[FFmpeg-devel] [PATCH] avutil: Add missing reference files for pixdesc fate test

[Andreas Rheinhardt]

Commit cd48318035 added support for NV24 and NV42, including several
fate tests for these formats, but did not include the reference files
for the tests filter-pixdesc-nv24 and filter-pixdesc-nv42. As a result,
these two tests were broken.

Signed-off-by: Andreas Rheinhardt 
---
 tests/ref/fate/filter-pixdesc-nv24 | 1 +
 tests/ref/fate/filter-pixdesc-nv42 | 1 +
 2 files changed, 2 insertions(+)
 create mode 100644 tests/ref/fate/filter-pixdesc-nv24
 create mode 100644 tests/ref/fate/filter-pixdesc-nv42

diff --git a/tests/ref/fate/filter-pixdesc-nv24 
b/tests/ref/fate/filter-pixdesc-nv24
new file mode 100644
index 00..ce07331997
--- /dev/null
+++ b/tests/ref/fate/filter-pixdesc-nv24
@@ -0,0 +1 @@
+pixdesc-nv247437f36b6ee58050564b20a1f839ff07
diff --git a/tests/ref/fate/filter-pixdesc-nv42 
b/tests/ref/fate/filter-pixdesc-nv42
new file mode 100644
index 00..88ef431a1b
--- /dev/null
+++ b/tests/ref/fate/filter-pixdesc-nv42
@@ -0,0 +1 @@
+pixdesc-nv42110bad2f58424ab800ad832f6966cafe
-- 
2.21.0

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

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

Re: [FFmpeg-devel] [PATCH] avfilter/vf_stack: Don't modify const strings

[Gyan]

On 14-05-2019 09:45 AM, Andreas Rheinhardt wrote:

b3b7ba62 introduced undefined behaviour: A (non-modifiable) string
literal has been assigned to a modifiable string; said string was indeed
modified later via av_strtok.
This of course caused compiler warnings because of the discarded
qualifier; these are in particular fixed by this commit.

Signed-off-by: Andreas Rheinhardt 
---
  libavfilter/vf_stack.c | 8 +---
  1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/libavfilter/vf_stack.c b/libavfilter/vf_stack.c
index 1455f196a7..4d254e0013 100644
--- a/libavfilter/vf_stack.c
+++ b/libavfilter/vf_stack.c
@@ -84,9 +84,11 @@ static av_cold int init(AVFilterContext *ctx)
  
  if (!strcmp(ctx->filter->name, "xstack")) {

  if (!s->layout) {
-if (s->nb_inputs == 2)
-s->layout = "0_0|w0_0";
-else {
+if (s->nb_inputs == 2) {
+s->layout = av_strdup("0_0|w0_0");
+if (!s->layout)
+return AVERROR(ENOMEM);
+} else {
  av_log(ctx, AV_LOG_ERROR, "No layout specified.\n");
  return AVERROR(EINVAL);
  }


Sorry, I missed what was being done with the string later on.

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

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

[FFmpeg-devel] [PATCH] avfilter/vf_stack: Don't modify const strings

[Andreas Rheinhardt]

b3b7ba62 introduced undefined behaviour: A (non-modifiable) string
literal has been assigned to a modifiable string; said string was indeed
modified later via av_strtok.
This of course caused compiler warnings because of the discarded
qualifier; these are in particular fixed by this commit.

Signed-off-by: Andreas Rheinhardt 
---
 libavfilter/vf_stack.c | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/libavfilter/vf_stack.c b/libavfilter/vf_stack.c
index 1455f196a7..4d254e0013 100644
--- a/libavfilter/vf_stack.c
+++ b/libavfilter/vf_stack.c
@@ -84,9 +84,11 @@ static av_cold int init(AVFilterContext *ctx)
 
 if (!strcmp(ctx->filter->name, "xstack")) {
 if (!s->layout) {
-if (s->nb_inputs == 2)
-s->layout = "0_0|w0_0";
-else {
+if (s->nb_inputs == 2) {
+s->layout = av_strdup("0_0|w0_0");
+if (!s->layout)
+return AVERROR(ENOMEM);
+} else {
 av_log(ctx, AV_LOG_ERROR, "No layout specified.\n");
 return AVERROR(EINVAL);
 }
-- 
2.21.0

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

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

[FFmpeg-devel] [PATCH 1/3] avfilter/vf_scale_cuda: Fix incorrect scaling of > 8bit content

[Philip Langdale]

When i converted the filter to use texture objects instead of
texture references, I incorrect dropped the `pixel_size` scaling
factor when setting `pitchInBytes`. `src_pitch` is in pixels and
so must be scaled up.
---
 libavfilter/vf_scale_cuda.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavfilter/vf_scale_cuda.c b/libavfilter/vf_scale_cuda.c
index c97a802ddc..ecfd6a1c92 100644
--- a/libavfilter/vf_scale_cuda.c
+++ b/libavfilter/vf_scale_cuda.c
@@ -357,7 +357,7 @@ static int call_resize_kernel(AVFilterContext *ctx, 
CUfunction func, int channel
 .res.pitch2D.numChannels = channels,
 .res.pitch2D.width = src_width,
 .res.pitch2D.height = src_height,
-.res.pitch2D.pitchInBytes = src_pitch,
+.res.pitch2D.pitchInBytes = src_pitch * pixel_size,
 .res.pitch2D.devPtr = (CUdeviceptr)src_dptr,
 };
 
-- 
2.20.1

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

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

[FFmpeg-devel] [PATCH 0/3] avfilter/vf_scale_cuda: Various improvements

[Philip Langdale]

After Sergey's bug report, I went and fixed a couple of other things
I noticed while I was looking at the filter.

Philip Langdale (3):
  avfilter/vf_scale_cuda: Fix incorrect scaling of > 8bit content
  avfilter/vf_scale_cuda: Add support for YUV444P16
  avfilter/vf_scale_cuda: Simplify output plane addressing

 libavfilter/vf_scale_cuda.c | 41 +
 1 file changed, 28 insertions(+), 13 deletions(-)

-- 
2.20.1

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

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

[FFmpeg-devel] [PATCH 2/3] avfilter/vf_scale_cuda: Add support for YUV444P16

[Philip Langdale]

This format is interesting because it's what you get for decoded
10/12bit HEVC 4:4:4.
---
 libavfilter/vf_scale_cuda.c | 17 -
 1 file changed, 16 insertions(+), 1 deletion(-)

diff --git a/libavfilter/vf_scale_cuda.c b/libavfilter/vf_scale_cuda.c
index ecfd6a1c92..a833dcd1a4 100644
--- a/libavfilter/vf_scale_cuda.c
+++ b/libavfilter/vf_scale_cuda.c
@@ -43,7 +43,8 @@ static const enum AVPixelFormat supported_formats[] = {
 AV_PIX_FMT_NV12,
 AV_PIX_FMT_YUV444P,
 AV_PIX_FMT_P010,
-AV_PIX_FMT_P016
+AV_PIX_FMT_P016,
+AV_PIX_FMT_YUV444P16,
 };
 
 #define DIV_UP(a, b) ( ((a) + (b) - 1) / (b) )
@@ -411,6 +412,20 @@ static int scalecuda_resize(AVFilterContext *ctx,
out->data[0]+out->linesize[0]*out->height*2, 
out->width, out->height, out->linesize[0],
1);
 break;
+case AV_PIX_FMT_YUV444P16:
+call_resize_kernel(ctx, s->cu_func_ushort, 1,
+   in->data[0], in->width, in->height, in->linesize[0] 
/ 2,
+   out->data[0], out->width, out->height, 
out->linesize[0] / 2,
+   2);
+call_resize_kernel(ctx, s->cu_func_ushort, 1,
+   in->data[1], in->width, in->height, in->linesize[1] 
/ 2,
+   out->data[1], out->width, out->height, 
out->linesize[1] / 2,
+   2);
+call_resize_kernel(ctx, s->cu_func_ushort, 1,
+   in->data[2], in->width, in->height, in->linesize[2] 
/ 2,
+   out->data[2], out->width, out->height, 
out->linesize[2] / 2,
+   2);
+break;
 case AV_PIX_FMT_NV12:
 call_resize_kernel(ctx, s->cu_func_uchar, 1,
in->data[0], in->width, in->height, in->linesize[0],
-- 
2.20.1

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

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

[FFmpeg-devel] [PATCH 3/3] avfilter/vf_scale_cuda: Simplify output plane addressing

[Philip Langdale]

I'm not sure why this was written the way it was originally. We
initialise the plane addresses correctly in hwcontext_cuda so
why try and play games to calculate the plane offsets directly
in this code?
---
 libavfilter/vf_scale_cuda.c | 22 +++---
 1 file changed, 11 insertions(+), 11 deletions(-)

diff --git a/libavfilter/vf_scale_cuda.c b/libavfilter/vf_scale_cuda.c
index a833dcd1a4..b7cdb81081 100644
--- a/libavfilter/vf_scale_cuda.c
+++ b/libavfilter/vf_scale_cuda.c
@@ -390,12 +390,12 @@ static int scalecuda_resize(AVFilterContext *ctx,
out->data[0], out->width, out->height, 
out->linesize[0],
1);
 call_resize_kernel(ctx, s->cu_func_uchar, 1,
-   in->data[0]+in->linesize[0]*in->height, 
in->width/2, in->height/2, in->linesize[0]/2,
-   out->data[0]+out->linesize[0]*out->height, 
out->width/2, out->height/2, out->linesize[0]/2,
+   in->data[1], in->width/2, in->height/2, 
in->linesize[0]/2,
+   out->data[1], out->width/2, out->height/2, 
out->linesize[0]/2,
1);
 call_resize_kernel(ctx, s->cu_func_uchar, 1,
-   in->data[0]+ 
ALIGN_UP((in->linesize[0]*in->height*5)/4, s->tex_alignment), in->width/2, 
in->height/2, in->linesize[0]/2,
-   out->data[0]+(out->linesize[0]*out->height*5)/4, 
out->width/2, out->height/2, out->linesize[0]/2,
+   in->data[2], in->width/2, in->height/2, 
in->linesize[0]/2,
+   out->data[2], out->width/2, out->height/2, 
out->linesize[0]/2,
1);
 break;
 case AV_PIX_FMT_YUV444P:
@@ -404,12 +404,12 @@ static int scalecuda_resize(AVFilterContext *ctx,
out->data[0], out->width, out->height, 
out->linesize[0],
1);
 call_resize_kernel(ctx, s->cu_func_uchar, 1,
-   in->data[0]+in->linesize[0]*in->height, in->width, 
in->height, in->linesize[0],
-   out->data[0]+out->linesize[0]*out->height, 
out->width, out->height, out->linesize[0],
+   in->data[1], in->width, in->height, in->linesize[0],
+   out->data[1], out->width, out->height, 
out->linesize[0],
1);
 call_resize_kernel(ctx, s->cu_func_uchar, 1,
-   in->data[0]+in->linesize[0]*in->height*2, 
in->width, in->height, in->linesize[0],
-   out->data[0]+out->linesize[0]*out->height*2, 
out->width, out->height, out->linesize[0],
+   in->data[2], in->width, in->height, in->linesize[0],
+   out->data[2], out->width, out->height, 
out->linesize[0],
1);
 break;
 case AV_PIX_FMT_YUV444P16:
@@ -433,7 +433,7 @@ static int scalecuda_resize(AVFilterContext *ctx,
1);
 call_resize_kernel(ctx, s->cu_func_uchar2, 2,
in->data[1], in->width/2, in->height/2, 
in->linesize[1],
-   out->data[0] + out->linesize[0] * ((out->height + 
31) & ~0x1f), out->width/2, out->height/2, out->linesize[1]/2,
+   out->data[1], out->width/2, out->height/2, 
out->linesize[1]/2,
1);
 break;
 case AV_PIX_FMT_P010LE:
@@ -443,7 +443,7 @@ static int scalecuda_resize(AVFilterContext *ctx,
2);
 call_resize_kernel(ctx, s->cu_func_ushort2, 2,
in->data[1], in->width / 2, in->height / 2, 
in->linesize[1]/2,
-   out->data[0] + out->linesize[0] * ((out->height + 
31) & ~0x1f), out->width / 2, out->height / 2, out->linesize[1] / 4,
+   out->data[1], out->width / 2, out->height / 2, 
out->linesize[1] / 4,
2);
 break;
 case AV_PIX_FMT_P016LE:
@@ -453,7 +453,7 @@ static int scalecuda_resize(AVFilterContext *ctx,
2);
 call_resize_kernel(ctx, s->cu_func_ushort2, 2,
in->data[1], in->width / 2, in->height / 2, 
in->linesize[1] / 2,
-   out->data[0] + out->linesize[0] * ((out->height + 
31) & ~0x1f), out->width / 2, out->height / 2, out->linesize[1] / 4,
+   out->data[1], out->width / 2, out->height / 2, 
out->linesize[1] / 4,
2);
 break;
 default:
-- 
2.20.1

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

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

Re: [FFmpeg-devel] [PATCH] libavfilter/vf_scale_cuda: fix src_pitch for 10bit videos

[Philip Langdale]

On Mon, 13 May 2019 11:18:09 +
Sergey Svechnikov  wrote:

> When scaling a 10bit video using scale_cuda filter (witch uses pixel
> format AV_PIX_FMT_P010LE), the output video gets distorted. I think
> it has something to do with the differences in processing between
> cuda_sdk and ffnvcodec with cuda_nvcc (the problem appears after this
> commit
> https://github.com/FFmpeg/FFmpeg/commit/2544c7ea67ca9521c5de36396bc9ac7058223742).
> To solve the problem we should not divide the input frame planes'
> linesizes by 2 and leave them as they are. More info, samples and
> reproduction steps are here
> https://github.com/Svechnikov/ffmpeg-scale-cuda-10bit-problem ---
> libavfilter/vf_scale_cuda.c | 4 ++-- 1 file changed, 2 insertions(+),
> 2 deletions(-)
> 
> diff --git a/libavfilter/vf_scale_cuda.c b/libavfilter/vf_scale_cuda.c
> index c97a802..7fc33ee 100644
> --- a/libavfilter/vf_scale_cuda.c
> +++ b/libavfilter/vf_scale_cuda.c
> @@ -423,11 +423,11 @@ static int scalecuda_resize(AVFilterContext
> *ctx, break;
>  case AV_PIX_FMT_P010LE:
>  call_resize_kernel(ctx, s->cu_func_ushort, 1,
> -   in->data[0], in->width, in->height,
> in->linesize[0]/2,
> +   in->data[0], in->width, in->height,
> in->linesize[0], out->data[0], out->width, out->height,
> out->linesize[0]/2, 2);
>  call_resize_kernel(ctx, s->cu_func_ushort2, 2,
> -   in->data[1], in->width / 2, in->height /
> 2, in->linesize[1]/2,
> +   in->data[1], in->width / 2, in->height /
> 2, in->linesize[1], out->data[0] + out->linesize[0] * ((out->height +
> 31) & ~0x1f), out->width / 2, out->height / 2, out->linesize[1] / 4,
> 2); break;

Thanks for reporting the problem. I took a look and identified the
precise mistake I made. I dropped the `pixel_size` scaling factor
when setting `pitchInBytes`. Here is the fix I intend to apply.

diff --git a/libavfilter/vf_scale_cuda.c b/libavfilter/vf_scale_cuda.c
index c97a802ddc..ecfd6a1c92 100644
--- a/libavfilter/vf_scale_cuda.c
+++ b/libavfilter/vf_scale_cuda.c
@@ -357,7 +357,7 @@ static int call_resize_kernel(AVFilterContext *ctx,
CUfunction func, int channel .res.pitch2D.numChannels = channels,
 .res.pitch2D.width = src_width,
 .res.pitch2D.height = src_height,
-.res.pitch2D.pitchInBytes = src_pitch,
+.res.pitch2D.pitchInBytes = src_pitch * pixel_size,
 .res.pitch2D.devPtr = (CUdeviceptr)src_dptr,
 };

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

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

Re: [FFmpeg-devel] [PATCH] libavformat/utils: Interpolate missing timestamps in H264 and HEVC when no b-frames observed.

[Michael Niedermayer]

On Mon, May 13, 2019 at 03:37:24PM -0400, Andriy Gelman wrote:
> Hello, 
> 
> On Mon, 13. May 12:04, Michael Niedermayer wrote:
> > On Sat, May 11, 2019 at 11:20:51PM -0400, Andriy Gelman wrote:
> > > From: Andriy Gelman 
> > > 
> > > Fixes Ticket #7895.
> > > 
> > > Currently, timestamp interpolation is disabled by default in H264 and
> > > HEVC.  This creates playback issues when the demuxer does not output a
> > > valid timestamp. This patch allows interpolation when no b-frames have
> > > been observed during decoding, which fixes playback issues for some
> > > missing timestamp cases.
> > > ---
> > >  libavformat/utils.c | 11 +--
> > >  1 file changed, 9 insertions(+), 2 deletions(-)
> > > 
> > > diff --git a/libavformat/utils.c b/libavformat/utils.c
> > > index a63d71b0f4..0668ae3ad1 100644
> > > --- a/libavformat/utils.c
> > > +++ b/libavformat/utils.c
> > > @@ -1233,7 +1233,9 @@ static void compute_pkt_fields(AVFormatContext *s, 
> > > AVStream *st,
> > >  int64_t offset;
> > >  AVRational duration;
> > >  int onein_oneout = st->codecpar->codec_id != AV_CODEC_ID_H264 &&
> > > -   st->codecpar->codec_id != AV_CODEC_ID_HEVC;
> > > +   st->codecpar->codec_id != AV_CODEC_ID_HEVC ||
> > > +   (!st->internal->avctx->max_b_frames &&
> > 
> > > +st->cur_dts != RELATIVE_TS_BASE);
> > 
> > This needs a comment explaining what it does. Assuming it is what i think 
> > it is
> > then its not completely obvious and could confuse someone working on the 
> > code
> > in the future.
> 
> I added this condition so that pts/dts interpolation is skipped when the 
> demuxer
> provides no timing information. I will add the comment in the updated patch.
> 

> > >  
> > >  if (s->flags & AVFMT_FLAG_NOFILLIN)
> > >  return;
> > > @@ -1272,6 +1274,10 @@ static void compute_pkt_fields(AVFormatContext *s, 
> > > AVStream *st,
> > >  delay = st->internal->avctx->has_b_frames;
> > >  presentation_delayed = 0;
> > >  
> > > +/*update max_b_frames if delay is larger */
> > > +if (delay > st->internal->avctx->max_b_frames)
> > > +  st->internal->avctx->max_b_frames = delay;
> > 
> > do we have a testcase for this ?
> > 
> 
> I can add a testcase similar to the attachment in ticket #7895, where the 
> pts/dts is interpolated 
> on a HEVC stream encoded with the zerolatency option. Will this be ok? 

should be fine if it results in a reliable testcase

thx

[...]

-- 
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
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [PATCH] avformat/mxfenc: support XAVC long gop

[Baptiste Coudurier]

Hi Thomas

> On May 13, 2019, at 3:11 PM, Thomas Mundt  wrote:
> 
> Hi Baptiste,
> 
> Am Fr., 10. Mai 2019 um 17:51 Uhr schrieb Baptiste Coudurier <
> baptiste.coudur...@gmail.com>:
> 
>> ---
>> libavformat/Makefile |   2 +-
>> libavformat/avc.c| 188 ++
>> libavformat/avc.h|  15 +++
>> libavformat/hevc.c   |  36 +---
>> libavformat/mxf.h|   1 +
>> libavformat/mxfenc.c | 213 ++-
>> 6 files changed, 374 insertions(+), 81 deletions(-)
>> [...]
> 
> +static const MXFLocalTagPair mxf_avc_subdescriptor_local_tags[] = {
>> +{ 0x8100,
>> {0x06,0x0E,0x2B,0x34,0x01,0x01,0x01,0x09,0x06,0x01,0x01,0x04,0x06,0x10,0x00,0x00}},
>> /* SubDescriptors */
>> +{ 0x8200,
>> {0x06,0x0E,0x2B,0x34,0x01,0x01,0x01,0x0E,0x04,0x01,0x06,0x06,0x01,0x0E,0x00,0x00}},
>> /* AVC Decoding Delay */
>> +{ 0x8201,
>> {0x06,0x0E,0x2B,0x34,0x01,0x01,0x01,0x0E,0x04,0x01,0x06,0x06,0x01,0x0A,0x00,0x00}},
>> /* AVC Profile */
>> +{ 0x8202,
>> {0x06,0x0E,0x2B,0x34,0x01,0x01,0x01,0x0E,0x04,0x01,0x06,0x06,0x01,0x0D,0x00,0x00}},
>> /* AVC Level */
>> +};
>> +
>> [...]
>> +static void mxf_write_avc_subdesc(AVFormatContext *s, AVStream *st)
>> +{
>> +AVIOContext *pb = s->pb;
>> +int64_t pos;
>> +
>> +avio_write(pb, mxf_avc_subdescriptor_key, 16);
>> +klv_encode_ber4_length(pb, 0);
>> +pos = avio_tell(pb);
>> +
>> +mxf_write_local_tag(pb, 16, 0x3C0A);
>> +mxf_write_uuid(pb, AVCSubDescriptor, 0);
>> +
>> +mxf_write_local_tag(pb, 1, 0x8200);
>> +avio_w8(pb, 0xFF); // AVC Decoding Delay, unknown
>> +
>> +mxf_write_local_tag(pb, 1, 0x8201);
>> +avio_w8(pb, st->codecpar->profile); // AVC Profile
>> +
>> +mxf_write_local_tag(pb, 1, 0x8202);
>> +avio_w8(pb, st->codecpar->level); // AVC Level
>> +
>> +mxf_update_klv_size(s->pb, pos);
>> +}
>> 
> 
> Other MXF muxers, e.g. bmxlib, also write the avc profile constraint tag
> when the avc subdescriptor is used. At least MediaInfo detects intra coded
> files as long gop otherwise.

I prefer not writing optional values unless actually required by actual 
decoders.
I think MediaInfo should be fixed in this case, it is obviously wrong.

> FFmpeg crashes with this patch when I try to remux AVC Intra files without
> SPS/PPS header.
> Tested on Windows 7. Compiled with msys2/gcc7.3.0 x86-32bit.
> Command: ffmpeg -i AVCI100_Test.mxf -c:v copy out.mxf
> Test file:
> https://www.mediafire.com/file/n0oi50u39yi3qpr/AVCI100_Test.mxf/file 
> 

Strange, why doesn’t gcc emit a warning for SPS might be initialized in this 
case…
Fixed in an updated patch.

— 
Baptiste

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

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

[FFmpeg-devel] [PATCH] avformat/mxfenc: support XAVC long gop

[Baptiste Coudurier]

---
 libavformat/Makefile |   2 +-
 libavformat/avc.c| 186 +
 libavformat/avc.h|  15 +++
 libavformat/hevc.c   |  36 +---
 libavformat/mxf.h|   1 +
 libavformat/mxfenc.c | 213 ++-
 6 files changed, 372 insertions(+), 81 deletions(-)

diff --git a/libavformat/Makefile b/libavformat/Makefile
index 99be60d184..df87c54a58 100644
--- a/libavformat/Makefile
+++ b/libavformat/Makefile
@@ -339,7 +339,7 @@ OBJS-$(CONFIG_MUSX_DEMUXER)  += musx.o
 OBJS-$(CONFIG_MV_DEMUXER)+= mvdec.o
 OBJS-$(CONFIG_MVI_DEMUXER)   += mvi.o
 OBJS-$(CONFIG_MXF_DEMUXER)   += mxfdec.o mxf.o
-OBJS-$(CONFIG_MXF_MUXER) += mxfenc.o mxf.o audiointerleave.o
+OBJS-$(CONFIG_MXF_MUXER) += mxfenc.o mxf.o audiointerleave.o 
avc.o
 OBJS-$(CONFIG_MXG_DEMUXER)   += mxg.o
 OBJS-$(CONFIG_NC_DEMUXER)+= ncdec.o
 OBJS-$(CONFIG_NISTSPHERE_DEMUXER)+= nistspheredec.o pcm.o
diff --git a/libavformat/avc.c b/libavformat/avc.c
index ec50033a04..a041e84357 100644
--- a/libavformat/avc.c
+++ b/libavformat/avc.c
@@ -21,6 +21,7 @@
 
 #include "libavutil/intreadwrite.h"
 #include "libavcodec/h264.h"
+#include "libavcodec/get_bits.h"
 #include "avformat.h"
 #include "avio.h"
 #include "avc.h"
@@ -241,3 +242,188 @@ const uint8_t *ff_avc_mp4_find_startcode(const uint8_t 
*start,
 
 return start + res;
 }
+
+uint8_t *ff_nal_unit_extract_rbsp(const uint8_t *src, uint32_t src_len,
+  uint32_t *dst_len, int header_len)
+{
+uint8_t *dst;
+uint32_t i, len;
+
+dst = av_malloc(src_len + AV_INPUT_BUFFER_PADDING_SIZE);
+if (!dst)
+return NULL;
+
+/* NAL unit header */
+i = len = 0;
+while (i < header_len && i < src_len)
+dst[len++] = src[i++];
+
+while (i + 2 < src_len)
+if (!src[i] && !src[i + 1] && src[i + 2] == 3) {
+dst[len++] = src[i++];
+dst[len++] = src[i++];
+i++; // remove emulation_prevention_three_byte
+} else
+dst[len++] = src[i++];
+
+while (i < src_len)
+dst[len++] = src[i++];
+
+memset(dst + len, 0, AV_INPUT_BUFFER_PADDING_SIZE);
+
+*dst_len = len;
+return dst;
+}
+
+static const AVRational avc_sample_aspect_ratio[17] = {
+{   0,  1 },
+{   1,  1 },
+{  12, 11 },
+{  10, 11 },
+{  16, 11 },
+{  40, 33 },
+{  24, 11 },
+{  20, 11 },
+{  32, 11 },
+{  80, 33 },
+{  18, 11 },
+{  15, 11 },
+{  64, 33 },
+{ 160, 99 },
+{   4,  3 },
+{   3,  2 },
+{   2,  1 },
+};
+
+static inline int get_ue_golomb(GetBitContext *gb) {
+int i;
+for (i = 0; i < 32 && !get_bits1(gb); i++)
+;
+return get_bitsz(gb, i) + (1 << i) - 1;
+}
+
+static inline int get_se_golomb(GetBitContext *gb) {
+int v = get_ue_golomb(gb) + 1;
+int sign = -(v & 1);
+return ((v >> 1) ^ sign) - sign;
+}
+
+H264SequenceParameterSet *ff_avc_decode_sps(const uint8_t *buf, int buf_size)
+{
+int i, j, ret, rbsp_size, aspect_ratio_idc, pic_order_cnt_type;
+int num_ref_frames_in_pic_order_cnt_cycle;
+int delta_scale, lastScale = 8, nextScale = 8;
+int sizeOfScalingList;
+H264SequenceParameterSet *sps = NULL;
+GetBitContext gb;
+uint8_t *rbsp_buf;
+
+rbsp_buf = ff_nal_unit_extract_rbsp(buf, buf_size, _size, 0);
+if (!rbsp_buf)
+return NULL;
+
+ret = init_get_bits8(, rbsp_buf, rbsp_size);
+if (ret < 0)
+goto end;
+
+sps = av_mallocz(sizeof(*sps));
+if (!sps)
+goto end;
+
+sps->profile_idc = get_bits(, 8);
+sps->constraint_set_flags |= get_bits1() << 0; // constraint_set0_flag
+sps->constraint_set_flags |= get_bits1() << 1; // constraint_set1_flag
+sps->constraint_set_flags |= get_bits1() << 2; // constraint_set2_flag
+sps->constraint_set_flags |= get_bits1() << 3; // constraint_set3_flag
+sps->constraint_set_flags |= get_bits1() << 4; // constraint_set4_flag
+sps->constraint_set_flags |= get_bits1() << 5; // constraint_set5_flag
+skip_bits(, 2); // reserved_zero_2bits
+sps->level_idc = get_bits(, 8);
+sps->id = get_ue_golomb();
+
+if (sps->profile_idc == 100 || sps->profile_idc == 110 ||
+sps->profile_idc == 122 || sps->profile_idc == 244 || sps->profile_idc 
==  44 ||
+sps->profile_idc ==  83 || sps->profile_idc ==  86 || sps->profile_idc 
== 118 ||
+sps->profile_idc == 128 || sps->profile_idc == 138 || sps->profile_idc 
== 139 ||
+sps->profile_idc == 134) {
+sps->chroma_format_idc = get_ue_golomb(); // chroma_format_idc
+if (sps->chroma_format_idc == 3) {
+skip_bits1(); // separate_colour_plane_flag
+}
+sps->bit_depth_luma = get_ue_golomb() + 8;
+get_ue_golomb(); // bit_depth_chroma_minus8
+skip_bits1(); // 

Re: [FFmpeg-devel] How to correctly use init and uninit

[Ulf Zibis]

Am 19.04.19 um 14:35 schrieb Paul B Mahol:
>>> You do not need to use loop filter on single png.
>> I need real pictures to prove the correctness of my hacking. The
>> smptebars is not appopriate to see errors in the output e.g. from mirroring.
>>
>>> Use something like this:
>>>
>>> ffmpeg -f lavfi -i smptebars=size=hd720 -vf fillborders=... -f null -
>> For performance testing I use the like:
>> -f rawvideo -pix_fmt gray16 -s 400x600 -i /dev/zero
>>
>> Are there doubts if that is good either?
> Use ffmpeg -f lavfi -i color=color=black:size=400x600 ...
>
> Thing about /dev/zero and -f rawvideo is that it will decode zeroes
> over and over again and thus use more CPU for that.

I can not confirm that. :-(

My benchmark needs 60 seconds with
ffmpeg -f lavfi -i
color=color=black:size=400x600,format=rgba64/gray/gray16 ...
but only 25 seconds with
ffmpeg -f rawvideo -pix_fmt rgba64/gray/gray16 -s 400x600 -i /dev/zero ...

-Ult

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

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

Re: [FFmpeg-devel] [PATCH] avformat/mxfenc: support XAVC long gop

[Thomas Mundt]

Hi Baptiste,

Am Fr., 10. Mai 2019 um 17:51 Uhr schrieb Baptiste Coudurier <
baptiste.coudur...@gmail.com>:

> ---
>  libavformat/Makefile |   2 +-
>  libavformat/avc.c| 188 ++
>  libavformat/avc.h|  15 +++
>  libavformat/hevc.c   |  36 +---
>  libavformat/mxf.h|   1 +
>  libavformat/mxfenc.c | 213 ++-
>  6 files changed, 374 insertions(+), 81 deletions(-)
> [...]

+static const MXFLocalTagPair mxf_avc_subdescriptor_local_tags[] = {
> +{ 0x8100,
> {0x06,0x0E,0x2B,0x34,0x01,0x01,0x01,0x09,0x06,0x01,0x01,0x04,0x06,0x10,0x00,0x00}},
> /* SubDescriptors */
> +{ 0x8200,
> {0x06,0x0E,0x2B,0x34,0x01,0x01,0x01,0x0E,0x04,0x01,0x06,0x06,0x01,0x0E,0x00,0x00}},
> /* AVC Decoding Delay */
> +{ 0x8201,
> {0x06,0x0E,0x2B,0x34,0x01,0x01,0x01,0x0E,0x04,0x01,0x06,0x06,0x01,0x0A,0x00,0x00}},
> /* AVC Profile */
> +{ 0x8202,
> {0x06,0x0E,0x2B,0x34,0x01,0x01,0x01,0x0E,0x04,0x01,0x06,0x06,0x01,0x0D,0x00,0x00}},
> /* AVC Level */
> +};
> +
> [...]
> +static void mxf_write_avc_subdesc(AVFormatContext *s, AVStream *st)
> +{
> +AVIOContext *pb = s->pb;
> +int64_t pos;
> +
> +avio_write(pb, mxf_avc_subdescriptor_key, 16);
> +klv_encode_ber4_length(pb, 0);
> +pos = avio_tell(pb);
> +
> +mxf_write_local_tag(pb, 16, 0x3C0A);
> +mxf_write_uuid(pb, AVCSubDescriptor, 0);
> +
> +mxf_write_local_tag(pb, 1, 0x8200);
> +avio_w8(pb, 0xFF); // AVC Decoding Delay, unknown
> +
> +mxf_write_local_tag(pb, 1, 0x8201);
> +avio_w8(pb, st->codecpar->profile); // AVC Profile
> +
> +mxf_write_local_tag(pb, 1, 0x8202);
> +avio_w8(pb, st->codecpar->level); // AVC Level
> +
> +mxf_update_klv_size(s->pb, pos);
> +}
>

Other MXF muxers, e.g. bmxlib, also write the avc profile constraint tag
when the avc subdescriptor is used. At least MediaInfo detects intra coded
files as long gop otherwise.

FFmpeg crashes with this patch when I try to remux AVC Intra files without
SPS/PPS header.
Tested on Windows 7. Compiled with msys2/gcc7.3.0 x86-32bit.
Command: ffmpeg -i AVCI100_Test.mxf -c:v copy out.mxf
Test file:
https://www.mediafire.com/file/n0oi50u39yi3qpr/AVCI100_Test.mxf/file

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

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

Re: [FFmpeg-devel] [PATCH v3 2/2] avcodec/videotoolbox: add support for full range pixel formats

[der richter]

ping, should i do anything else about this second part of the patch?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [DECISION] Project policy on closed source components

[Hendrik Leppkes]

On Mon, May 13, 2019 at 10:53 PM Carl Eugen Hoyos  wrote:
>
> > Release branches provide a guarantee of API, ABI and feature
> > stability.
>
> And we sadly did not always hold that guarantee=-(

Mistakes have been made. We shall strive to be better in the future,
and not use them as an excuse to push an agenda.

>
> > We shall not violate that for some petty feud.
>
> I wonder if this isn't exactly a case where it should be violated.
> Contrary to the cases where we - unfortunately - have
> violated it in the past.
>

No, we shall not.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [DECISION] Project policy on closed source components

[Carl Eugen Hoyos]

Am Mo., 13. Mai 2019 um 22:46 Uhr schrieb Hendrik Leppkes :
>
> On Mon, May 13, 2019 at 10:37 PM Carl Eugen Hoyos  wrote:
> >
> > Am Mo., 13. Mai 2019 um 22:32 Uhr schrieb James Almer :
> > >
> > > On 5/13/2019 5:23 PM, Carl Eugen Hoyos wrote:
> > > > Am Mo., 13. Mai 2019 um 22:18 Uhr schrieb James Almer 
> > > > :
> > > >>
> > > >> On 5/13/2019 5:13 PM, Carl Eugen Hoyos wrote:
> > > >>> Am Mo., 13. Mai 2019 um 22:10 Uhr schrieb Marton Balint 
> > > >>> :
> >
> > > > 1) Should libNDI support be removed from the ffmpeg codebase?
> > > 
> > >  Thanks for the votes, I counted 9 yes, 5 no, so majority is for 
> > >  removal of
> > >  libNDI, which is already done.
> > > >>>
> > > >>> The vote was not about the removal from libndi from release branches?
> > > >>
> > > >> No, features on releases are frozen, as changing them can result in
> > > >> breakages for distros and package managers.
> > > >
> > > > We have broken distros and packages before, we would not break it
> > > > in this case;-)
> > >
> > > We would. Distros and scripts would be broken, and it would not be pretty.
> >
> > Would you please be so kind as to explain (if possible in detail) how
> > this would be possible in this specific case?
> > I do not understand how removing a non-free dependency can break a
> > binary distribution.
> >
>
> There are other people that use and build ffmpeg, and track release
> branches.

But not distributions as claimed above.

> And they may as well be building only for themselves a
> non-free binary.

Absolutely.
And they can still do that after reverting a possible removal but
they would realize that we are not endorsing the library anymore.

> Release branches provide a guarantee of API, ABI and feature
> stability.

And we sadly did not always hold that guarantee=-(

> We shall not violate that for some petty feud.

I wonder if this isn't exactly a case where it should be violated.
Contrary to the cases where we - unfortunately - have
violated it in the past.

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

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

Re: [FFmpeg-devel] [DECISION] Project policy on closed source components

[James Almer]

On 5/13/2019 5:36 PM, Carl Eugen Hoyos wrote:
> Am Mo., 13. Mai 2019 um 22:32 Uhr schrieb James Almer :
>>
>> On 5/13/2019 5:23 PM, Carl Eugen Hoyos wrote:
>>> Am Mo., 13. Mai 2019 um 22:18 Uhr schrieb James Almer :

 On 5/13/2019 5:13 PM, Carl Eugen Hoyos wrote:
> Am Mo., 13. Mai 2019 um 22:10 Uhr schrieb Marton Balint :
> 
>>> 1) Should libNDI support be removed from the ffmpeg codebase?
>>
>> Thanks for the votes, I counted 9 yes, 5 no, so majority is for removal 
>> of
>> libNDI, which is already done.
>
> The vote was not about the removal from libndi from release branches?

 No, features on releases are frozen, as changing them can result in
 breakages for distros and package managers.
>>>
>>> We have broken distros and packages before, we would not break it
>>> in this case;-)
>>
>> We would. Distros and scripts would be broken, and it would not be pretty.
> 
> Would you please be so kind as to explain (if possible in detail) how
> this would be possible in this specific case?
> I do not understand how removing a non-free dependency can break a
> binary distribution.
> 
 We have removed tons of
 libraries before and it's always limited to git master.
>>>
>>> None of them had to be removed because the authors chose to
>>> violate our copyright (and refused to fix the copyright violation)
>>> so we decided to stop endorsing them.
>>
>> If you feel strong about it
> 
> I don't, I just wonder how your interpretation of the question
> is more obvious than mine.
> 
>> and if you think it justifies breaking
>> releases and pissing off distros and package managers handling half a
>> decade old well tested LTS releases, you can start a vote to remove it
>> from releases.
> 
> Again: Please elaborate!

No, i wont. I'm tired of you having something in mind but never saying
it. You have a reason to think distros will not be affected? State it.
If it's right, then you stopped an argument before it started. Don't try
to lead the other party to reach to the same conclusion you came to when
a single paragraph can prevent it. It wastes time and patience, and the
latter is something people on this list have run out of long ago.

The vote was to make the removal that already took place official. If
you want it gone from release branches, start a vote for it explaining
why something that exceptional should be done and why it would not be an
issue. As i said, i don't think you'll have a hard time harvesting
positive votes for it knowing the above precedent.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [DECISION] Project policy on closed source components

[Hendrik Leppkes]

On Mon, May 13, 2019 at 10:37 PM Carl Eugen Hoyos  wrote:
>
> Am Mo., 13. Mai 2019 um 22:32 Uhr schrieb James Almer :
> >
> > On 5/13/2019 5:23 PM, Carl Eugen Hoyos wrote:
> > > Am Mo., 13. Mai 2019 um 22:18 Uhr schrieb James Almer :
> > >>
> > >> On 5/13/2019 5:13 PM, Carl Eugen Hoyos wrote:
> > >>> Am Mo., 13. Mai 2019 um 22:10 Uhr schrieb Marton Balint 
> > >>> :
>
> > > 1) Should libNDI support be removed from the ffmpeg codebase?
> > 
> >  Thanks for the votes, I counted 9 yes, 5 no, so majority is for 
> >  removal of
> >  libNDI, which is already done.
> > >>>
> > >>> The vote was not about the removal from libndi from release branches?
> > >>
> > >> No, features on releases are frozen, as changing them can result in
> > >> breakages for distros and package managers.
> > >
> > > We have broken distros and packages before, we would not break it
> > > in this case;-)
> >
> > We would. Distros and scripts would be broken, and it would not be pretty.
>
> Would you please be so kind as to explain (if possible in detail) how
> this would be possible in this specific case?
> I do not understand how removing a non-free dependency can break a
> binary distribution.
>

There are other people that use and build ffmpeg, and track release
branches. And they may as well be building only for themselves a
non-free binary.
Release branches provide a guarantee of API, ABI and feature
stability. We shall not violate that for some petty feud.

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

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

Re: [FFmpeg-devel] [DECISION] Project policy on closed source components

[Carl Eugen Hoyos]

Am Mo., 13. Mai 2019 um 22:32 Uhr schrieb James Almer :
>
> On 5/13/2019 5:23 PM, Carl Eugen Hoyos wrote:
> > Am Mo., 13. Mai 2019 um 22:18 Uhr schrieb James Almer :
> >>
> >> On 5/13/2019 5:13 PM, Carl Eugen Hoyos wrote:
> >>> Am Mo., 13. Mai 2019 um 22:10 Uhr schrieb Marton Balint :

> > 1) Should libNDI support be removed from the ffmpeg codebase?
> 
>  Thanks for the votes, I counted 9 yes, 5 no, so majority is for removal 
>  of
>  libNDI, which is already done.
> >>>
> >>> The vote was not about the removal from libndi from release branches?
> >>
> >> No, features on releases are frozen, as changing them can result in
> >> breakages for distros and package managers.
> >
> > We have broken distros and packages before, we would not break it
> > in this case;-)
>
> We would. Distros and scripts would be broken, and it would not be pretty.

Would you please be so kind as to explain (if possible in detail) how
this would be possible in this specific case?
I do not understand how removing a non-free dependency can break a
binary distribution.

> >> We have removed tons of
> >> libraries before and it's always limited to git master.
> >
> > None of them had to be removed because the authors chose to
> > violate our copyright (and refused to fix the copyright violation)
> > so we decided to stop endorsing them.
>
> If you feel strong about it

I don't, I just wonder how your interpretation of the question
is more obvious than mine.

> and if you think it justifies breaking
> releases and pissing off distros and package managers handling half a
> decade old well tested LTS releases, you can start a vote to remove it
> from releases.

Again: Please elaborate!

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

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

Re: [FFmpeg-devel] [DECISION] Project policy on closed source components

[James Almer]

On 5/13/2019 5:23 PM, Carl Eugen Hoyos wrote:
> Am Mo., 13. Mai 2019 um 22:18 Uhr schrieb James Almer :
>>
>> On 5/13/2019 5:13 PM, Carl Eugen Hoyos wrote:
>>> Am Mo., 13. Mai 2019 um 22:10 Uhr schrieb Marton Balint :

 On Sun, 28 Apr 2019, Marton Balint wrote:

> Hi All,
>
> There has been discussion on the mailing list several times about the
> inclusion of support for closed source components (codecs, formats,
> filters, etc) in the main ffmpeg codebase.
>
> Also the removal of libNDI happened without general consensus, so a vote
> is necessary to justify the removal.
>
> So here is a call to the voting committee [1] to decide on the following
> two questions:
>
> 1) Should libNDI support be removed from the ffmpeg codebase?
>

 Thanks for the votes, I counted 9 yes, 5 no, so majority is for removal of
 libNDI, which is already done.
>>>
>>> The vote was not about the removal from libndi from release branches?
>>
>> No, features on releases are frozen, as changing them can result in
>> breakages for distros and package managers.
> 
> We have broken distros and packages before, we would not break it
> in this case;-)

We would. Distros and scripts would be broken, and it would not be pretty.

> 
>> We have removed tons of
>> libraries before and it's always limited to git master.
> 
> None of them had to be removed because the authors chose to
> violate our copyright (and refused to fix the copyright violation)
> so we decided to stop endorsing them.

If you feel strong about it, and if you think it justifies breaking
releases and pissing off distros and package managers handling half a
decade old well tested LTS releases, you can start a vote to remove it
from releases.
Seeing the outcome of the above vote, i wouldn't be surprised if such a
vote gets a positive result as well.

> 
>> The vote was to make the removal official
> 
> Sorry, but I find this interpretation extremely difficult from the quote 
> above,

I think "Also the removal of libNDI happened without general consensus,
so a vote is necessary to justify the removal." is pretty clear with its
usage of words like "happened".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [DECISION] Project policy on closed source components

[Carl Eugen Hoyos]

Am Mo., 13. Mai 2019 um 22:18 Uhr schrieb James Almer :
>
> On 5/13/2019 5:13 PM, Carl Eugen Hoyos wrote:
> > Am Mo., 13. Mai 2019 um 22:10 Uhr schrieb Marton Balint :
> >>
> >> On Sun, 28 Apr 2019, Marton Balint wrote:
> >>
> >>> Hi All,
> >>>
> >>> There has been discussion on the mailing list several times about the
> >>> inclusion of support for closed source components (codecs, formats,
> >>> filters, etc) in the main ffmpeg codebase.
> >>>
> >>> Also the removal of libNDI happened without general consensus, so a vote
> >>> is necessary to justify the removal.
> >>>
> >>> So here is a call to the voting committee [1] to decide on the following
> >>> two questions:
> >>>
> >>> 1) Should libNDI support be removed from the ffmpeg codebase?
> >>>
> >>
> >> Thanks for the votes, I counted 9 yes, 5 no, so majority is for removal of
> >> libNDI, which is already done.
> >
> > The vote was not about the removal from libndi from release branches?
>
> No, features on releases are frozen, as changing them can result in
> breakages for distros and package managers.

We have broken distros and packages before, we would not break it
in this case;-)

> We have removed tons of
> libraries before and it's always limited to git master.

None of them had to be removed because the authors chose to
violate our copyright (and refused to fix the copyright violation)
so we decided to stop endorsing them.

> The vote was to make the removal official

Sorry, but I find this interpretation extremely difficult from the quote above,

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

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

Re: [FFmpeg-devel] [DECISION] Project policy on closed source components

[James Almer]

On 5/13/2019 5:13 PM, Carl Eugen Hoyos wrote:
> Am Mo., 13. Mai 2019 um 22:10 Uhr schrieb Marton Balint :
>>
>> On Sun, 28 Apr 2019, Marton Balint wrote:
>>
>>> Hi All,
>>>
>>> There has been discussion on the mailing list several times about the
>>> inclusion of support for closed source components (codecs, formats,
>>> filters, etc) in the main ffmpeg codebase.
>>>
>>> Also the removal of libNDI happened without general consensus, so a vote
>>> is necessary to justify the removal.
>>>
>>> So here is a call to the voting committee [1] to decide on the following
>>> two questions:
>>>
>>> 1) Should libNDI support be removed from the ffmpeg codebase?
>>>
>>
>> Thanks for the votes, I counted 9 yes, 5 no, so majority is for removal of
>> libNDI, which is already done.
> 
> The vote was not about the removal from libndi from release branches?

No, features on releases are frozen, as changing them can result in
breakages for distros and package managers. We have removed tons of
libraries before and it's always limited to git master.

The vote was to make the removal official, as stated in the first email
quoted above, since some people were not happy it was done without a
formal vote.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [DECISION] Project policy on closed source components

[Carl Eugen Hoyos]

Am Mo., 13. Mai 2019 um 22:10 Uhr schrieb Marton Balint :
>
> On Sun, 28 Apr 2019, Marton Balint wrote:
>
> > Hi All,
> >
> > There has been discussion on the mailing list several times about the
> > inclusion of support for closed source components (codecs, formats,
> > filters, etc) in the main ffmpeg codebase.
> >
> > Also the removal of libNDI happened without general consensus, so a vote
> > is necessary to justify the removal.
> >
> > So here is a call to the voting committee [1] to decide on the following
> > two questions:
> >
> > 1) Should libNDI support be removed from the ffmpeg codebase?
> >
>
> Thanks for the votes, I counted 9 yes, 5 no, so majority is for removal of
> libNDI, which is already done.

The vote was not about the removal from libndi from release branches?

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

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

Re: [FFmpeg-devel] [DECISION] Project policy on closed source components

[Marton Balint]

On Sun, 28 Apr 2019, Marton Balint wrote:


Hi All,

There has been discussion on the mailing list several times about the 
inclusion of support for closed source components (codecs, formats, 
filters, etc) in the main ffmpeg codebase.


Also the removal of libNDI happened without general consensus, so a vote 
is necessary to justify the removal.


So here is a call to the voting committee [1] to decide on the following 
two questions:


1) Should libNDI support be removed from the ffmpeg codebase?



Thanks for the votes, I counted 9 yes, 5 no, so majority is for removal of 
libNDI, which is already done.


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

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

[FFmpeg-devel] [PATCH] avformat/hcom: Remove unused variables

[Andreas Rheinhardt]

The variables huffcount, rsrc_size and data_size were all set but not
used. Therefore they have been removed.
This fixes -Wunused-but-set-variable warnings in GCC.

Signed-off-by: Andreas Rheinhardt 
---
 libavformat/hcom.c | 7 +++
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/libavformat/hcom.c b/libavformat/hcom.c
index 0d1736b620..98ed66f4f2 100644
--- a/libavformat/hcom.c
+++ b/libavformat/hcom.c
@@ -38,16 +38,15 @@ static int hcom_probe(const AVProbeData *p)
 static int hcom_read_header(AVFormatContext *s)
 {
 AVStream *st;
-unsigned data_size, rsrc_size, huffcount;
 unsigned compresstype, divisor;
 unsigned dict_entries;
 int ret;
 
 avio_skip(s->pb, 83);
-data_size = avio_rb32(s->pb);
-rsrc_size = avio_rb32(s->pb);
+avio_rb32(s->pb); /* data_size */
+avio_rb32(s->pb); /* rsrc_size */
 avio_skip(s->pb, 128-91+4);
-huffcount = avio_rb32(s->pb);
+avio_rb32(s->pb); /* huffcount */
 avio_skip(s->pb, 4);
 compresstype = avio_rb32(s->pb);
 if (compresstype > 1)
-- 
2.21.0

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

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

Re: [FFmpeg-devel] [PATCH] libavformat/utils: Interpolate missing timestamps in H264 and HEVC when no b-frames observed.

[Andriy Gelman]

Hello, 

On Mon, 13. May 12:04, Michael Niedermayer wrote:
> On Sat, May 11, 2019 at 11:20:51PM -0400, Andriy Gelman wrote:
> > From: Andriy Gelman 
> > 
> > Fixes Ticket #7895.
> > 
> > Currently, timestamp interpolation is disabled by default in H264 and
> > HEVC.  This creates playback issues when the demuxer does not output a
> > valid timestamp. This patch allows interpolation when no b-frames have
> > been observed during decoding, which fixes playback issues for some
> > missing timestamp cases.
> > ---
> >  libavformat/utils.c | 11 +--
> >  1 file changed, 9 insertions(+), 2 deletions(-)
> > 
> > diff --git a/libavformat/utils.c b/libavformat/utils.c
> > index a63d71b0f4..0668ae3ad1 100644
> > --- a/libavformat/utils.c
> > +++ b/libavformat/utils.c
> > @@ -1233,7 +1233,9 @@ static void compute_pkt_fields(AVFormatContext *s, 
> > AVStream *st,
> >  int64_t offset;
> >  AVRational duration;
> >  int onein_oneout = st->codecpar->codec_id != AV_CODEC_ID_H264 &&
> > -   st->codecpar->codec_id != AV_CODEC_ID_HEVC;
> > +   st->codecpar->codec_id != AV_CODEC_ID_HEVC ||
> > +   (!st->internal->avctx->max_b_frames &&
> 
> > +st->cur_dts != RELATIVE_TS_BASE);
> 
> This needs a comment explaining what it does. Assuming it is what i think it 
> is
> then its not completely obvious and could confuse someone working on the code
> in the future.

I added this condition so that pts/dts interpolation is skipped when the demuxer
provides no timing information. I will add the comment in the updated patch.

> >  
> >  if (s->flags & AVFMT_FLAG_NOFILLIN)
> >  return;
> > @@ -1272,6 +1274,10 @@ static void compute_pkt_fields(AVFormatContext *s, 
> > AVStream *st,
> >  delay = st->internal->avctx->has_b_frames;
> >  presentation_delayed = 0;
> >  
> > +/*update max_b_frames if delay is larger */
> > +if (delay > st->internal->avctx->max_b_frames)
> > +  st->internal->avctx->max_b_frames = delay;
> 
> do we have a testcase for this ?
> 

I can add a testcase similar to the attachment in ticket #7895, where the 
pts/dts is interpolated 
on a HEVC stream encoded with the zerolatency option. Will this be ok? 

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

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

Re: [FFmpeg-devel] [PATCH] libswcale: Fix possible string overflow in test

[Carl Eugen Hoyos]

Am Mo., 13. Mai 2019 um 20:33 Uhr schrieb Adam Richter :

> Thanks for reviewing that possible string overflow found by cppcheck
> and proposing to try to make a better fix.  I'll assume no further
> action on my part for this fix is necessary unless anyone tells me
> otherwise.

See:
http://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=9d269301

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

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

Re: [FFmpeg-devel] [PATCH] libswcale: Fix possible string overflow in test

[Adam Richter]

Hi, Michael.

Thanks for reviewing that possible string overflow found by cppcheck
and proposing to try to make a better fix.  I'll assume no further
action on my part for this fix is necessary unless anyone tells me
otherwise.

Adam


Adam

On Mon, May 13, 2019 at 4:39 AM Michael Niedermayer
 wrote:
>
> On Sun, May 12, 2019 at 05:40:00AM -0700, Adam Richter wrote:
> > This is a possible fix for a string overflow in some sscanf calls in
> > libswcale/tests/swscale.c, in the function fileTest(), found by
> > cppcheck.  Please see the attachment for more discussion of this.
> >
> > Thanks in advance for considering this patch.
> >
> > Adam
>
> >  swscale.c |4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> > 337bfa52e3917c2d896ca5c7ba1b669d5970cdab  
> > 0002-libswcale-Fix-possible-string-overflow-in-test.patch
> > From 8b5f994bcd2576588149f228695823b5cf8d3dc8 Mon Sep 17 00:00:00 2001
> > From: Adam Richter 
> > Date: Sun, 12 May 2019 05:03:25 -0700
> > Subject: [PATCH] libswcale: Fix possible string overflow in test.
> >
> > In libswcale/tests/swcale.c, the function fileTest() calls sscanf in
> > an argument of "%12s" on character srcStr[] and dstStr[], which are
> > only 12 bytes.  So, if the input string is 12 characters, a
> > terminating null byte can be written past the end of these arrays.
> >
> > This bug was found by cppcheck.
> >
> > I am not an ffmpeg or libswcale developer, and I believe that this is
> > the first patch I am submitting to ffmpeg, so please let me know if
> > I am doing anything wrong in the patch submission process.
> >
> > For the same reason, please examine this patch skeptically, especially
> > considering that I have not tested this patch other than to see that
> > it compiled without complaint and that "make fate" completed with a
> > zero exit code.  I do not know if this program actually
> > expects these input strings to be a maximum of 11 or 12 characters long.
> > In this patch, I assume that they could be 12 characters long, so I have
> > extended the array sizes, but perhaps a more correct fix might
> > be to change the "%12s" instances to "%11s" instead.
> >
> > Thanks in advance for considering this patch.
>
> I actually think 13 is not long enough for the longest name.
> Ill fix it, thanks for finding this
>
>
> [...]
>
>
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> Rewriting code that is poorly written but fully understood is good.
> Rewriting code that one doesnt understand is a sign that one is less smart
> then the original author, trying to rewrite it will not make it better.
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

[FFmpeg-devel] [PATCH] avcodec/libdav1d: fine tune thread distribution

[James Almer]

As suggested by Ronald, don't map auto threads to frame threads only, and
instead distribute them between frame and tile more efficiently.
Add a new framethreads override option, similar to the tilethreads one.

Signed-off-by: James Almer 
---
 libavcodec/libdav1d.c | 16 +---
 libavcodec/version.h  |  2 +-
 2 files changed, 14 insertions(+), 4 deletions(-)

diff --git a/libavcodec/libdav1d.c b/libavcodec/libdav1d.c
index 30c6eccfef..d173d867a7 100644
--- a/libavcodec/libdav1d.c
+++ b/libavcodec/libdav1d.c
@@ -38,6 +38,7 @@ typedef struct Libdav1dContext {
 
 Dav1dData data;
 int tile_threads;
+int frame_threads;
 int apply_grain;
 } Libdav1dContext;
 
@@ -114,6 +115,7 @@ static av_cold int libdav1d_init(AVCodecContext *c)
 {
 Libdav1dContext *dav1d = c->priv_data;
 Dav1dSettings s;
+int threads = c->thread_count ? c->thread_count : av_cpu_count();
 int res;
 
 av_log(c, AV_LOG_INFO, "libdav1d %s\n", dav1d_version());
@@ -124,9 +126,16 @@ static av_cold int libdav1d_init(AVCodecContext *c)
 s.allocator.cookie = dav1d;
 s.allocator.alloc_picture_callback = libdav1d_picture_allocator;
 s.allocator.release_picture_callback = libdav1d_picture_release;
-s.n_tile_threads = dav1d->tile_threads;
 s.apply_grain = dav1d->apply_grain;
-s.n_frame_threads = FFMIN(c->thread_count ? c->thread_count : 
av_cpu_count(), DAV1D_MAX_FRAME_THREADS);
+
+s.n_tile_threads = dav1d->tile_threads
+ ? dav1d->tile_threads
+ : FFMIN(floor(sqrt(threads)), DAV1D_MAX_TILE_THREADS);
+s.n_frame_threads = dav1d->frame_threads
+  ? dav1d->frame_threads
+  : FFMIN(ceil(threads / s.n_tile_threads), 
DAV1D_MAX_FRAME_THREADS);
+av_log(c, AV_LOG_DEBUG, "Using %d frame threads, %d tile threads\n",
+   s.n_frame_threads, s.n_tile_threads);
 
 res = dav1d_open(>c, );
 if (res < 0)
@@ -317,7 +326,8 @@ static av_cold int libdav1d_close(AVCodecContext *c)
 #define OFFSET(x) offsetof(Libdav1dContext, x)
 #define VD AV_OPT_FLAG_VIDEO_PARAM | AV_OPT_FLAG_DECODING_PARAM
 static const AVOption libdav1d_options[] = {
-{ "tilethreads", "Tile threads", OFFSET(tile_threads), AV_OPT_TYPE_INT, { 
.i64 = 1 }, 1, DAV1D_MAX_TILE_THREADS, VD },
+{ "tilethreads", "Tile threads", OFFSET(tile_threads), AV_OPT_TYPE_INT, { 
.i64 = 0 }, 0, DAV1D_MAX_TILE_THREADS, VD },
+{ "framethreads", "Frame threads", OFFSET(frame_threads), AV_OPT_TYPE_INT, 
{ .i64 = 0 }, 0, DAV1D_MAX_FRAME_THREADS, VD },
 { "filmgrain", "Apply Film Grain", OFFSET(apply_grain), AV_OPT_TYPE_BOOL, 
{ .i64 = 1 }, 0, 1, VD },
 { NULL }
 };
diff --git a/libavcodec/version.h b/libavcodec/version.h
index d11beb7885..7ed60717f0 100644
--- a/libavcodec/version.h
+++ b/libavcodec/version.h
@@ -29,7 +29,7 @@
 
 #define LIBAVCODEC_VERSION_MAJOR  58
 #define LIBAVCODEC_VERSION_MINOR  52
-#define LIBAVCODEC_VERSION_MICRO 101
+#define LIBAVCODEC_VERSION_MICRO 102
 
 #define LIBAVCODEC_VERSION_INT  AV_VERSION_INT(LIBAVCODEC_VERSION_MAJOR, \
LIBAVCODEC_VERSION_MINOR, \
-- 
2.21.0

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

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

Re: [FFmpeg-devel] [PATCH] mpeg12enc: Use all Closed Captions side data

[Carl Eugen Hoyos]

Am Mi., 10. Apr. 2019 um 13:26 Uhr schrieb Mathieu Duponchelle
:

> No problem

I don't see an updated patch.

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

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

Re: [FFmpeg-devel] [PATCH] mpeg12enc: Use all Closed Captions side data

[Mathieu Duponchelle]

Ping!

On 4/19/19 2:46 PM, Mathieu Duponchelle wrote:
> Hello ? :)
>
> On 4/10/19 1:26 PM, Mathieu Duponchelle wrote:
>> No problem, note that the added indentation is because a loop
>> was added :)
>>
>> On 4/10/19 1:14 AM, Carl Eugen Hoyos wrote:
>>> 2019-03-23 0:22 GMT+01:00, Mathieu Duponchelle :
 It is perfectly valid to have multiple CC Picture User Data
 for the same frame. Instead of using the first side_data
 potentially present with the A53_CC type, iterate over all
 side_data.
>>> Please separate the functional changes in your patch from
>>> the cosmetics, ie do not re-indent in the same patch to make
>>> reviews easier.
>>>
>>> Sorry for the late reply, Carl Eugen
>>> ___
>>> ffmpeg-devel mailing list
>>> ffmpeg-devel@ffmpeg.org
>>> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>>>
>>> To unsubscribe, visit link above, or email
>>> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
>> ___
>> ffmpeg-devel mailing list
>> ffmpeg-devel@ffmpeg.org
>> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>>
>> To unsubscribe, visit link above, or email
>> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [PATCH 2/2] avcodec/cinepak: Check available input against encoded buffer size

[Tomas Härdin]

sön 2019-05-12 klockan 23:21 +0200 skrev Michael Niedermayer:
> Fixes: Timeout (12sec -> 2sec)
> Fixes: 
> 14606/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_CINEPAK_fuzzer-5738687561728000
> 
> Found-by: continuous fuzzing process 
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> > Signed-off-by: Michael Niedermayer 
> ---
>  libavcodec/cinepak.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/libavcodec/cinepak.c b/libavcodec/cinepak.c
> index a5132ddbc0..aeb15de0ed 100644
> --- a/libavcodec/cinepak.c
> +++ b/libavcodec/cinepak.c
> @@ -323,6 +323,9 @@ static int cinepak_predecode_check (CinepakContext *s)
>  num_strips  = AV_RB16 (>data[8]);
>  encoded_buf_size = AV_RB24(>data[1]);
>  
> +if (s->size < encoded_buf_size * (int64_t)(100 - 
> s->avctx->discard_damaged_percentage) / 100)
> +return AVERROR_INVALIDDATA;

Looks OK

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

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

Re: [FFmpeg-devel] [PATCH] avformat/mxfenc: support XAVC long gop

[Tomas Härdin]

sön 2019-05-12 klockan 18:03 +0100 skrev Mark Thompson:
> On 12/05/2019 14:47, Tomas Härdin wrote:
> > fre 2019-05-10 klockan 08:50 -0700 skrev Baptiste Coudurier:
> > > ...
> > > +skip_bits(, 2); // reserved_zero_2bits
> > > +sps->level_idc = get_bits(, 8);
> > > +sps->id = get_ue_golomb();
> > > +
> > > +if (sps->profile_idc == 100 || sps->profile_idc == 110 ||
> > > +sps->profile_idc == 122 || sps->profile_idc == 244 || 
> > > sps->profile_idc ==  44 ||
> > > +sps->profile_idc ==  83 || sps->profile_idc ==  86 || 
> > > sps->profile_idc == 118 ||
> > > +sps->profile_idc == 128 || sps->profile_idc == 138 || 
> > > sps->profile_idc == 139 ||
> > > +sps->profile_idc == 134) {
> > 
> > Maybe put these in a table instead? I guess it works this way, just a
> > bit verbose. They could do with sorting, unless there's a specific
> > reason for this ordering
> 
> This is exactly how it appears in the standard (see section
> 7.3.2.1.1).  IMO it's better to match that exactly than to do
> something else.

Fair enough

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

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

Re: [FFmpeg-devel] [PATCH] avfilter: add xmedian filter

[Paul B Mahol]

On 5/3/19, Paul B Mahol  wrote:
> Signed-off-by: Paul B Mahol 
> ---
>  doc/filters.texi |  11 ++
>  libavfilter/Makefile |   1 +
>  libavfilter/allfilters.c |   1 +
>  libavfilter/vf_xmedian.c | 325 +++
>  4 files changed, 338 insertions(+)
>  create mode 100644 libavfilter/vf_xmedian.c

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

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

[FFmpeg-devel] [PATCH] ffplay: added option always on top for video window

[Daniel Kucera]

From: Daniel Kucera 

Signed-off-by: Daniel Kucera 
---
 doc/ffplay.texi  | 2 ++
 fftools/ffplay.c | 8 
 2 files changed, 10 insertions(+)

diff --git a/doc/ffplay.texi b/doc/ffplay.texi
index c305465078..a487c0de8d 100644
--- a/doc/ffplay.texi
+++ b/doc/ffplay.texi
@@ -66,6 +66,8 @@ Set custom interval, in seconds, for seeking using left/right 
keys. Default is 1
 Disable graphical display.
 @item -noborder
 Borderless window.
+@item -alwaysontop
+Window always on top. Available on: X11 with SDL >= 2.0.5, Windows SDL >= 
2.0.6.
 @item -volume
 Set the startup volume. 0 means silence, 100 means no volume reduction or
 amplification. Negative values are treated as 0, values above 100 are treated
diff --git a/fftools/ffplay.c b/fftools/ffplay.c
index 8f050e16e6..8fb8faeb06 100644
--- a/fftools/ffplay.c
+++ b/fftools/ffplay.c
@@ -324,6 +324,7 @@ static int seek_by_bytes = -1;
 static float seek_interval = 10;
 static int display_disable;
 static int borderless;
+static int alwaysontop;
 static int startup_volume = 100;
 static int show_status = 1;
 static int av_sync_type = AV_SYNC_AUDIO_MASTER;
@@ -3581,6 +3582,7 @@ static const OptionDef options[] = {
 { "seek_interval", OPT_FLOAT | HAS_ARG, { _interval }, "set seek 
interval for left/right keys, in seconds", "seconds" },
 { "nodisp", OPT_BOOL, { _disable }, "disable graphical display" },
 { "noborder", OPT_BOOL, {  }, "borderless window" },
+{ "alwaysontop", OPT_BOOL, {  }, "window always on top" },
 { "volume", OPT_INT | HAS_ARG, { _volume}, "set startup volume 
0=min 100=max", "volume" },
 { "f", HAS_ARG, { .func_arg = opt_format }, "force format", "fmt" },
 { "pix_fmt", HAS_ARG | OPT_EXPERT | OPT_VIDEO, { .func_arg = 
opt_frame_pix_fmt }, "set pixel format", "format" },
@@ -3722,6 +3724,12 @@ int main(int argc, char **argv)
 
 if (!display_disable) {
 int flags = SDL_WINDOW_HIDDEN;
+if (alwaysontop)
+#if SDL_VERSION_ATLEAST(2,0,5)
+flags |= SDL_WINDOW_ALWAYS_ON_TOP;
+#else
+av_log(NULL, AV_LOG_WARNING, "Your SDL version doesn't support 
SDL_WINDOW_ALWAYS_ON_TOP. Feature will be inactive.\n");
+#endif
 if (borderless)
 flags |= SDL_WINDOW_BORDERLESS;
 else
-- 
2.17.1

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

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

Re: [FFmpeg-devel] [PATCH] libswcale: Fix possible string overflow in test

[Michael Niedermayer]

On Sun, May 12, 2019 at 05:40:00AM -0700, Adam Richter wrote:
> This is a possible fix for a string overflow in some sscanf calls in
> libswcale/tests/swscale.c, in the function fileTest(), found by
> cppcheck.  Please see the attachment for more discussion of this.
> 
> Thanks in advance for considering this patch.
> 
> Adam

>  swscale.c |4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 337bfa52e3917c2d896ca5c7ba1b669d5970cdab  
> 0002-libswcale-Fix-possible-string-overflow-in-test.patch
> From 8b5f994bcd2576588149f228695823b5cf8d3dc8 Mon Sep 17 00:00:00 2001
> From: Adam Richter 
> Date: Sun, 12 May 2019 05:03:25 -0700
> Subject: [PATCH] libswcale: Fix possible string overflow in test.
> 
> In libswcale/tests/swcale.c, the function fileTest() calls sscanf in
> an argument of "%12s" on character srcStr[] and dstStr[], which are
> only 12 bytes.  So, if the input string is 12 characters, a
> terminating null byte can be written past the end of these arrays.
> 
> This bug was found by cppcheck.
> 
> I am not an ffmpeg or libswcale developer, and I believe that this is
> the first patch I am submitting to ffmpeg, so please let me know if
> I am doing anything wrong in the patch submission process.
> 
> For the same reason, please examine this patch skeptically, especially
> considering that I have not tested this patch other than to see that
> it compiled without complaint and that "make fate" completed with a
> zero exit code.  I do not know if this program actually
> expects these input strings to be a maximum of 11 or 12 characters long.
> In this patch, I assume that they could be 12 characters long, so I have
> extended the array sizes, but perhaps a more correct fix might
> be to change the "%12s" instances to "%11s" instead.
> 
> Thanks in advance for considering this patch.

I actually think 13 is not long enough for the longest name.
Ill fix it, thanks for finding this


[...]


-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Rewriting code that is poorly written but fully understood is good.
Rewriting code that one doesnt understand is a sign that one is less smart
then the original author, trying to rewrite it will not make it better.


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

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

Re: [FFmpeg-devel] [PATCH v2] libavutil: add an FFT & MDCT implementation

[Paul B Mahol]

On 5/13/19, Carl Eugen Hoyos  wrote:
> Am Mo., 13. Mai 2019 um 13:31 Uhr schrieb Paul B Mahol :
>>
>> On 5/13/19, Carl Eugen Hoyos  wrote:
>> > Am Mo., 13. Mai 2019 um 13:24 Uhr schrieb Lynne :
>> >
>> >> I'll ignore Carl's messages for now as I agree with the others that
>> >> authorship is always
>> >> preserved through git history.
>> >
>> >> If he disagrees then it becomes a project-wide issue as
>> >> copyright headers have sometimes not been preserved through
>> >> refactoring.
>> >
>> > Sorry, I forgot: Mistakes can always happen.
>> > In this case though, we all agree that a code that was committed with a
>> > copyright notice gets moved.
>> >
>> >> I can give examples _in_another_thread_.
>>
>> I have myriad examples.
>
> Please point us to them: It is important that we fix
> such issues if we get informed.
>

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

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

Re: [FFmpeg-devel] [PATCH v2] libavutil: add an FFT & MDCT implementation

[Carl Eugen Hoyos]

Am Mo., 13. Mai 2019 um 13:31 Uhr schrieb Paul B Mahol :
>
> On 5/13/19, Carl Eugen Hoyos  wrote:
> > Am Mo., 13. Mai 2019 um 13:24 Uhr schrieb Lynne :
> >
> >> I'll ignore Carl's messages for now as I agree with the others that
> >> authorship is always
> >> preserved through git history.
> >
> >> If he disagrees then it becomes a project-wide issue as
> >> copyright headers have sometimes not been preserved through refactoring.
> >
> > Sorry, I forgot: Mistakes can always happen.
> > In this case though, we all agree that a code that was committed with a
> > copyright notice gets moved.
> >
> >> I can give examples _in_another_thread_.
>
> I have myriad examples.

Please point us to them: It is important that we fix
such issues if we get informed.

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

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

Re: [FFmpeg-devel] [PATCH v2] libavutil: add an FFT & MDCT implementation

[Paul B Mahol]

On 5/13/19, Carl Eugen Hoyos  wrote:
> Am Mo., 13. Mai 2019 um 13:24 Uhr schrieb Lynne :
>
>> I'll ignore Carl's messages for now as I agree with the others that
>> authorship is always
>> preserved through git history.
>
>> If he disagrees then it becomes a project-wide issue as
>> copyright headers have sometimes not been preserved through refactoring.
>
> Sorry, I forgot: Mistakes can always happen.
> In this case though, we all agree that a code that was committed with a
> copyright notice gets moved.
>
>> I can give examples _in_another_thread_.
>

I have myriad examples.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [PATCH v2] libavutil: add an FFT & MDCT implementation

[Carl Eugen Hoyos]

Am Mo., 13. Mai 2019 um 13:24 Uhr schrieb Lynne :

> I'll ignore Carl's messages for now as I agree with the others that 
> authorship is always
> preserved through git history.

> If he disagrees then it becomes a project-wide issue as
> copyright headers have sometimes not been preserved through refactoring.

Sorry, I forgot: Mistakes can always happen.
In this case though, we all agree that a code that was committed with a
copyright notice gets moved.

> I can give examples _in_another_thread_.

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

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

Re: [FFmpeg-devel] [PATCH v2] libavutil: add an FFT & MDCT implementation

[Paul B Mahol]

On 5/13/19, Carl Eugen Hoyos  wrote:
> Am Mo., 13. Mai 2019 um 13:24 Uhr schrieb Lynne :
>
>> I'll ignore Carl's messages for now as I agree with the others that
>> authorship is always
>> preserved through git history.
>
> This is not the question here.
>
>> If he disagrees then it becomes a project-wide issue as
>> copyright headers have sometimes not been preserved through refactoring. I
>> can give
>> examples _in_another_thread_.
>
> Please do, I would like to fix them.
>
> Please understand that your current patch cannot be committed, the reason
> is that the push would be a copyright violation.
>

Please, stop writing nonsense.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [PATCH v2] libavutil: add an FFT & MDCT implementation

[Carl Eugen Hoyos]

Am Mo., 13. Mai 2019 um 13:24 Uhr schrieb Lynne :

> I'll ignore Carl's messages for now as I agree with the others that 
> authorship is always
> preserved through git history.

This is not the question here.

> If he disagrees then it becomes a project-wide issue as
> copyright headers have sometimes not been preserved through refactoring. I 
> can give
> examples _in_another_thread_.

Please do, I would like to fix them.

Please understand that your current patch cannot be committed, the reason
is that the push would be a copyright violation.

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

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

[FFmpeg-devel] [PATCH] libavfilter/vf_scale_cuda: fix src_pitch for 10bit videos

[Sergey Svechnikov]

When scaling a 10bit video using scale_cuda filter (witch uses pixel format 
AV_PIX_FMT_P010LE), the output video gets distorted.
I think it has something to do with the differences in processing between 
cuda_sdk and ffnvcodec with cuda_nvcc
(the problem appears after this commit 
https://github.com/FFmpeg/FFmpeg/commit/2544c7ea67ca9521c5de36396bc9ac7058223742).
To solve the problem we should not divide the input frame planes' linesizes by 
2 and leave them as they are.
More info, samples and reproduction steps are here 
https://github.com/Svechnikov/ffmpeg-scale-cuda-10bit-problem
---
 libavfilter/vf_scale_cuda.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/libavfilter/vf_scale_cuda.c b/libavfilter/vf_scale_cuda.c
index c97a802..7fc33ee 100644
--- a/libavfilter/vf_scale_cuda.c
+++ b/libavfilter/vf_scale_cuda.c
@@ -423,11 +423,11 @@ static int scalecuda_resize(AVFilterContext *ctx,
 break;
 case AV_PIX_FMT_P010LE:
 call_resize_kernel(ctx, s->cu_func_ushort, 1,
-   in->data[0], in->width, in->height, 
in->linesize[0]/2,
+   in->data[0], in->width, in->height, in->linesize[0],
out->data[0], out->width, out->height, 
out->linesize[0]/2,
2);
 call_resize_kernel(ctx, s->cu_func_ushort2, 2,
-   in->data[1], in->width / 2, in->height / 2, 
in->linesize[1]/2,
+   in->data[1], in->width / 2, in->height / 2, 
in->linesize[1],
out->data[0] + out->linesize[0] * ((out->height + 
31) & ~0x1f), out->width / 2, out->height / 2, out->linesize[1] / 4,
2);
 break;
-- 
2.7.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [PATCH v2] libavutil: add an FFT & MDCT implementation

[Lynne]

May 13, 2019, 9:53 AM by one...@gmail.com:

> On 5/13/19, Carl Eugen Hoyos <> ceffm...@gmail.com 
> > > wrote:
>
>> Am Mo., 13. Mai 2019 um 00:55 Uhr schrieb James Almer <>> jamr...@gmail.com 
>> >> >:
>>
>>>
>>> On 5/12/2019 7:42 PM, Carl Eugen Hoyos wrote:
>>> > Am So., 12. Mai 2019 um 23:58 Uhr schrieb Lynne <>>> d...@lynne.ee 
>>> > :
>>> >> I need *technical* feedback about the API.
>>> >
>>> > I understand that.
>>>
>>> Then, if you can't provide technical feedback, please stop replying
>>> to this thread (After you provide the source Hendrik requested).
>>>
>>
>> Could you please stop this?
>>
>> It doesn't matter where you live, and it doesn't matter which license
>> you use, you are not allowed to remove a copyright statement that
>> was put on top of a source file.
>>
>> It is arguably not always as clear as in this case, but since it was
>> explained where the code comes from, there is really no question
>> about this.
>>
>
> Do we need yet another voting for this one?
>

Please do, then this thread can be left alone and I can get some actual 
feedback.

I'll ignore Carl's messages for now as I agree with the others that authorship 
is always
preserved through git history. If he disagrees then it becomes a project-wide 
issue as
copyright headers have sometimes not been preserved through refactoring. I can 
give
examples _in_another_thread_.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [PATCH] ffplay: added option always on top for video window

[Carl Eugen Hoyos]

Am Mo., 13. Mai 2019 um 11:00 Uhr schrieb Daniel Kucera
:

> +#ifdef SDL_WINDOW_ALWAYS_ON_TOP
> +{ "alwaysontop", OPT_BOOL, {  }, "window always on top" },
> +#endif

You could remove the condition here...

>  { "volume", OPT_INT | HAS_ARG, { _volume}, "set startup volume 
> 0=min 100=max", "volume" },
>  { "f", HAS_ARG, { .func_arg = opt_format }, "force format", "fmt" },
>  { "pix_fmt", HAS_ARG | OPT_EXPERT | OPT_VIDEO, { .func_arg = 
> opt_frame_pix_fmt }, "set pixel format", "format" },
> @@ -3722,6 +3726,10 @@ int main(int argc, char **argv)
>
>  if (!display_disable) {
>  int flags = SDL_WINDOW_HIDDEN;
> +#ifdef SDL_WINDOW_ALWAYS_ON_TOP
> +if (alwaysontop)
> +flags |= SDL_WINDOW_ALWAYS_ON_TOP;

... and add an #else here with a warning message to reduce confusion.
(and switch lines "#ifdef" and "if (alwaysontop)")

> +#endif

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

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

Re: [FFmpeg-devel] [PATCH] libavformat/utils: Interpolate missing timestamps in H264 and HEVC when no b-frames observed.

[Michael Niedermayer]

On Sat, May 11, 2019 at 11:20:51PM -0400, Andriy Gelman wrote:
> From: Andriy Gelman 
> 
> Fixes Ticket #7895.
> 
> Currently, timestamp interpolation is disabled by default in H264 and
> HEVC.  This creates playback issues when the demuxer does not output a
> valid timestamp. This patch allows interpolation when no b-frames have
> been observed during decoding, which fixes playback issues for some
> missing timestamp cases.
> ---
>  libavformat/utils.c | 11 +--
>  1 file changed, 9 insertions(+), 2 deletions(-)
> 
> diff --git a/libavformat/utils.c b/libavformat/utils.c
> index a63d71b0f4..0668ae3ad1 100644
> --- a/libavformat/utils.c
> +++ b/libavformat/utils.c
> @@ -1233,7 +1233,9 @@ static void compute_pkt_fields(AVFormatContext *s, 
> AVStream *st,
>  int64_t offset;
>  AVRational duration;
>  int onein_oneout = st->codecpar->codec_id != AV_CODEC_ID_H264 &&
> -   st->codecpar->codec_id != AV_CODEC_ID_HEVC;
> +   st->codecpar->codec_id != AV_CODEC_ID_HEVC ||
> +   (!st->internal->avctx->max_b_frames &&

> +st->cur_dts != RELATIVE_TS_BASE);

This needs a comment explaining what it does. Assuming it is what i think it is
then its not completely obvious and could confuse someone working on the code
in the future.


>  
>  if (s->flags & AVFMT_FLAG_NOFILLIN)
>  return;
> @@ -1272,6 +1274,10 @@ static void compute_pkt_fields(AVFormatContext *s, 
> AVStream *st,
>  delay = st->internal->avctx->has_b_frames;
>  presentation_delayed = 0;
>  
> +/*update max_b_frames if delay is larger */
> +if (delay > st->internal->avctx->max_b_frames)
> +  st->internal->avctx->max_b_frames = delay;

do we have a testcase for this ?

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

If you fake or manipulate statistics in a paper in physics you will never
get a job again.
If you fake or manipulate statistics in a paper in medicin you will get
a job for life at the pharma industry.


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

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

Re: [FFmpeg-devel] [PATCH v1] fftools/ffmpeg: Add support for per frame rotation and flip

[Michael Niedermayer]

On Sat, May 11, 2019 at 10:57:01PM -0700, Jun Li wrote:
> On Sat, May 11, 2019 at 10:47 PM Jun Li  wrote:
> 
> > Fix #6945
> > Current implementaion for autorotate works fine for stream
> > level rotataion but no support for frame level operation
> > and frame flip. This patch is for adding flip support and
> > per frame operations.
> > ---
> >  fftools/cmdutils.c|  9 ++---
> >  fftools/cmdutils.h|  2 +-
> >  fftools/ffmpeg.c  | 21 +-
> >  fftools/ffmpeg.h  |  2 +
> >  fftools/ffmpeg_filter.c   | 81 ---
> >  fftools/ffplay.c  | 28 +++---
> >  libavutil/display.c   | 14 +++
> >  libavutil/display.h   | 14 +++
> >  libavutil/tests/display.c |  8 
> >  tests/ref/fate/display|  4 ++
> >  10 files changed, 166 insertions(+), 17 deletions(-)
[...]

> > \ No newline at end of file

> > diff --git a/libavutil/display.h b/libavutil/display.h
> > index 515adad795..23d71a0bc5 100644
> > --- a/libavutil/display.h
> > +++ b/libavutil/display.h
> > @@ -106,6 +106,20 @@ void av_display_rotation_set(int32_t matrix[9],
> > double angle);
> >   */
> >  void av_display_matrix_flip(int32_t matrix[9], int hflip, int vflip);
> >
> > +/**
> > + * Extract the rotation component and hflip status of the transformation
> > matrix.
> > + *
> > + * @param matrix the transformation matrix
> > + * @param hflip wille be set to 1 if the matrix need horizontal flipped
> > + * @return the angle (in degrees) by which the transformation rotates the
> > frame
> > + * counterclockwise. The angle will be in range [-180.0, 180.0],
> > + * or NaN if the matrix is singular.
> > + *
> > + * @note floating point numbers are inherently inexact, so callers are
> > + *   recommended to round the return value to nearest integer before
> > use.
> > + */
> > +double av_display_rotation_hflip_get(const int32_t matrix[9], int* hflip);
> > +
> >  /**
> >   * @}
> >   * @}
> > diff --git a/libavutil/tests/display.c b/libavutil/tests/display.c
> > index 893ebb5543..65a0971e7b 100644
> > --- a/libavutil/tests/display.c
> > +++ b/libavutil/tests/display.c
> > @@ -35,6 +35,8 @@ static void print_matrix(int32_t matrix[9])
> >  int main(void)
> >  {
> >  int32_t matrix[9];
> > +int hflip = 0;
> > +double degree;
> >
> >  // Set the matrix to 90 degrees
> >  av_display_rotation_set(matrix, 90);
> > @@ -56,6 +58,12 @@ int main(void)
> >  print_matrix(matrix);
> >  printf("degrees: %f\n", av_display_rotation_get(matrix));
> >
> > +// flip vertical
> > +av_display_matrix_flip(matrix, 0, 1);
> > +print_matrix(matrix);
> > +degree = av_display_rotation_hflip_get(matrix, );
> > +printf("degrees: %f, hflip: %i\n", degree, hflip);
> > +
> >  return 0;
> >
> >  }

[...]

> This change is to address the feedback of last patch using 1st frame's
> orientation as stream rotation.
> Thanks again for review. I added the support for per frame rotation.
> 
> (I know it involves too many file changes and not easy to read. Sorry about
> that I tried to
>  separate them but failed since due to some dependencies).

The libavutil changes should be in a seperate patch and need a version
and APIChanges update

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

If a bugfix only changes things apparently unrelated to the bug with no
further explanation, that is a good sign that the bugfix is wrong.


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

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

Re: [FFmpeg-devel] [PATCH 1/2] VP4 video decoder

[Peter Ross]

On Sun, May 12, 2019 at 10:20:19AM -0300, James Almer wrote:
> On 5/12/2019 3:12 AM, Peter Ross wrote:
> > ---
> > i have incorporated all suggestions from the first patch posted jan 2019.
> > 
> > if there's nothing further to change, i will apply it a good week or so.
> > 
> > cheers,
> > 
> > 
> >  Changelog   |1 +
> >  doc/general.texi|2 +
> >  libavcodec/allcodecs.c  |1 +
> >  libavcodec/avcodec.h|1 +
> >  libavcodec/codec_desc.c |7 +
> >  libavcodec/vp3.c|  718 +++-
> >  libavcodec/vp4data.h| 3784 +++
> >  7 files changed, 4478 insertions(+), 36 deletions(-)
> >  create mode 100644 libavcodec/vp4data.h
> 
> As Carl mentioned, this is missing a vp4_decoder_select line in
> configure to enable the vp3 decoder, like the theora one does. There's
> nothing telling the build system what objects are required for this new
> decoder otherwise.
> 
> Did you make sure Theora samples are unaffected? Those afaik are much
> more common in the wild than vp3. Wikimedia is full of them.

Unaffected :) I have tested this throughout development.

> Also, if you have distributable vp4 samples at hand, you should make at
> least one fate decoding test.

Shall do. I have no interesting content. Synthetic tests streams will have to 
suffice.

-- Peter
(A907 E02F A6E5 0CD2 34CD 20D2 6760 79C5 AC40 DD6B)


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

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

Re: [FFmpeg-devel] [PATCH 1/2] VP4 video decoder

[Peter Ross]

On Sun, May 12, 2019 at 12:49:03PM +0200, Carl Eugen Hoyos wrote:
> Am So., 12. Mai 2019 um 08:12 Uhr schrieb Peter Ross :
> 
> > i have incorporated all suggestions from the first patch posted jan 2019.
> >
> > if there's nothing further to change, i will apply it a good week or so.
> >
> > cheers,
> >
> >
> >  Changelog   |1 +
> >  doc/general.texi|2 +
> >  libavcodec/allcodecs.c  |1 +
> >  libavcodec/avcodec.h|1 +
> >  libavcodec/codec_desc.c |7 +
> >  libavcodec/vp3.c|  718 +++-
> >  libavcodec/vp4data.h| 3784 +++
> >  7 files changed, 4478 insertions(+), 36 deletions(-)
> 
> This looks to me as if a line in either configure or Makefile is missing to 
> fix
> building with "--disable-everything --enable-decoder=vp4".

Fixed. Thanks.

-- Peter
(A907 E02F A6E5 0CD2 34CD 20D2 6760 79C5 AC40 DD6B)


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

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

Re: [FFmpeg-devel] [PATCH 1/2] VP4 video decoder

[Peter Ross]

On Sun, May 12, 2019 at 09:41:40AM +0200, Paul B Mahol wrote:
> On 5/12/19, Peter Ross  wrote:
> > ---
> > i have incorporated all suggestions from the first patch posted jan 2019.
> >
> > if there's nothing further to change, i will apply it a good week or so.
> >
> > cheers,
> >
> >
> >  Changelog   |1 +
> >  doc/general.texi|2 +
> >  libavcodec/allcodecs.c  |1 +
> >  libavcodec/avcodec.h|1 +
> >  libavcodec/codec_desc.c |7 +
> >  libavcodec/vp3.c|  718 +++-
> >  libavcodec/vp4data.h| 3784 +++
> >  7 files changed, 4478 insertions(+), 36 deletions(-)
> >  create mode 100644 libavcodec/vp4data.h
> >
> > diff --git a/Changelog b/Changelog
> > index 36a04872fd..8af9006ec0 100644
> > --- a/Changelog
> > +++ b/Changelog
> > @@ -28,6 +28,7 @@ version :
> >  - asoftclip filter
> >  - Support decoding of HEVC 4:4:4 content in vdpau
> >  - colorhold filter
> > +- VP4 video decoder


> > diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
> > index b749946633..148c63bb89 100644
> > --- a/libavcodec/avcodec.h
> > +++ b/libavcodec/avcodec.h
> > @@ -410,6 +410,7 @@ enum AVCodecID {
> >  AV_CODEC_ID_SCREENPRESSO,
> >  AV_CODEC_ID_RSCC,
> >  AV_CODEC_ID_AVS2,
> > +AV_CODEC_ID_VP4,
> >
> 
> This can not be here.

Fixed.

> > +++ b/libavcodec/vp4data.h
> > @@ -0,0 +1,3784 @@
> > +/*
> > + * Copyright (C) 2019 Peter Ross
> > + *
> > + * 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.
> > + *

> > +{ 0x19B3, 14 },
> > +{ 0x19B2, 14 },
> > +{   0x47,  8 },
> > +{   0x8C,  9 },
> > +{  0x337, 11 },
> > +{   0x67,  8 },
> > +{   0x18,  6 },
> > +{   0x10,  6 },
> > +{   0x32,  7 },
> > +{  0xCD5, 13 },
> > +{  0xCD4, 13 }
> > +}
> > +};
> 
> Also those tables takes too much lines.

Agree. It was originally done that way to find patterns from other tables.

I will squish them down.

> 
> Also you need real review.

Every bit helps. Thanks Paul.

-- Peter
(A907 E02F A6E5 0CD2 34CD 20D2 6760 79C5 AC40 DD6B)


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

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

Re: [FFmpeg-devel] [PATCH] ffplay: added option always on top for video window

[Daniel Kučera]

>
> I can at least confirm that 2.0.4, which I have installed on one
> machine, doesn't define this in the provided headers, and that ffmpeg
> doesn't build against 2.0.4 with this patch. So there should be an
> #ifdef SDL_WINDOW_ALWAYS_ON_TOP guard around this, and possibly around
> the options definition. (And the docs should mention it?)
>
> https://hg.libsdl.org/SDL/annotate/3beca914a2ad/include/SDL_video.h
>
> Not sure how Windows behaves if compiled against 2.0.5 with
> availability of the flag, but not the feature. ;-) [*]
>
> BTW, would this also be an option which could go into the "sdl2" output
> device? (I'm not happy with separate code bases for these, personally.)
>
> Moritz
>

Thanks Moritz, I submited a new patch according to your
recommendations. This patch compiles with 2.0.5 on Windows but doesn't
have any effect (tested). I updated the docs to make this clear.

Regarding libavdevice/sdl2 - this doesn't share the implementation of
windows creation (which is shame) so this is a separate task to
implement.

-- 

S pozdravom / Best regards
Daniel Kucera.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

[FFmpeg-devel] [PATCH] ffplay: added option always on top for video window

[Daniel Kucera]

From: Daniel Kucera 

Signed-off-by: Daniel Kucera 
---
 doc/ffplay.texi  | 2 ++
 fftools/ffplay.c | 8 
 2 files changed, 10 insertions(+)

diff --git a/doc/ffplay.texi b/doc/ffplay.texi
index c305465078..a487c0de8d 100644
--- a/doc/ffplay.texi
+++ b/doc/ffplay.texi
@@ -66,6 +66,8 @@ Set custom interval, in seconds, for seeking using left/right 
keys. Default is 1
 Disable graphical display.
 @item -noborder
 Borderless window.
+@item -alwaysontop
+Window always on top. Available on: X11 with SDL >= 2.0.5, Windows SDL >= 
2.0.6.
 @item -volume
 Set the startup volume. 0 means silence, 100 means no volume reduction or
 amplification. Negative values are treated as 0, values above 100 are treated
diff --git a/fftools/ffplay.c b/fftools/ffplay.c
index 8f050e16e6..2af5f0386a 100644
--- a/fftools/ffplay.c
+++ b/fftools/ffplay.c
@@ -324,6 +324,7 @@ static int seek_by_bytes = -1;
 static float seek_interval = 10;
 static int display_disable;
 static int borderless;
+static int alwaysontop;
 static int startup_volume = 100;
 static int show_status = 1;
 static int av_sync_type = AV_SYNC_AUDIO_MASTER;
@@ -3581,6 +3582,9 @@ static const OptionDef options[] = {
 { "seek_interval", OPT_FLOAT | HAS_ARG, { _interval }, "set seek 
interval for left/right keys, in seconds", "seconds" },
 { "nodisp", OPT_BOOL, { _disable }, "disable graphical display" },
 { "noborder", OPT_BOOL, {  }, "borderless window" },
+#ifdef SDL_WINDOW_ALWAYS_ON_TOP
+{ "alwaysontop", OPT_BOOL, {  }, "window always on top" },
+#endif
 { "volume", OPT_INT | HAS_ARG, { _volume}, "set startup volume 
0=min 100=max", "volume" },
 { "f", HAS_ARG, { .func_arg = opt_format }, "force format", "fmt" },
 { "pix_fmt", HAS_ARG | OPT_EXPERT | OPT_VIDEO, { .func_arg = 
opt_frame_pix_fmt }, "set pixel format", "format" },
@@ -3722,6 +3726,10 @@ int main(int argc, char **argv)
 
 if (!display_disable) {
 int flags = SDL_WINDOW_HIDDEN;
+#ifdef SDL_WINDOW_ALWAYS_ON_TOP
+if (alwaysontop)
+flags |= SDL_WINDOW_ALWAYS_ON_TOP;
+#endif
 if (borderless)
 flags |= SDL_WINDOW_BORDERLESS;
 else
-- 
2.17.1

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

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

Re: [FFmpeg-devel] [PATCH v2] libavutil: add an FFT & MDCT implementation

[Paul B Mahol]

On 5/13/19, Carl Eugen Hoyos  wrote:
> Am Mo., 13. Mai 2019 um 00:55 Uhr schrieb James Almer :
>>
>> On 5/12/2019 7:42 PM, Carl Eugen Hoyos wrote:
>> > Am So., 12. Mai 2019 um 23:58 Uhr schrieb Lynne :
>> >> I need *technical* feedback about the API.
>> >
>> > I understand that.
>>
>> Then, if you can't provide technical feedback, please stop replying
>> to this thread (After you provide the source Hendrik requested).
>
> Could you please stop this?
>
> It doesn't matter where you live, and it doesn't matter which license
> you use, you are not allowed to remove a copyright statement that
> was put on top of a source file.
>
> It is arguably not always as clear as in this case, but since it was
> explained where the code comes from, there is really no question
> about this.

Do we need yet another voting for this one?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [PATCH v2] libavutil: add an FFT & MDCT implementation

[Hendrik Leppkes]

On Mon, May 13, 2019 at 8:57 AM Reimar Döffinger
 wrote:
>
> On 13.05.2019, at 04:54, Pedro Arthur  wrote:
>
> > Em dom, 12 de mai de 2019 às 18:11, Hendrik Leppkes
> >  escreveu:
> >>
> >> On Sun, May 12, 2019 at 11:05 PM Carl Eugen Hoyos  
> >> wrote:
> >>>
> >>> But seriously: We are of course not allowed to remove copyright
> >>> statements, no matter if we consider them relevant or not.
> >>>
> >>
> >> Please provide a source for such claims.
> > The GPL license included in the header states that.
> >
> > GPL2 [1] - "keep intact all the notices that refer to this License"
> > GPL3 [2]  - "Requiring preservation of specified reasonable legal
> > notices or author attributions in that material"
> > MIT [3] (for completeness) - "The above copyright notice and this
> > permission notice shall be included in all copies or substantial
> > portions of the Software."
> >
> > [1] - https://www.gnu.org/licenses/old-licenses/gpl-2.0.html
> > [2] - http://www.gnu.org/licenses/gpl.html
> > [3] - https://opensource.org/licenses/MI
>
> Besides the direct legals and ethics of it, please note that it also creates a
> serious (even if unlikely) risk to us and our users.
> In any kind of legal case, whether to defend against some "copyright troll" 
> or to
> enforce the license it might become necessary to find the author of the code.
> Not properly taking care of the license and copyright statement side exposes 
> our
> users to unnecessary risk and makes it harder to enforce our license.
> Even if nothing happens, the work companies have to do to show compliance
> (because their customers require it or to reduce their risk) becomes much 
> harder.
> Which is why the Linux kernel currently is working on cleaning up their 
> license
> header mess.
>

This argument is not really applicable because the headers do not
actually let you identify who holds all the copyright over the code in
the file. You need to go dig through years of Git history.

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

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

Re: [FFmpeg-devel] [PATCH] "assert(a && b)" --> "assert(a); assert(b)" for more precise diagnostics, except for libformat

[Michael Niedermayer]

On Sun, May 12, 2019 at 08:24:11AM -0700, Adam Richter wrote:
> This patch separates statements of the form "assert(a && b);" into
> "assert(a);" and "assert(b);", typically involving an assertion
> function like av_assert0.
> 
> This patch covers all of ffmpeg, except for the libavformat, which I
> have already submitted separately.
> 
> I have not tested this patch other than observing that ffmpeg still
> builds without any apparent new complaints, that no complaints in the
> build contain "assert", and that "make fate" seems to succeed.
> 
> Thanks in advance for considering the attached patch.
> 
> Adam

>  fftools/cmdutils.c|3 +-
>  fftools/ffmpeg.c  |3 +-
>  libavcodec/4xm.c  |   12 ++---
>  libavcodec/aaccoder_twoloop.h |3 +-
>  libavcodec/aacenc.c   |3 +-
>  libavcodec/aacenc_quantization_misc.h |3 +-
>  libavcodec/aacpsy.c   |6 +++-
>  libavcodec/ac3enc.c   |   15 
>  libavcodec/acelp_filters.c|3 +-
>  libavcodec/amfenc.c   |5 ++--
>  libavcodec/amrnbdec.c |3 +-
>  libavcodec/av1_frame_split_bsf.c  |3 +-
>  libavcodec/avpacket.c |3 +-
>  libavcodec/cbs.c  |   42 
> ++
>  libavcodec/cbs_av1.c  |9 ---
>  libavcodec/cbs_av1_syntax_template.c  |3 +-
>  libavcodec/cbs_h2645.c|   10 
>  libavcodec/cbs_mpeg2.c|4 +--
>  libavcodec/cbs_vp9.c  |8 --
>  libavcodec/celp_filters.c |3 +-
>  libavcodec/dca_core.c |3 +-
>  libavcodec/decode.c   |4 +--
>  libavcodec/dvdsubdec.c|3 +-
>  libavcodec/dvenc.c|3 +-
>  libavcodec/dxva2_h264.c   |3 +-
>  libavcodec/dxva2_hevc.c   |3 +-
>  libavcodec/dxva2_vp9.c|3 +-
>  libavcodec/error_resilience.c |3 +-
>  libavcodec/ffv1dec.c  |3 +-
>  libavcodec/flacenc.c  |6 +++-
>  libavcodec/get_bits.h |   35 +++-
>  libavcodec/h263dec.c  |3 +-
>  libavcodec/h2645_parse.c  |6 +++-
>  libavcodec/h264_refs.c|3 +-
>  libavcodec/h264_slice.c   |3 +-
>  libavcodec/h264chroma_template.c  |   20 
>  libavcodec/hevc_filter.c  |6 +++-
>  libavcodec/huffyuv.c  |3 +-
>  libavcodec/huffyuvenc.c   |5 +++-
>  libavcodec/ituh263enc.c   |3 +-
>  libavcodec/ivi.c  |4 ++-
>  libavcodec/jpeg2000dec.c  |3 +-
>  libavcodec/lclenc.c   |3 +-
>  libavcodec/lpc.c  |5 ++--
>  libavcodec/lzwenc.c   |9 ---
>  libavcodec/mips/h264chroma_msa.c  |   31 +++--
>  libavcodec/mips/vc1dsp_mmi.c  |   20 
>  libavcodec/mjpegdec.c |   11 +---
>  libavcodec/motion_est.c   |   12 -
>  libavcodec/motion_est_template.c  |   10 ++--
>  libavcodec/mpeg12.c   |3 +-
>  libavcodec/mpeg12enc.c|6 +++-
>  libavcodec/mpeg4videoenc.c|6 +++-
>  libavcodec/mpegaudiodec_template.c|3 +-
>  libavcodec/mpegaudioenc_template.c|6 +++-
>  libavcodec/mpegutils.c|6 +++-
>  libavcodec/mpegvideo_enc.c|9 ---
>  libavcodec/mpegvideo_xvmc.c   |3 +-
>  libavcodec/mpegvideoencdsp.c  |3 +-
>  libavcodec/mqcenc.c   |3 +-
>  libavcodec/put_bits.h |9 ---
>  libavcodec/rv34.c |3 +-
>  libavcodec/rv40dsp.c  |   10 ++--
>  libavcodec/sanm.c |3 +-
>  libavcodec/sinewin_tablegen.h |3 +-
>  libavcodec/snow.c |3 +-
>  libavcodec/snow.h |3 +-
>  libavcodec/snow_dwt.c |3 +-
>  libavcodec/snowenc.c  |   14 +++
>  libavcodec/svq1enc.c  |   24 ---
>  libavcodec/vaapi_encode.c |8 --
>  libavcodec/vaapi_encode_h264.c|3 +-
>  libavcodec/vaapi_encode_h265.c|6 +++-
>  libavcodec/vaapi_encode_vp9.c |4 +--
>  libavcodec/vc1_pred.c |3 +-
>  libavcodec/vc1dsp.c   |   20 
>  libavcodec/videodsp_template.c|6 +++-
>  libavcodec/vp9.c  |3 +-
>  libavcodec/vp9recon.c |3 +-
>  libavcodec/wmaenc.c   |6 +++-
>  libavcodec/x86/videodsp_init.c| 

Re: [FFmpeg-devel] [PATCH] libavformat: Separate assertions of the form "av_assertN(a && b)" to "av_assertN(a); av_assertN(b)" for more precise diagnostics.

[Michael Niedermayer]

On Sun, May 12, 2019 at 05:49:00AM -0700, Adam Richter wrote:
> This is the first of what I expect to be several patches to convert
> assertions of the
> form "assert(a && b)" to "assert(a); assert(b)".
> 
> Here are some reasons why I think this would be an improvement.  This
> lengthy argument is not included in the patch attachment.
> 
> 1. Assertion failures are often sporadic, and users who report them may
>not be in a position to efficiently narrow them down further, so it
>is important to get as much precision from each assertion failure as
>possible.
> 
> 2. It is a more efficient use of developers time when a bug report
>arrives if the problem has been narrowed down that much more.  A
>new bug report may initially attract more interest, so, if the
>problem has been narrowed down that much more, it may increase the
>chance that developers may invest the time to try to resolve the
>problem, and also reduce unnecessary traffic on the developer mailing
>list about possible causes of the bug that separating the assertion
>was able to rule out.
> 
> 3. It's often more readable, sometimes eliminating parentheses or
>changing multi-line conditions to separate single line conditions.
> 
> 4. When using a debugger to step over an assertion failure in the
>first part of the statement, the second part is still tested.
> 
> 5. Providing separate likelihood hints to the compiler in the form
>of separate assert statements does not require the compiler to
>be quite as smart to recognize that it should optimize both branches,
>although I do not know if that makes a difference for any compiler
>commonly used to compile X (that is, I suspect that they are all
>smart enough to realize is that "a && b" is likely true, then "a"
>is likely true and "b" is likely true).
> 
> I have confirmed that the resulting tree built without any apparent
> complaints about the assert statements and that "make fate" completed
> with a zero exit code.  I have not done any other tests though.
> 
> Thanks in advance for considering this patch.
> 
> Adam

>  au.c  |3 ++-
>  avienc.c  |3 ++-
>  aviobuf.c |3 ++-
>  matroskaenc.c |6 --
>  mov.c |3 ++-
>  rtmppkt.c |3 ++-
>  utils.c   |9 +
>  7 files changed, 19 insertions(+), 11 deletions(-)
> c36df9add7cb81a670d3e2ca2bbd7ee20d25cc51  
> 0001-libavformat-Separate-assertions-of-the-form-av_asser.patch
> From edb58a5ee8030ec66c04736a025d2a44e7322ba3 Mon Sep 17 00:00:00 2001
> From: Adam Richter 
> Date: Sun, 12 May 2019 03:41:49 -0700
> Subject: [PATCH] libavformat: Separate assertions of the form
>  "av_assertN(a && b)" to "av_assertN(a); av_assertN(b)" for more precise
>  diagnostics.
> 
> Signed-off-by: Adam Richter 

LGTM

thx

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Observe your enemies, for they first find out your faults. -- Antisthenes


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

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

Re: [FFmpeg-devel] [PATCH] ffplay: added option always on top for video window

[Moritz Barsnick]

On Mon, May 13, 2019 at 12:54:58 +0530, Gyan wrote:
> >> Since 2.0.6 it works on Windows too.
> > Ping.
>
> Michael needs to confirm whether the build failure he had was due to his
> SDL version < 2.0.5

I can at least confirm that 2.0.4, which I have installed on one
machine, doesn't define this in the provided headers, and that ffmpeg
doesn't build against 2.0.4 with this patch. So there should be an
#ifdef SDL_WINDOW_ALWAYS_ON_TOP guard around this, and possibly around
the options definition. (And the docs should mention it?)

https://hg.libsdl.org/SDL/annotate/3beca914a2ad/include/SDL_video.h

Not sure how Windows behaves if compiled against 2.0.5 with
availability of the flag, but not the feature. ;-) [*]

BTW, would this also be an option which could go into the "sdl2" output
device? (I'm not happy with separate code bases for these, personally.)

Moritz

[*] My guess is that Windows just ignored this flag before its
implementation:
https://hg.libsdl.org/SDL/rev/2653833db94e
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [PATCH] ffplay: added option always on top for video window

[Gyan]

On 13-05-2019 12:49 PM, Daniel Kučera wrote:

Is qualified as 'X11 only, >= SDL 2.0.5' at
https://wiki.libsdl.org/SDL_WindowFlags

Gyan


Since 2.0.6 it works on Windows too.

Ping.


Michael needs to confirm whether the build failure he had was due to his 
SDL version < 2.0.5


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

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

Re: [FFmpeg-devel] [PATCH] ffplay: added option always on top for video window

[Daniel Kučera]

>>
>> Is qualified as 'X11 only, >= SDL 2.0.5' at
>> https://wiki.libsdl.org/SDL_WindowFlags
>>
>> Gyan
>
>
> Since 2.0.6 it works on Windows too.

Ping.

-- 

S pozdravom / Best regards
Daniel Kucera.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [PATCH v2] libavutil: add an FFT & MDCT implementation

[Reimar Döffinger]

On 13.05.2019, at 04:54, Pedro Arthur  wrote:

> Em dom, 12 de mai de 2019 às 18:11, Hendrik Leppkes
>  escreveu:
>> 
>> On Sun, May 12, 2019 at 11:05 PM Carl Eugen Hoyos  wrote:
>>> 
>>> But seriously: We are of course not allowed to remove copyright
>>> statements, no matter if we consider them relevant or not.
>>> 
>> 
>> Please provide a source for such claims.
> The GPL license included in the header states that.
> 
> GPL2 [1] - "keep intact all the notices that refer to this License"
> GPL3 [2]  - "Requiring preservation of specified reasonable legal
> notices or author attributions in that material"
> MIT [3] (for completeness) - "The above copyright notice and this
> permission notice shall be included in all copies or substantial
> portions of the Software."
> 
> [1] - https://www.gnu.org/licenses/old-licenses/gpl-2.0.html
> [2] - http://www.gnu.org/licenses/gpl.html
> [3] - https://opensource.org/licenses/MI

Besides the direct legals and ethics of it, please note that it also creates a
serious (even if unlikely) risk to us and our users.
In any kind of legal case, whether to defend against some "copyright troll" or 
to
enforce the license it might become necessary to find the author of the code.
Not properly taking care of the license and copyright statement side exposes our
users to unnecessary risk and makes it harder to enforce our license.
Even if nothing happens, the work companies have to do to show compliance
(because their customers require it or to reduce their risk) becomes much 
harder.
Which is why the Linux kernel currently is working on cleaning up their license
header mess.

Best regards,
Reimar Döffinger
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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