[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] [PATCH] avfilter/drawtext: make command processing error-resilient

[Gyan]

On 13-05-2019 06:54 AM, myp...@gmail.com wrote:

On Mon, May 13, 2019 at 4:06 AM Gyan  wrote:



On 10-05-2019 07:25 PM, Gyan wrote:

At present, if the command args passed to drawtext contain any invalid
values, ffmpeg may crash or, at best, stop drawing any text.
Attached patch gets the filter to continue with existing parameters,
if not all of the changes can be parsed or applied. This allows users
in live processing to correct and resubmit.

Ping.

Tested and verified, LGTM, Thanks

Pushed as 87db1ca632bfbb66329c5729301d88ca30bed9b3

Thanks,
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] avformat/mxfenc: support XAVC long gop

[Baptiste Coudurier]

> On May 12, 2019, at 1:39 PM, Paul B Mahol  wrote:
> 
> On 5/12/19, Baptiste Coudurier  > wrote:
>> Hi Tomas
>> 
>>> On May 12, 2019, at 6:47 AM, Tomas Härdin  wrote:
>>> 
>>> fre 2019-05-10 klockan 08:50 -0700 skrev Baptiste Coudurier:
 +static inline int get_ue_golomb(GetBitContext *gb) {
 +int i, v;
 +for (i = 0; i < 32 && !get_bits1(gb); i++)
 +;
 +for (v = 1; i--;)
 +v = (v << 1) | get_bits1(gb);
>>> 
>>> Isn't there already a function to get variable number of bits?
>> 
>> get_bits doesn’t work for n == 0
> 
> There is get_bitsz. Or I misunderstood?

Nice, updated.

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

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

[Pedro Arthur]

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/MIT
___
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] lavf/mov: Fix timestamp rescale on sidx atom

[Jun Li]

On Fri, May 10, 2019 at 7:25 PM Jun Li  wrote:

>
> On Thu, May 9, 2019 at 2:08 AM Jun Li  wrote:
>
>> Fix #5090
>> Fix the timestamp rescale issue, from sidx timebase to
>> stream's timebase.
>> ---
>>  libavformat/mov.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/libavformat/mov.c b/libavformat/mov.c
>> index 78f692872b..d058855e6c 100644
>> --- a/libavformat/mov.c
>> +++ b/libavformat/mov.c
>> @@ -5017,7 +5017,7 @@ static int mov_read_sidx(MOVContext *c, AVIOContext
>> *pb, MOVAtom atom)
>>  return AVERROR_PATCHWELCOME;
>>  }
>>  avio_rb32(pb); // sap_flags
>> -timestamp = av_rescale_q(pts, st->time_base, timescale);
>> +timestamp = av_rescale_q(pts, timescale, st->time_base);
>>
>>  index = update_frag_index(c, offset);
>>  frag_stream_info = get_frag_stream_info(>frag_index, index,
>> track_id);
>> --
>> 2.17.1
>>
>
> Ping
>

This change is for fix the issue of calculating sidx_pts.
Sidx box has "earliest_presentation_time", used as pts of  the referent
track, sidx also has timescale field.
So the operation should convert from sidx's timescale to track's timescale,
this patch is for addressing this, as well as fixing #5090.

Of course this is based on my understanding, so please correct me if I am
wrong. Thanks !

Best Regards,
Jun
___
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] [PATCHv2] lavfi: add gblur_opencl filter

[Dylan Fernando]

On Sun, May 12, 2019 at 10:47 PM Paul B Mahol  wrote:

> On 5/8/19, Song, Ruiling  wrote:
> >
> >
> >> -Original Message-
> >> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> >> Of Dylan Fernando
> >> Sent: Tuesday, May 7, 2019 8:27 AM
> >> To: ffmpeg-devel@ffmpeg.org
> >> Subject: Re: [FFmpeg-devel] [PATCHv2] lavfi: add gblur_opencl filter
> >>
> >> Anyone have any comments/feedback?
> > I think unsharp_opencl with a negative amount should do similar thing as
> > this one.
>
> Not really.
>
> > What's the difference? Better quality? or better speed?
>
> This one can blur image with larger radius.
>
> But why step parameter was removed?
> ___
> 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".

This one doesn't use a Gaussian approximation, it uses a Gaussian kernel
calculated with:
matrix_horiz[i] = (1 / sqrt(2 * 3.14159*pow(s->sigma, 2)))*exp(-(pow(x, 2)
/ (2 * pow(s->sigma, 2
with kernel size 6 * sigma.
Should there be a parameter for adjusting the kernel size?
___
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] lavfi/opencl: add nlmeans_opencl filter

[Song, Ruiling]

> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Ruiling Song
> Sent: Tuesday, May 7, 2019 10:45 AM
> To: ffmpeg-devel@ffmpeg.org
> Cc: Song, Ruiling 
> Subject: [FFmpeg-devel] [PATCH V3] lavfi/opencl: add nlmeans_opencl filter
> 
> Signed-off-by: Ruiling Song 
> ---
>  configure   |   1 +
>  doc/filters.texi|   4 +
>  libavfilter/Makefile|   1 +
>  libavfilter/allfilters.c|   1 +
>  libavfilter/opencl/nlmeans.cl   | 115 +
>  libavfilter/opencl_source.h |   1 +
>  libavfilter/vf_nlmeans_opencl.c | 443
> 
>  7 files changed, 566 insertions(+)
>  create mode 100644 libavfilter/opencl/nlmeans.cl
>  create mode 100644 libavfilter/vf_nlmeans_opencl.c
Hi Mark,

Do you have further comment on v3?

Ruiling
___
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/3] avutil: Add NV24 and NV42 pixel formats

[Fu, Linjie]

> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Carl Eugen Hoyos
> Sent: Sunday, May 12, 2019 18:45
> To: FFmpeg development discussions and patches  de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH 1/3] avutil: Add NV24 and NV42 pixel
> formats
> 
> Am So., 12. Mai 2019 um 05:38 Uhr schrieb Fu, Linjie :
> 
> > I'm working on adding support for HEVC 4:2:2/ 4:4:4, 8/10 bit, in vaapi
> decoding.
> > And I'm aslo thinking of add some new pix_fmt for packed FourCC:
> > 444 8 bit :  AYUV
> > 444 10 bit: Y410
> > 422 10 bit: Y210
> 
> Do I understand correctly that for 420 8 bit, vaapi produces the
> decoded image in a planar format but for 444 8 bit (and 10 bit),
> you decided that a packed format makes more sense?
> (Aren't luma and chroma stored independently in hevc?)
> 

It's true that for 420 8 bit, the decoded image is in planar format.
But as to 444 8 bit(and 10 bit), as far as I know in  media driver , the 
decoded image is produced in packed format.
See:
https://github.com/intel/media-driver/blob/8773ef5e82e8a151e1bcfef317f7808f319c91c2/media_driver/linux/gen11/ddi/media_libva_caps_g11.cpp#L842

else if(profile == VAProfileHEVCMain444 || profile == 
VAProfileVP9Profile1)
{
attribs[i].type = VASurfaceAttribPixelFormat;
attribs[i].value.type = VAGenericValueTypeInteger;
attribs[i].flags = VA_SURFACE_ATTRIB_GETTABLE | 
VA_SURFACE_ATTRIB_SETTABLE;
attribs[i].value.value.i = VA_FOURCC_AYUV;
i++;
}

> Note that no matter what you do with the decoded image, there
> will be a (measurable) performance hit because of the needed
> transformation into something (planar) that other filters and
> encoders understand.

Agree, the directly decoded format is better. 
And it's also one of the reasons I'd like to add these packed formats.

Linjie
___
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_unsharp: enable slice threading

[Song, Ruiling]

> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Carl Eugen Hoyos
> Sent: Friday, May 10, 2019 4:53 PM
> To: FFmpeg development discussions and patches  de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH] avfilter/vf_unsharp: enable slice
> threading
> 
> Am Fr., 10. Mai 2019 um 08:50 Uhr schrieb Song, Ruiling
> :
> >
> > > -Original Message-
> > > From: Song, Ruiling
> > > Sent: Thursday, May 9, 2019 3:43 PM
> > > To: ffmpeg-devel@ffmpeg.org
> > > Cc: Song, Ruiling 
> > > Subject: [PATCH] avfilter/vf_unsharp: enable slice threading
> > >
> > > Signed-off-by: Ruiling Song 
> > > ---
> > >  libavfilter/unsharp.h|  4 +-
> > >  libavfilter/vf_unsharp.c | 98 ++--
> 
> > >  2 files changed, 78 insertions(+), 24 deletions(-)
> >
> > Add some performance number in case somebody have interest to know.
> > Running "ffmpeg -i 1080p.mp4 -vf unsharp=la=3:ca=3 -an -f null /dev/null"
> on my local machine (i7-6770HQ): the fps increase from 50 to 120.
> 
> Something like this should be part of the commit message imo.
Ok, I will add this to commit message when pushing the patch. Will add next 
time.
I really hope someone to take a look at the change whether this is functionally 
ok.

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

Re: [FFmpeg-devel] [PATCH 3/6] lavc/bink: Remove the dead code block

[myp...@gmail.com]

On Sat, May 11, 2019 at 11:04 AM Peter Ross  wrote:
>
> On Sat, May 11, 2019 at 12:05:51AM +0800, Jun Zhao wrote:
> > From: Jun Zhao 
> >
> > Remove the dead code block
> >
> > Signed-off-by: Jun Zhao 
> > ---
> >  libavcodec/bink.c |2 --
> >  1 files changed, 0 insertions(+), 2 deletions(-)
> >
> > diff --git a/libavcodec/bink.c b/libavcodec/bink.c
> > index 6673afa..d0f1b39 100644
> > --- a/libavcodec/bink.c
> > +++ b/libavcodec/bink.c
> > @@ -1046,8 +1046,6 @@ static int bink_decode_plane(BinkContext *c, AVFrame 
> > *frame, GetBitContext *gb,
> >  if ((ret = read_runs(c->avctx, gb, >bundle[BINK_SRC_RUN])) < 0)
> >  return ret;
> >
> > -if (by == bh)
> > -break;
> >  dst  = frame->data[plane_idx]  + 8*by*stride;
> >  prev = (c->last->data[plane_idx] ? c->last->data[plane_idx]
> >   : frame->data[plane_idx]) + 
> > 8*by*stride;
> > --
> > 1.7.1
>
> looks good. please apply.
>
> -- Peter
> (A907 E02F A6E5 0CD2 34CD 20D2 6760 79C5 AC40 DD6B)
Pushed, Thanks
___
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 4/6] lavc/libvpxenc: remove redundant condition check

[myp...@gmail.com]

On Sat, May 11, 2019 at 3:14 AM Vignesh Venkatasubramanian
 wrote:
>
> From: Jun Zhao 
> Date: Fri, May 10, 2019 at 9:06 AM
> To: 
> Cc: Jun Zhao
>
> > From: Jun Zhao 
> >
> > Redundant condition: '!A || B' is equivalent to '!A || (A && B)' but
> > more clearly.
> >
> > Signed-off-by: Jun Zhao 
> > ---
> >  libavcodec/libvpxenc.c |2 +-
> >  1 files changed, 1 insertions(+), 1 deletions(-)
> >
> > diff --git a/libavcodec/libvpxenc.c b/libavcodec/libvpxenc.c
> > index c823b8a..feb52ea 100644
> > --- a/libavcodec/libvpxenc.c
> > +++ b/libavcodec/libvpxenc.c
> > @@ -978,7 +978,7 @@ static int queue_frames(AVCodecContext *avctx, AVPacket 
> > *pkt_out)
> > are only good through the next vpx_codec call */
> >  while ((pkt = vpx_codec_get_cx_data(>encoder, )) &&
> > (!ctx->is_alpha ||
> > -(ctx->is_alpha && (pkt_alpha = 
> > vpx_codec_get_cx_data(>encoder_alpha, _alpha) {
> > +(pkt_alpha = vpx_codec_get_cx_data(>encoder_alpha, 
> > _alpha {
> >  switch (pkt->kind) {
> >  case VPX_CODEC_CX_FRAME_PKT:
> >  if (!size) {
> > --
> > 1.7.1
> >
>
> lgtm.
>
Pushed, Thanks
___
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/6] lavc/avpacket: check NULL before using the pointer

[myp...@gmail.com]

On Sat, May 11, 2019 at 8:23 AM Michael Niedermayer
 wrote:
>
> On Fri, May 10, 2019 at 10:00:54PM +0200, Carl Eugen Hoyos wrote:
> > Am Fr., 10. Mai 2019 um 18:13 Uhr schrieb Jun Zhao :
> > >
> > > From: Jun Zhao 
> > >
> > > Need to check NULL before using the pointer
> > >
> > > Signed-off-by: Jun Zhao 
> > > ---
> > >  libavcodec/avpacket.c |3 ++-
> > >  1 files changed, 2 insertions(+), 1 deletions(-)
> > >
> > > diff --git a/libavcodec/avpacket.c b/libavcodec/avpacket.c
> > > index 8f0603d..2b20067 100644
> > > --- a/libavcodec/avpacket.c
> > > +++ b/libavcodec/avpacket.c
> > > @@ -522,11 +522,12 @@ fail:
> > >
> > >  int av_packet_unpack_dictionary(const uint8_t *data, int size, 
> > > AVDictionary **dict)
> > >  {
> > > -const uint8_t *end = data + size;
> > > +const uint8_t *end;
> > >  int ret = 0;
> > >
> > >  if (!dict || !data || !size)
> > >  return ret;
> > > +end = data + size;
> >
> > Could somebody explain to me why this is necessary?
>
> if data is NULL adding a non zero value to it would be undefined behavior
> i think
>
Yes, it's a undefined behavior to adding a non zero value if the
pointer is NULL,
this is the reason to change the code.

Applied, Thanks
___
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 6/6] lavc/pngenc: check malloc fail before using the pointer

[myp...@gmail.com]

On Sat, May 11, 2019 at 12:06 AM Jun Zhao  wrote:
>
> From: Jun Zhao 
>
> Need to check malloc fail before using the pointer
>
> Signed-off-by: Jun Zhao 
> ---
>  libavcodec/pngenc.c |2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/libavcodec/pngenc.c b/libavcodec/pngenc.c
> index 69b4495..d4d8dc8 100644
> --- a/libavcodec/pngenc.c
> +++ b/libavcodec/pngenc.c
> @@ -748,11 +748,11 @@ static int apng_encode_frame(AVCodecContext *avctx, 
> const AVFrame *pict,
>  original_bytestream_end = s->bytestream_end;
>
>  temp_bytestream = av_malloc(original_bytestream_end - 
> original_bytestream);
> -temp_bytestream_end = temp_bytestream + (original_bytestream_end - 
> original_bytestream);
>  if (!temp_bytestream) {
>  ret = AVERROR(ENOMEM);
>  goto fail;
>  }
> +temp_bytestream_end = temp_bytestream + (original_bytestream_end - 
> original_bytestream);
>
>  for (last_fctl_chunk.dispose_op = 0; last_fctl_chunk.dispose_op < 3; 
> ++last_fctl_chunk.dispose_op) {
>  // 0: APNG_DISPOSE_OP_NONE
> --
> 1.7.1
Pushed, Thanks
___
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/drawtext: make command processing error-resilient

[myp...@gmail.com]

On Mon, May 13, 2019 at 4:06 AM Gyan  wrote:
>
>
>
> On 10-05-2019 07:25 PM, Gyan wrote:
> > At present, if the command args passed to drawtext contain any invalid
> > values, ffmpeg may crash or, at best, stop drawing any text.
> > Attached patch gets the filter to continue with existing parameters,
> > if not all of the changes can be parsed or applied. This allows users
> > in live processing to correct and resubmit.
>
> Ping.
Tested and verified, LGTM, Thanks
___
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/6] lavc/aacenc_ltp: remove unnecessary condition check.

[myp...@gmail.com]

On Sat, May 11, 2019 at 12:06 AM Jun Zhao  wrote:
>
> From: Jun Zhao 
>
> Condition 'sum==2' is always true, so remove the check logic to
> make the code clean.
>
> Signed-off-by: Jun Zhao 
> ---
>  libavcodec/aacenc_ltp.c |2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/libavcodec/aacenc_ltp.c b/libavcodec/aacenc_ltp.c
> index 674a2a0..f77f0b6 100644
> --- a/libavcodec/aacenc_ltp.c
> +++ b/libavcodec/aacenc_ltp.c
> @@ -144,7 +144,7 @@ void ff_aac_adjust_common_ltp(AACEncContext *s, 
> ChannelElement *cpe)
>  int sum = sce0->ics.ltp.used[sfb] + sce1->ics.ltp.used[sfb];
>  if (sum != 2) {
>  sce0->ics.ltp.used[sfb] = 0;
> -} else if (sum == 2) {
> +} else {
>  count++;
>  }
>  }
> --
> 1.7.1
>
Pushed, Thanks
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [PATCH 5/6] lavc/mlpenc: remove the redundant condition check

[myp...@gmail.com]

On Sat, May 11, 2019 at 12:06 AM Jun Zhao  wrote:
>
> From: Jun Zhao 
>
> remove the redundant condition check for 'frame'
>
> Signed-off-by: Jun Zhao 
> ---
>  libavcodec/mlpenc.c |6 ++
>  1 files changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/libavcodec/mlpenc.c b/libavcodec/mlpenc.c
> index 7536d3b..deb1716 100644
> --- a/libavcodec/mlpenc.c
> +++ b/libavcodec/mlpenc.c
> @@ -2232,10 +2232,8 @@ static int mlp_encode_frame(AVCodecContext *avctx, 
> AVPacket *avpkt,
>  return 1;
>
>  /* add current frame to queue */
> -if (frame) {
> -if ((ret = ff_af_queue_add(>afq, frame)) < 0)
> -return ret;
> -}
> +if ((ret = ff_af_queue_add(>afq, frame)) < 0)
> +return ret;
>
>  data = frame->data[0];
>
> --
> 1.7.1
Pushed, Thanks
___
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] Discussion of all-inclusive full stack builds

[Tim Jones]

On May 12, 2019, at 4:14 PM, Reimar Döffinger  wrote:
> 
> On Sun, May 12, 2019 at 12:07:42PM -0700, Tim Jones wrote:
>> On May 12, 2019, at 11:54 AM, Nicolas George  wrote:
>>> 
>>> Tim Jones (12019-05-12):
>>> 
 --disable-all-proprietary/--enable-all-proprietary
>>> 
>>> As for this one, on the other hand, there will be opposition: we do not
>>> want encourage users to use proprietary software. In fact, there is
>>> currently a discussion to refuse including new proprietary components,
>>> and possibly getting rid of the ones we included without thinking.
>> 
>> I don't want to start a thread war here, but isn't the purpose of any 
>> toolchain to allow for the support of a given task?  If there isn't a FOSS 
>> option and an easily obtained proprietary solution exists, why block it?
>> 
>> This is one of the things I hear from new Linux users when running into the 
>> FOSS vs. proprietary brick walls - they just want a platform that works.  
>> The FUD that is continuously promoted concerning adding non-FOSS components 
>> - Nvidia drivers, ATTO drivers, HighPoint drivers, custom audio device 
>> drivers - has caused a number of potentially large Linux opportunities to 
>> move to Windows.
>> 
>> I've long been a proponent of FOSS where it is apropos, but I also 
>> understand Heinlein's TNSTAAFL :) .
> 
> Well, which is a fairly good argument to enable proprietary components
> only in specific cases.

Which is why I asked in my original question if an optional config setting had 
been discussed previously.  

If autodetection is an issue "in general", then the option should be to 
--disable-external, or my --disable-all-proprietary, by default.  This flag 
could then be reversed by the builder to include any external/proprietary 
libraries found with the understanding that if something is broken, the builder 
must revert to the --disable-external config and rebuild before attempting to 
report a bug or other problem.  Then it would be up to the builder to determine 
which of their external features/libraries were causing the build failure or 
problem.

We do this with a few sensor-specific library collections I work with on the 
Arduino and Raspberry Pi platforms.  The user builds with the defaults - if it 
works, add their custom sensor packages.  If it breaks, report that to the 
creator of your custom sensor module package instead of the upstream team. 
Works perfectly in each case and the primary team doesn't have to worry about 
that new hydrology sensor that has added salinity levels to the mix (which we 
don't even know about).

--
Tim


___
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] Discussion of all-inclusive full stack builds

[Reimar Döffinger]

On Sun, May 12, 2019 at 12:07:42PM -0700, Tim Jones wrote:
> On May 12, 2019, at 11:54 AM, Nicolas George  wrote:
> >
> > Tim Jones (12019-05-12):
> >
> >> --disable-all-proprietary/--enable-all-proprietary
> >
> > As for this one, on the other hand, there will be opposition: we do not
> > want encourage users to use proprietary software. In fact, there is
> > currently a discussion to refuse including new proprietary components,
> > and possibly getting rid of the ones we included without thinking.
>
> I don't want to start a thread war here, but isn't the purpose of any 
> toolchain to allow for the support of a given task?  If there isn't a FOSS 
> option and an easily obtained proprietary solution exists, why block it?
>
> This is one of the things I hear from new Linux users when running into the 
> FOSS vs. proprietary brick walls - they just want a platform that works.  The 
> FUD that is continuously promoted concerning adding non-FOSS components - 
> Nvidia drivers, ATTO drivers, HighPoint drivers, custom audio device drivers 
> - has caused a number of potentially large Linux opportunities to move to 
> Windows.
>
> I've long been a proponent of FOSS where it is apropos, but I also understand 
> Heinlein's TNSTAAFL :) .

Well, which is a fairly good argument to enable proprietary components
only in specific cases.
There is a cost in doing the auto-detection, there is a cost in
maintaining it, there is a cost in supporting it when it breaks -
especially when it completely breaks FFmpeg even for users who have
no use for it (this can easily happen with libraries that do not
properly namespace symbols and hide the non-namespaced ones for example).
But as always it is a cost vs. benefit question.
And I'd also add that it's not really specific to proprietary,
it applies to all external dependencies, most are not enabled
by default even when they are FOSS.
Unfortunately we don't really have the data to say which features
are used often, which makes the whole cost vs. benefit consideration
a bit hard.
___
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 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.

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

[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).
___
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 So., 12. Mai 2019 um 23:58 Uhr schrieb Lynne :
> I need *technical* feedback about the API.

I understand that.

Please understand that the patch cannot be committed as-is.

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

[Lynne]

May 12, 2019, 10:04 PM by ceffm...@gmail.com:

>
> Yes, and this is the reason why we must not remove the names
> of those present (they also hold a copyright, not just those whose
> names are missing).
>
>

Please go and discuss the project and the world's attitude and policy towards 
copyright
notices in another thread.

I need *technical* feedback about the API. I would also like to have someone 
take a quick
look at the implementation, although I'm confident its okay and as optimal as a 
generic
software implementation could be. Accuracy-wise its slightly better than 
libfftw3f, due to
the use of reordering for nptwo transform direction and the compound 15-point 
FFT
(less operations due to the lack of inter-stage twiddles).
Can provide a benchmarking test program on IRC.
___
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 apitch filter

[Paul B Mahol]

On 5/12/19, Michael Niedermayer  wrote:
> On Sun, May 12, 2019 at 11:00:51PM +0200, Nicolas George wrote:
>> Marton Balint (12019-05-12):
>> > Yeah, you are right, what I had in mind was this:
>> >
>> > apitch  ===  asetrate,aresample,atempo
>>
>> Exactly. And reciprocally, atempo = apitch+asetrate+aresample.
>>
>> Furthermore, since it works with the spectrum, the filter that does the
>> hard work can probably easily output at any sample rate, at a cost much
>> lower than resampling afterwards. Therefore, it makes most sense to have
>> a single filter with all three parameters (sample rate, speed adjustment
>> and pitch adjustment).
>
> and if thats done in our resampler than that can also be combined with
> changing the channel order, layout, sample type and so on.
> Iam not sure its a good idea but purely technically it should be more
> efficient to do it all together.
> Also swresample already supports an external FFT resampler so it might
> actually fit in there nicely and it might even allow us to remove an
> external
> dependancy without loosing a feature. (assuming the new FFT resampler
> would be equally good)
>
>

To make it work dynamically, filter must resample audio internally.
___
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 apitch filter

[Michael Niedermayer]

On Sun, May 12, 2019 at 11:00:51PM +0200, Nicolas George wrote:
> Marton Balint (12019-05-12):
> > Yeah, you are right, what I had in mind was this:
> > 
> > apitch  ===  asetrate,aresample,atempo
> 
> Exactly. And reciprocally, atempo = apitch+asetrate+aresample.
> 
> Furthermore, since it works with the spectrum, the filter that does the
> hard work can probably easily output at any sample rate, at a cost much
> lower than resampling afterwards. Therefore, it makes most sense to have
> a single filter with all three parameters (sample rate, speed adjustment
> and pitch adjustment).

and if thats done in our resampler than that can also be combined with
changing the channel order, layout, sample type and so on.
Iam not sure its a good idea but purely technically it should be more
efficient to do it all together.
Also swresample already supports an external FFT resampler so it might
actually fit in there nicely and it might even allow us to remove an external
dependancy without loosing a feature. (assuming the new FFT resampler
would be equally good)

Thanks

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Elect your leaders based on what they did after the last election, not
based on what they say before an election.



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

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

[FFmpeg-devel] [PATCH 1/2] avcodec/diracdec: Check for arith decoder errors in dirac_unpack_block_motion_data()

[Michael Niedermayer]

Fixes: Timeout (54sec -> 188ms)
Fixes: 
14585/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_DIRAC_fuzzer-5649933052411904

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

diff --git a/libavcodec/diracdec.c b/libavcodec/diracdec.c
index a5bb6d5f34..52a1951690 100644
--- a/libavcodec/diracdec.c
+++ b/libavcodec/diracdec.c
@@ -1551,6 +1551,11 @@ static int dirac_unpack_block_motion_data(DiracContext 
*s)
 }
 }
 
+for (i = 0; i < 4 + 2*s->num_refs; i++) {
+if (arith[i].error)
+return arith[i].error;
+}
+
 return 0;
 }
 
-- 
2.21.0

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

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

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

[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;
+
 /* if this is the first frame, check for deviant Sega FILM data */
 if (s->sega_film_skip_bytes == -1) {
 if (!encoded_buf_size) {
-- 
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 v2] libavutil: add an FFT & MDCT implementation

[Hendrik Leppkes]

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.

- 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 v2] libavutil: add an FFT & MDCT implementation

[Carl Eugen Hoyos]

Am So., 12. Mai 2019 um 22:59 Uhr schrieb Hendrik Leppkes :
>
> On Sun, May 12, 2019 at 10:38 PM Carl Eugen Hoyos  wrote:
> >
> > Am So., 12. Mai 2019 um 22:37 Uhr schrieb Paul B Mahol :
> > >
> > > On 5/12/19, Carl Eugen Hoyos  wrote:
> > > > Am Fr., 10. Mai 2019 um 17:15 Uhr schrieb Lynne :
> > > >>
> > > >> Patch updated again.
> > > >> Made some more cleanups to the transforms, the tables and the main
> > > >> context.
> > > >> API changed again, now the init function populates the function pointer
> > > >> for transform.
> > > >> I decided that having a separate function would encourage bad usage 
> > > >> (e.g.
> > > >> calling
> > > >> the function every time before doing a transform rather than storing 
> > > >> the
> > > >> pointer) when
> > > >> we're trying to avoid the overhead of function calls.
> > > >> Also adjusted file names to match the API.
> > > >
> > > > As said, this patch is not ok as long as the copyright statements are
> > > > missing.
> > > >
> > >
> > > You are mislead. No statements are necessary.
> >
> > Why do you think so?
> >
> > The commit message states that a part of the code is coming
> > from a file with an extensive copyright statement: Why would
> > it be ok to remove it?
>
> The names at the top of the file are always going to be inaccurate,

Possibly.

> and as such meaningless,

(Impossible to parse)

> because everyone that changed the file in a
> meaningful way holds a copyright over those changes,

Of course!

> and not everyone is added to that list

True.

> (typically, no-one beyond the original author is present there).

Depending on the meaning of "typically" this may be true
(but is probably "meaningless").

> Since the list is not complete, and as such does not allow you to
> identify who actually holds all the copyright in such a file, its not
> legally relevant.

This is - to quote a Viennese scientist - not even wrong;-)

But seriously: We are of course not allowed to remove copyright
statements, no matter if we consider them relevant or not.

> Everyone of the authors still hold a copyright no matter if the name
> is present there, or not.

Yes, and this is the reason why we must not remove the names
of those present (they also hold a copyright, not just those whose
names are missing).

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] avfilter: add apitch filter

[Nicolas George]

Marton Balint (12019-05-12):
> Yeah, you are right, what I had in mind was this:
> 
> apitch  ===  asetrate,aresample,atempo

Exactly. And reciprocally, atempo = apitch+asetrate+aresample.

Furthermore, since it works with the spectrum, the filter that does the
hard work can probably easily output at any sample rate, at a cost much
lower than resampling afterwards. Therefore, it makes most sense to have
a single filter with all three parameters (sample rate, speed adjustment
and pitch adjustment).

Regards,

-- 
  Nicolas George


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

[Hendrik Leppkes]

On Sun, May 12, 2019 at 10:38 PM Carl Eugen Hoyos  wrote:
>
> Am So., 12. Mai 2019 um 22:37 Uhr schrieb Paul B Mahol :
> >
> > On 5/12/19, Carl Eugen Hoyos  wrote:
> > > Am Fr., 10. Mai 2019 um 17:15 Uhr schrieb Lynne :
> > >>
> > >> Patch updated again.
> > >> Made some more cleanups to the transforms, the tables and the main
> > >> context.
> > >> API changed again, now the init function populates the function pointer
> > >> for transform.
> > >> I decided that having a separate function would encourage bad usage (e.g.
> > >> calling
> > >> the function every time before doing a transform rather than storing the
> > >> pointer) when
> > >> we're trying to avoid the overhead of function calls.
> > >> Also adjusted file names to match the API.
> > >
> > > As said, this patch is not ok as long as the copyright statements are
> > > missing.
> > >
> >
> > You are mislead. No statements are necessary.
>
> Why do you think so?
>
> The commit message states that a part of the code is coming
> from a file with an extensive copyright statement: Why would
> it be ok to remove it?
>

The names at the top of the file are always going to be inaccurate,
and as such meaningless, because everyone that changed the file in a
meaningful way holds a copyright over those changes, and not everyone
is added to that list (typically, no-one beyond the original author is
present there).
Since the list is not complete, and as such does not allow you to
identify who actually holds all the copyright in such a file, its not
legally relevant.

Everyone of the authors still hold a copyright no matter if the name
is present there, or not.

- 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 v2] libavutil: add an FFT & MDCT implementation

[Carl Eugen Hoyos]

Am So., 12. Mai 2019 um 22:40 Uhr schrieb Paul B Mahol :
>
> On 5/12/19, Carl Eugen Hoyos  wrote:
> > Am So., 12. Mai 2019 um 22:37 Uhr schrieb Paul B Mahol :
> >>
> >> On 5/12/19, Carl Eugen Hoyos  wrote:
> >> > Am Fr., 10. Mai 2019 um 17:15 Uhr schrieb Lynne :
> >> >>
> >> >> Patch updated again.
> >> >> Made some more cleanups to the transforms, the tables and the main
> >> >> context.
> >> >> API changed again, now the init function populates the function pointer
> >> >> for transform.
> >> >> I decided that having a separate function would encourage bad usage
> >> >> (e.g.
> >> >> calling
> >> >> the function every time before doing a transform rather than storing
> >> >> the
> >> >> pointer) when
> >> >> we're trying to avoid the overhead of function calls.
> >> >> Also adjusted file names to match the API.
> >> >
> >> > As said, this patch is not ok as long as the copyright statements are
> >> > missing.
> >> >
> >>
> >> You are mislead. No statements are necessary.
> >
> > Why do you think so?
> >
> > The commit message states that a part of the code is coming
> > from a file with an extensive copyright statement: Why would
> > it be ok to remove it?
>
> Are you  sure white-space is copyright-able?

I am sure that white-space is generally not copyrightable but
Lynne claimed he copied actual code from libavcodec.

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/12/19, Carl Eugen Hoyos  wrote:
> Am Fr., 10. Mai 2019 um 17:15 Uhr schrieb Lynne :
>>
>> Patch updated again.
>> Made some more cleanups to the transforms, the tables and the main
>> context.
>> API changed again, now the init function populates the function pointer
>> for transform.
>> I decided that having a separate function would encourage bad usage (e.g.
>> calling
>> the function every time before doing a transform rather than storing the
>> pointer) when
>> we're trying to avoid the overhead of function calls.
>> Also adjusted file names to match the API.
>
> As said, this patch is not ok as long as the copyright statements are
> missing.
>

You are mislead. No statements are necessary.
___
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 So., 12. Mai 2019 um 22:37 Uhr schrieb Paul B Mahol :
>
> On 5/12/19, Carl Eugen Hoyos  wrote:
> > Am Fr., 10. Mai 2019 um 17:15 Uhr schrieb Lynne :
> >>
> >> Patch updated again.
> >> Made some more cleanups to the transforms, the tables and the main
> >> context.
> >> API changed again, now the init function populates the function pointer
> >> for transform.
> >> I decided that having a separate function would encourage bad usage (e.g.
> >> calling
> >> the function every time before doing a transform rather than storing the
> >> pointer) when
> >> we're trying to avoid the overhead of function calls.
> >> Also adjusted file names to match the API.
> >
> > As said, this patch is not ok as long as the copyright statements are
> > missing.
> >
>
> You are mislead. No statements are necessary.

Why do you think so?

The commit message states that a part of the code is coming
from a file with an extensive copyright statement: Why would
it be ok to remove it?

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/12/19, Carl Eugen Hoyos  wrote:
> Am So., 12. Mai 2019 um 22:37 Uhr schrieb Paul B Mahol :
>>
>> On 5/12/19, Carl Eugen Hoyos  wrote:
>> > Am Fr., 10. Mai 2019 um 17:15 Uhr schrieb Lynne :
>> >>
>> >> Patch updated again.
>> >> Made some more cleanups to the transforms, the tables and the main
>> >> context.
>> >> API changed again, now the init function populates the function pointer
>> >> for transform.
>> >> I decided that having a separate function would encourage bad usage
>> >> (e.g.
>> >> calling
>> >> the function every time before doing a transform rather than storing
>> >> the
>> >> pointer) when
>> >> we're trying to avoid the overhead of function calls.
>> >> Also adjusted file names to match the API.
>> >
>> > As said, this patch is not ok as long as the copyright statements are
>> > missing.
>> >
>>
>> You are mislead. No statements are necessary.
>
> Why do you think so?
>
> The commit message states that a part of the code is coming
> from a file with an extensive copyright statement: Why would
> it be ok to remove it?
>

Are you  sure white-space is copyright-able?
___
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

[Paul B Mahol]

On 5/12/19, Baptiste Coudurier  wrote:
> Hi Tomas
>
>> On May 12, 2019, at 6:47 AM, Tomas Härdin  wrote:
>>
>> fre 2019-05-10 klockan 08:50 -0700 skrev Baptiste Coudurier:
>>> +static inline int get_ue_golomb(GetBitContext *gb) {
>>> +int i, v;
>>> +for (i = 0; i < 32 && !get_bits1(gb); i++)
>>> +;
>>> +for (v = 1; i--;)
>>> +v = (v << 1) | get_bits1(gb);
>>
>> Isn't there already a function to get variable number of bits?
>
> get_bits doesn’t work for n == 0

There is get_bitsz. Or I misunderstood?

>
>>>
>>> +
>>> +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
>>
>> Why not just get 6 bits at once?
>
> That’s how it’s done in h264_ps.c currently.
>
>>> +static void mxf_write_local_tags(AVIOContext *pb, const MXFLocalTagPair
>>> *local_tags, int count)
>>> +{
>>> +int i;
>>> +for (i = 0; i < count; i++) {
>>> +avio_wb16(pb, local_tags[i].local_tag);
>>> +avio_write(pb, local_tags[i].uid, 16);
>>> +}
>>> +}
>>
>> This function could be used to simplify mxf_write_primer_pack(). But
>> that probably belongs in a separate patch.
>
> Yes, it does
>
>>> +
>>>  static void mxf_write_primer_pack(AVFormatContext *s)
>>>  {
>>>  MXFContext *mxf = s->priv_data;
>>>  AVIOContext *pb = s->pb;
>>>  int local_tag_number, i = 0;
>>> +int avc_tags_count = 0;
>>>
>>>  local_tag_number = FF_ARRAY_ELEMS(mxf_local_tag_batch);
>>>  local_tag_number += mxf->store_user_comments *
>>> FF_ARRAY_ELEMS(mxf_user_comments_local_tag);
>>>
>>> +for (i = 0; i < s->nb_streams; i++) {
>>> +MXFStreamContext *sc = s->streams[i]->priv_data;
>>> +if (s->streams[i]->codecpar->codec_id == AV_CODEC_ID_H264 &&
>>> !sc->avc_intra) {
>>> +avc_tags_count =
>>> FF_ARRAY_ELEMS(mxf_avc_subdescriptor_local_tags);
>>> +local_tag_number += avc_tags_count;
>>
>> This will output a broken file if there's more than one XAVC stream.
>> Not possible now I think, but will be a problem is someone decides to
>> give higher operational patterns a try
>
> Yes, it will get caught when this happens.
>
> —
> 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 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/drawtext: make command processing error-resilient

[Gyan]

On 10-05-2019 07:25 PM, Gyan wrote:
At present, if the command args passed to drawtext contain any invalid 
values, ffmpeg may crash or, at best, stop drawing any text.
Attached patch gets the filter to continue with existing parameters, 
if not all of the changes can be parsed or applied. This allows users 
in live processing to correct and resubmit.


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

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

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

[Baptiste Coudurier]

Hi Tomas

> On May 12, 2019, at 6:47 AM, Tomas Härdin  wrote:
> 
> fre 2019-05-10 klockan 08:50 -0700 skrev Baptiste Coudurier:
>> +static inline int get_ue_golomb(GetBitContext *gb) {
>> +int i, v;
>> +for (i = 0; i < 32 && !get_bits1(gb); i++)
>> +;
>> +for (v = 1; i--;)
>> +v = (v << 1) | get_bits1(gb);
> 
> Isn't there already a function to get variable number of bits?

get_bits doesn’t work for n == 0

>> 
>> +
>> +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
> 
> Why not just get 6 bits at once?

That’s how it’s done in h264_ps.c currently.
 
>> +static void mxf_write_local_tags(AVIOContext *pb, const MXFLocalTagPair 
>> *local_tags, int count)
>> +{
>> +int i;
>> +for (i = 0; i < count; i++) {
>> +avio_wb16(pb, local_tags[i].local_tag);
>> +avio_write(pb, local_tags[i].uid, 16);
>> +}
>> +}
> 
> This function could be used to simplify mxf_write_primer_pack(). But
> that probably belongs in a separate patch.

Yes, it does

>> +
>>  static void mxf_write_primer_pack(AVFormatContext *s)
>>  {
>>  MXFContext *mxf = s->priv_data;
>>  AVIOContext *pb = s->pb;
>>  int local_tag_number, i = 0;
>> +int avc_tags_count = 0;
>>  
>>  local_tag_number = FF_ARRAY_ELEMS(mxf_local_tag_batch);
>>  local_tag_number += mxf->store_user_comments * 
>> FF_ARRAY_ELEMS(mxf_user_comments_local_tag);
>>  
>> +for (i = 0; i < s->nb_streams; i++) {
>> +MXFStreamContext *sc = s->streams[i]->priv_data;
>> +if (s->streams[i]->codecpar->codec_id == AV_CODEC_ID_H264 && 
>> !sc->avc_intra) {
>> +avc_tags_count = 
>> FF_ARRAY_ELEMS(mxf_avc_subdescriptor_local_tags);
>> +local_tag_number += avc_tags_count;
> 
> This will output a broken file if there's more than one XAVC stream.
> Not possible now I think, but will be a problem is someone decides to
> give higher operational patterns a try

Yes, it will get caught when this happens.

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

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

[Carl Eugen Hoyos]

Am Fr., 10. Mai 2019 um 17:15 Uhr schrieb Lynne :
>
> Patch updated again.
> Made some more cleanups to the transforms, the tables and the main context.
> API changed again, now the init function populates the function pointer for 
> transform.
> I decided that having a separate function would encourage bad usage (e.g. 
> calling
> the function every time before doing a transform rather than storing the 
> pointer) when
> we're trying to avoid the overhead of function calls.
> Also adjusted file names to match the API.

As said, this patch is not ok as long as the copyright statements are missing.

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] avfilter: add apitch filter

[Marton Balint]

On Sun, 12 May 2019, Nicolas George wrote:


Marton Balint (12019-05-12):

Why would you want to do pitch scaling and tempo scaling in a single filter?


Because that is the same thing.


Pitch scaling is a combo of asetrate and aresample as far as I understand.


You are mistaken: if you do that, you change the pitch and the tempo the
same way.


Yeah, you are right, what I had in mind was this:

apitch  ===  asetrate,aresample,atempo

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

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

Re: [FFmpeg-devel] [PATCH][TESTERS WANTED] avfilter: add apitch filter

[Paul B Mahol]

On 5/12/19, Nicolas George  wrote:
> Paul B Mahol (12019-05-12):
>> You can not merge filters by removing other filters as that will break
>> user scripts.
>
> I know how do avoid that, thank you very much.
>

How would you avoid that?
___
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 apitch filter

[Paul B Mahol]

On 5/12/19, Marton Balint  wrote:
>
>
> On Sun, 12 May 2019, Paul B Mahol wrote:
>
>> Signed-off-by: Paul B Mahol 
>> ---
>>
>> This filter can dynamically change both tempo and pitch of audio.
>> Also scale range is bigger, from 0.01 to 100.
>
> Why would you want to do pitch scaling and tempo scaling in a single
> filter? Pitch scaling is a combo of asetrate and aresample as far as I
> understand. Tempo scaling is what atempo/librubberband/scaletempo does.
>
> I have no use case in my head where doing both makes too much sense. Do
> you?

Than rubberband/scaletempo does not make much sense as they also allow changing
pitch and tempo at same time.
___
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][TESTERS WANTED] avfilter: add apitch filter

[Nicolas George]

Paul B Mahol (12019-05-12):
> You can not merge filters by removing other filters as that will break
> user scripts.

I know how do avoid that, thank you very much.

-- 
  Nicolas George


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][TESTERS WANTED] avfilter: add apitch filter

[Paul B Mahol]

On 5/12/19, Nicolas George  wrote:
> Paul B Mahol (12019-05-12):
>> We have both setsar and setdar,
>
> And that is a mistake. We should have a single "set" filter that can
> change all the transparent numeric properties of frames (sar, time base,
> timestamp, colorspace, etc.). One of the benefits: it can notify users
> who set inconsistent values instead of just overriding them.
>
> Merging all this is one of my easy TODO list items.

You can not merge filters by removing other filters as that will break
user scripts.
Also there is already setparams filter.
___
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 apitch filter

[Nicolas George]

Marton Balint (12019-05-12):
> Why would you want to do pitch scaling and tempo scaling in a single filter?

Because that is the same thing.

> Pitch scaling is a combo of asetrate and aresample as far as I understand.

You are mistaken: if you do that, you change the pitch and the tempo the
same way. I am sure you have at some point in your life heard an audio
recording played at a different speed, did you not?

Regards,

-- 
  Nicolas George


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][TESTERS WANTED] avfilter: add apitch filter

[Nicolas George]

Paul B Mahol (12019-05-12):
> We have both setsar and setdar,

And that is a mistake. We should have a single "set" filter that can
change all the transparent numeric properties of frames (sar, time base,
timestamp, colorspace, etc.). One of the benefits: it can notify users
who set inconsistent values instead of just overriding them.

Merging all this is one of my easy TODO list items.

> why should we not have both atempo and apitch?

Because a single filter that can do both is less confusing: users do not
need to hesitate about which one to use.

-- 
  Nicolas George


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] Discussion of all-inclusive full stack builds

[Tim Jones]

On May 12, 2019, at 11:54 AM, Nicolas George  wrote:
> 
> Tim Jones (12019-05-12):
> 
>> --disable-all-proprietary/--enable-all-proprietary
> 
> As for this one, on the other hand, there will be opposition: we do not
> want encourage users to use proprietary software. In fact, there is
> currently a discussion to refuse including new proprietary components,
> and possibly getting rid of the ones we included without thinking.

I don't want to start a thread war here, but isn't the purpose of any toolchain 
to allow for the support of a given task?  If there isn't a FOSS option and an 
easily obtained proprietary solution exists, why block it?

This is one of the things I hear from new Linux users when running into the 
FOSS vs. proprietary brick walls - they just want a platform that works.  The 
FUD that is continuously promoted concerning adding non-FOSS components - 
Nvidia drivers, ATTO drivers, HighPoint drivers, custom audio device drivers - 
has caused a number of potentially large Linux opportunities to move to Windows.

I've long been a proponent of FOSS where it is apropos, but I also understand 
Heinlein's TNSTAAFL :) .

--
Tim

___
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 apitch filter

[Marton Balint]

On Sun, 12 May 2019, Paul B Mahol wrote:


Signed-off-by: Paul B Mahol 
---

This filter can dynamically change both tempo and pitch of audio.
Also scale range is bigger, from 0.01 to 100.


Why would you want to do pitch scaling and tempo scaling in a single 
filter? Pitch scaling is a combo of asetrate and aresample as far as I 
understand. Tempo scaling is what atempo/librubberband/scaletempo does.


I have no use case in my head where doing both makes too much sense. Do 
you?


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

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

Re: [FFmpeg-devel] [PATCH][TESTERS WANTED] avfilter: add apitch filter

[Paul B Mahol]

On 5/12/19, Nicolas George  wrote:
> Paul B Mahol (12019-05-12):
>> Calling atempo filter atempo when it also modifies pitch is bad for users
>> and
>> at same time not having apitch filter, user would think that they can
>> not alter pitch.
>> Sorry if you can not understand my fears.
>
> As I have pointed to you (but you made a show of misunderstanding on
> purpose), changing the pitch and changing the speed of an audio signal
> are fundamentally the same thing, they are connected by the sample rate.
>
> In my experience, most people are aware of that, including completely
> non-technical people: they know that if you speed up or down a sound,
> its pitch changes.
>
> The documentation, of course, can be enhanced to make sure it contains
> all keyword a user is likely to search. And if the options can be
> tweaked to allow setting exactly the wanted output in the most
> convenient way (like we have a setdar, even though only the SAR exists
> in the library), it is even better.

We have both setsar and setdar, why should we not have both atempo and apitch?
___
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][TESTERS WANTED] avfilter: add apitch filter

[Nicolas George]

Tim Jones (12019-05-12):
> Coming from the audio world, tempo, and pitch are different things.

Tempo and pitch are not the same thing. But changing them is the same
thing.

Regards,

-- 
  Nicolas George


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 0/4] Add AVDRMFrameDescriptor.format field

[Jonas Karlman]

On 2019-05-12 19:28, Mark Thompson wrote:
> On 09/05/2019 20:38, Jonas Karlman wrote:
>> Hello,
>>
>> When a multi-layer AVDRMFrameDescriptor is used to describe a frame the 
>> overall
>> frame format is missing and applications need to deduce the frame 
>> DRM_FORMAT_*
>> based on sw_format or the layers format.
>>
>> This patchset adds a AVDRMFrameDescriptor.format field to remove any 
>> ambiguity
>> of what frame format a multi-layer descriptor may have.
>>
>> Kodi has up until now only supported single layer AVDRMFrameDescriptor,
>> when trying to add support for multi-layer frame descriptors [1],
>> we did not want to try and deduce the frame format, hence this patchset.
>>
>> [1] https://github.com/xbmc/xbmc/pull/16102
>>
>> Patch 1 adds a new field, format, to the AVDRMFrameDescriptor struct.
>> Patch 2-4 adds code to set the new format field.
>>
>> Regards,
>> Jonas
>>
>> ---
>>
>> Jonas Karlman (4):
>>   hwcontext_drm: Add AVDRMFrameDescriptor.format field
>>   hwcontext_vaapi: Set AVDRMFrameDescriptor.format in map_from
>>   rkmppdec: Set AVDRMFrameDescriptor.format
>>   kmsgrab: Set AVDRMFrameDescriptor.format
>>
>>  doc/APIchanges  |  3 +++
>>  libavcodec/rkmppdec.c   |  1 +
>>  libavdevice/kmsgrab.c   |  1 +
>>  libavutil/hwcontext_drm.h   |  4 
>>  libavutil/hwcontext_vaapi.c | 38 +
>>  libavutil/version.h |  4 ++--
>>  6 files changed, 49 insertions(+), 2 deletions(-)
> Can you argue why this case should be put in FFmpeg rather than constructing 
> the format you want in the client code?
>
> The intent of the existing format information is that each layer is 
> definitely usable as the specific format stated if the device supports that 
> format and format modifier.  That isn't true for the top-level format - some 
> devices enforce additional constraints which aren't visible.  For example, if 
> you take an R8 + GR88 frame from an AMD device, it probably won't work as 
> NV12 with Intel video hardware because there the whole frame is required to 
> be in one object (well, not quite - actually the offset from the luma plane 
> to the chroma plane just has some relatively small limit; in practice this 
> gets enforced as single-object, though), but it will work perfectly well as 
> R8 and GR88 planes.

The reason why I wanted to offload this to FFmpeg is that the top-level format 
is already known while the application would have to guess/calculate correct 
format to use when importing the video buffer into a drm plane.

The main issue we are facing is that kernel api do not have a distinction 
between single/multi layer/object when importing a video buffer into a 
framebuffer, drmModeAddFB2WithModifiers is expecting the top-level format 
regardless if the planes come from multiple objects or not.
(Kernel driver may still enforce additional constraints, e.g. on Rockchip the 
luma plane must be contiguous after chroma plane, and Allwinner have similar 
limits as Intel, chorma and luma plane must be in close proximity)

In order to support HDR video using a framebuffer tied to a drm plane on Intel, 
the top-level format passed to drmModeAddFB2WithModifiers must be P010 even if 
vaExportSurfaceHandle exports the video buffer as two layers, R16 + RG1616.

Changing vaapi_map_to_drm_esh in hwcontext_vaapi to try and use 
VA_EXPORT_SURFACE_COMPOSED_LAYERS and fallback to 
VA_EXPORT_SURFACE_SEPARATE_LAYERS could also work for our use case, the Intel 
vaapi driver support both export methods and AMD only the separate layers 
method.
From what I understand support for composed layers wont be added to AMD as it 
technically are multiple objects. I am not even sure if AMD have support for 
NV12 as a drm plane format.

Regards,
Jonas

>
> Thanks,
>
> - Mark

___
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][TESTERS WANTED] avfilter: add apitch filter

[Tim Jones]

On May 12, 2019, at 11:51 AM, Nicolas George  wrote:
> 
> Paul B Mahol (12019-05-12):
>> Calling atempo filter atempo when it also modifies pitch is bad for users and
>> at same time not having apitch filter, user would think that they can
>> not alter pitch.
>> Sorry if you can not understand my fears.
> 
> As I have pointed to you (but you made a show of misunderstanding on
> purpose), changing the pitch and changing the speed of an audio signal
> are fundamentally the same thing, they are connected by the sample rate.
> 
> In my experience, most people are aware of that, including completely
> non-technical people: they know that if you speed up or down a sound,
> its pitch changes.

Coming from the audio world, tempo, and pitch are different things.  Using a 
smart algorithm. I can speed up the tempo of clip without changing the pitch.  
Or, inversely, I can modify the pitch without changing the tempo.  We look at 
"tempo" as beats per period (usually minutes).  We look at pitch as the "tone 
and timbre" of a given sound (transposing a note from D to F#, for example).

> The documentation, of course, can be enhanced to make sure it contains
> all keyword a user is likely to search. And if the options can be
> tweaked to allow setting exactly the wanted output in the most
> convenient way (like we have a setdar, even though only the SAR exists
> in the library), it is even better.

This would be helpful since I had previously looked into adjusting the playback 
rate without the associate "Alvin and the Chipmunks" effect and didn't uncover 
anything within a deep DDG and Google search.

--
Tim

___
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] Discussion of all-inclusive full stack builds

[Nicolas George]

Tim Jones (12019-05-12):
> Has anyone previously discussed or offered up a simplified set of
> config macros for something like:

Options to have auto-detection of external libraries enabled have been
suggested in the past.

> --disable-all-proprietary/--enable-all-proprietary

As for this one, on the other hand, there will be opposition: we do not
want encourage users to use proprietary software. In fact, there is
currently a discussion to refuse including new proprietary components,
and possibly getting rid of the ones we included without thinking.

Regards,

-- 
  Nicolas George


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][TESTERS WANTED] avfilter: add apitch filter

[Nicolas George]

Paul B Mahol (12019-05-12):
> Calling atempo filter atempo when it also modifies pitch is bad for users and
> at same time not having apitch filter, user would think that they can
> not alter pitch.
> Sorry if you can not understand my fears.

As I have pointed to you (but you made a show of misunderstanding on
purpose), changing the pitch and changing the speed of an audio signal
are fundamentally the same thing, they are connected by the sample rate.

In my experience, most people are aware of that, including completely
non-technical people: they know that if you speed up or down a sound,
its pitch changes.

The documentation, of course, can be enhanced to make sure it contains
all keyword a user is likely to search. And if the options can be
tweaked to allow setting exactly the wanted output in the most
convenient way (like we have a setdar, even though only the SAR exists
in the library), it is even better.

-- 
  Nicolas George


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

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

[FFmpeg-devel] Discussion of all-inclusive full stack builds

[Tim Jones]

Hi Folks,

I've long been a fanatic for ffmpeg and now have the bandwidth to dip my toes 
into the developer pool.  My primary experience is in file I/O in C, C++ , and 
Python, and I force my team to pay close attention to smaller-is-better 
refactoring.

With the enormous number of config options, newcomers to the development side 
of things (yes, that means me, too) can find the inclusion of a specific 
capability to be quite daunting (and I've been coding since before autoconf 
existed).

Has anyone previously discussed or offered up a simplified set of config macros 
for something like:

--disable-all-proprietary/--enable-all-proprietary

I have run into situations where I've needed to recompile to meet a specific 
situation that could have been easily handled by simply enabling everything - 
regardless of it's status as FOSS or proprietary.

If such a build level were created, would there be a recognizable performance 
hit with such an option?

--
Tim

___
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 asr filter

[Paul B Mahol]

On 5/11/19, Paul B Mahol  wrote:
> On 5/5/19, Paul B Mahol  wrote:
>> Signed-off-by: Paul B Mahol 
>> ---
>>  configure|   4 +
>>  doc/filters.texi |  32 +++
>>  libavfilter/Makefile |   1 +
>>  libavfilter/af_asr.c | 177 +++
>>  libavfilter/allfilters.c |   1 +
>>  5 files changed, 215 insertions(+)
>>  create mode 100644 libavfilter/af_asr.c
>>
>
> Will apply.

Because nobody is against this will be applied in next 24h.
___
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][TESTERS WANTED] avfilter: add apitch filter

[Paul B Mahol]

On 5/12/19, Nicolas George  wrote:
> Paul B Mahol (12019-05-12):
>> That is hard problem, how would one know what implementation is best for
>> user scenario.
>
> Better developers who know the limits of their filters than users who do
> not know.
>
>> I disagree, current filter have artifacts with small scale factors.
>
> And that is what you are about to fix, is it not?
>
>> Looks like I missed to explain it in more fashion to you full
>> understanding,
>> it is filter that uses external library, do you still insist it to be
>> part of atempo?
>
> I know that. And yes, of course.
>
>> Looks like you missed to understand my detailed explanation.
>> Lets try it to explain in again, in more detailed fashion:
>> I mean there would be two filters doing same thing:
>> apitch with 1st option pitch and 2nd option tempo.
>> atempo with 1st option tempo and 2nd option pitch.
>> These filters would share same C file.
>
> Indeed, I missed the fact that you did not understand:
>
> No, there will no be an apitch filter, whether it lives in af_apitch.c
> or af_atempo.c. There will be a single filter, named atempo, that will
> bring the best quality to all users, existing and new ones.

Calling atempo filter atempo when it also modifies pitch is bad for users and
at same time not having apitch filter, user would think that they can
not alter pitch.
Sorry if you can not understand my fears.
___
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][TESTERS WANTED] avfilter: add apitch filter

[Nicolas George]

Paul B Mahol (12019-05-12):
> That is hard problem, how would one know what implementation is best for
> user scenario.

Better developers who know the limits of their filters than users who do
not know.

> I disagree, current filter have artifacts with small scale factors.

And that is what you are about to fix, is it not?

> Looks like I missed to explain it in more fashion to you full understanding,
> it is filter that uses external library, do you still insist it to be
> part of atempo?

I know that. And yes, of course.

> Looks like you missed to understand my detailed explanation.
> Lets try it to explain in again, in more detailed fashion:
> I mean there would be two filters doing same thing:
> apitch with 1st option pitch and 2nd option tempo.
> atempo with 1st option tempo and 2nd option pitch.
> These filters would share same C file.

Indeed, I missed the fact that you did not understand:

No, there will no be an apitch filter, whether it lives in af_apitch.c
or af_atempo.c. There will be a single filter, named atempo, that will
bring the best quality to all users, existing and new ones.

-- 
  Nicolas George


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][TESTERS WANTED] avfilter: add apitch filter

[Paul B Mahol]

Hi,

On 5/12/19, Nicolas George  wrote:
> Paul B Mahol (12019-05-11):
>> It is currently separate filter for ease of testing.
>
> Then no problem. But I insist: once it is in shape, for the convenience
> of the users and ease of maintenance, it should be a single filter.
>
> Of course, if you disagree, we can discuss it here.
>
>> It can not be "part" of current atempo implementation for numerous
>> reasons,
>> most significant one being bad output quality with < 1 tempo scale
>> factor of current atempo implementation.
>
> This is one of the reasons it should be a single filter: the users
> should not need to know the arbitrary limits of different filters
> implementation. The filters are there to perform a task, and they should
> select the best implementation for it automatically.

That is hard problem, how would one know what implementation is best for
user scenario.

>
>> Also current atempo implementation have limits for minimal scale
>> reduction,
>
> IIRC, the limits were rather arbitrary. But even if they are not, my
> point stand: the filter should select the best implementation for the
> requested parameters, automatically without bothering the users.

I disagree, current filter have artifacts with small scale factors.

>
>> unlike rubberband filter in libavfilter. Also rubberband filter having
>> similar and bigger functionality.
>
> Oh, great, another filter with the same task. If I had noticed at the
> time, I would have insisted that it be part of atempo too at the time.

Looks like I missed to explain it in more fashion to you full understanding,
it is filter that uses external library, do you still insist it to be
part of atempo?

>
>> That's way I request for quality testers.
>> Best would be to compare this filter with rubberband and current atempo
>> filter.
>>
>> This filter is supposed to be current atempo full replacement.
>> (atempo would be just this filter but with same first two options but
>> with swapped positions).
>
> Swapping the position will break existing scripts. It should be avoided.

Looks like you missed to understand my detailed explanation.
Lets try it to explain in again, in more detailed fashion:
I mean there would be two filters doing same thing:
apitch with 1st option pitch and 2nd option tempo.
atempo with 1st option tempo and 2nd option pitch.
These filters would share same C file.

Regards, have a nice day
___
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 05:58:50PM +0100, Mark Thompson wrote:
> On 12/05/2019 16:24, 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
> > 
> > 
> > From f815a2481a19cfd191b9f97e246b307b71d6c790 Mon Sep 17 00:00:00 2001
> > From: Adam Richter 
> > Date: Sun, 12 May 2019 08:02:51 -0700
> > Subject: [PATCH] "assert(a && b)" --> "assert(a); assert(b)" for more
> >  precise diagnostics, except for libformat.
> > 
> > This patch separates statements of the form "assert(a && b);" into
> > "assert(a);" and "assert(b);", for more precise diagnostics when
> > an assertion fails, which can be especially important in cases where
> > the problem may not be easily reproducible and save developer time.
> > Usually, this involves functions like av_assert0.
> 
> I don't feel very convinced by the general case of this argument.  Assertions 
> are primarily present to assist a developer reading/writing the code; they 
> should never be triggering at runtime in non-development contexts.
> 
> Where the statements a and b are not related then yes, splitting them is a 
> good idea.  But when it's something like a bounds check on one variable 
> ("av_assert0(A < n && n < B)", as appears quite a few times below) then I 
> think keeping it as one statement feels clearer.  Similarly for highly 
> related conditions ("av_assert0(p && p->f)" or "av_assert0(x < width && y < 
> height)").
> 
> > There are a couple of cases that this patch does not change:
> > (1) assert conjunctions of the form assert(condition && "string literal
> > to pass to the user as a helpful tip."), and
> > (2) assert condjunctions where the first part contained a variable
> > assignment that was used in the second part of the assertion and
> > not outside the assert (so that the variable assignment be elided
> > if the assertion checking omitted).
> > 
> > This patch covers all of ffmpeg except for libavformat, which was
> > covered in a patch that I previously submitted separately.
> > 
> > These changes build without any new complaints that I noticed, and
> > "make fate" succeeds, but I have not otherwise tested them.
> > 
> > Signed-off-by: Adam Richter 
> > ...
> > diff --git a/libavcodec/aacpsy.c b/libavcodec/aacpsy.c
> > index fca692cb15..bef52e8b02 100644
> > --- a/libavcodec/aacpsy.c
> > +++ b/libavcodec/aacpsy.c
> > @@ -504,9 +504,11 @@ static int calc_bit_demand(AacPsyContext *ctx, float 
> > pe, int bits, int size,
> >  fill_level = av_clipf((float)ctx->fill_level / size, clip_low, 
> > clip_high);
> >  clipped_pe = av_clipf(pe, ctx->pe.min, ctx->pe.max);
> >  bit_save   = (fill_level + bitsave_add) * bitsave_slope;
> > -assert(bit_save <= 0.3f && bit_save >= -0.0501f);
> > +assert(bit_save <= 0.3f);
> > +assert(bit_save >= -0.0501f);
> >  bit_spend  = (fill_level + bitspend_add) * bitspend_slope;
> > -assert(bit_spend <= 0.5f && bit_spend >= -0.1f);
> > +assert(bit_spend <= 0.5f);
> > +assert(bit_spend >= -0.1f);
> 
> While you're touching calls to traditional assert() please consider turning 
> them into suitable av_assertN().

I agree that they should be changed to av_assertN() but it should be
in a seperate commit/patch

These assert -> av_assertN changes will likely in some cases "activate"
"dormant" checks which fail. Managing / Testing / Reviewing and correcting
these should be easier if they are not in a large change splitting asserts

Thanks

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

"You are 36 times more likely to die in a bathtub than at the hands of a
terrorist. Also, you are 2.5 times more likely to become a president and
2 times more likely to become an astronaut, than to die in a terrorist
attack." -- Thoughty2



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][TESTERS WANTED] avfilter: add apitch filter

[Nicolas George]

Paul B Mahol (12019-05-11):
> It is currently separate filter for ease of testing.

Then no problem. But I insist: once it is in shape, for the convenience
of the users and ease of maintenance, it should be a single filter.

Of course, if you disagree, we can discuss it here.

> It can not be "part" of current atempo implementation for numerous reasons,
> most significant one being bad output quality with < 1 tempo scale
> factor of current atempo implementation.

This is one of the reasons it should be a single filter: the users
should not need to know the arbitrary limits of different filters
implementation. The filters are there to perform a task, and they should
select the best implementation for it automatically.

> Also current atempo implementation have limits for minimal scale
> reduction,

IIRC, the limits were rather arbitrary. But even if they are not, my
point stand: the filter should select the best implementation for the
requested parameters, automatically without bothering the users.

> unlike rubberband filter in libavfilter. Also rubberband filter having
> similar and bigger functionality.

Oh, great, another filter with the same task. If I had noticed at the
time, I would have insisted that it be part of atempo too at the time.

> That's way I request for quality testers.
> Best would be to compare this filter with rubberband and current atempo 
> filter.
> 
> This filter is supposed to be current atempo full replacement.
> (atempo would be just this filter but with same first two options but
> with swapped positions).

Swapping the position will break existing scripts. It should be avoided.

> Options are self-explanatory, at least first two.
> Documentation will appear later.

Ok.

-- 
  Nicolas George


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/4] hwcontext_drm: Add AVDRMFrameDescriptor.format field

[Mark Thompson]

On 09/05/2019 20:40, Jonas Karlman wrote:
> A AVDRMFrameDescriptor for a NV12 frame may be described in
> a single layer descriptor with multiple planes,
> 
> (AVDRMFrameDescriptor) {
> .nb_layers = 1,
> .layers[0] = {
> .format   = DRM_FORMAT_NV12,
> .nb_planes= 2,
> .planes[0] = {
> .object_index = 0,
> },
> .planes[1] = {
> .object_index = 0,
> },
> },
> }
> 
> or a multi-layer descriptor with one plane in each layer.
> 
> (AVDRMFrameDescriptor) {
> .nb_layers = 2,
> .layers[0] = {
> .format   = DRM_FORMAT_R8,
> .nb_planes= 1,
> .planes[0] = {
> .object_index = 0,
> },
> },
> .layers[1] = {
> .format   = DRM_FORMAT_RG88,
> .nb_planes= 1,
> .planes[0] = {
> .object_index = 1,
> },
> },
> }
> 
> With a multi-layer descriptor, the frame format is missing.
> 
> Add a AVDRMFrameDescriptor.format field to remove any ambiguity of
> what frame format a multi-layer descriptor may have.
> 
> Signed-off-by: Jonas Karlman 
> ---
>  doc/APIchanges| 3 +++
>  libavutil/hwcontext_drm.h | 4 
>  libavutil/version.h   | 4 ++--
>  3 files changed, 9 insertions(+), 2 deletions(-)

Can you explain carefully the rationale for why the ABI change is ok, and add 
it to the commit message?

It looks like it might be ok (the most obvious failure mode doesn't happen 
because you're avoiding adding any reads of the field in FFmpeg), but I'm not 
entirely sure so an explicit comment would be helpful.

> diff --git a/doc/APIchanges b/doc/APIchanges
> index e75c4044ce..d9c21ec030 100644
> --- a/doc/APIchanges
> +++ b/doc/APIchanges
> @@ -15,6 +15,9 @@ libavutil: 2017-10-21
>  
>  API changes, most recent first:
>  
> +2019-05-08 - xx - lavu 56.27.100 - hwcontext_drm.h
> +  Add AVDRMFrameDescriptor.format.
> +
>  2019-04-20 - 3153a6502a - lavc 58.52.100 - avcodec.h
>Add AV_CODEC_FLAG_DROPCHANGED to allow avcodec_receive_frame to drop
>frames whose parameters differ from first decoded frame in stream.
> diff --git a/libavutil/hwcontext_drm.h b/libavutil/hwcontext_drm.h
> index 42709f215e..0ccbd19acc 100644
> --- a/libavutil/hwcontext_drm.h
> +++ b/libavutil/hwcontext_drm.h
> @@ -147,6 +147,10 @@ typedef struct AVDRMFrameDescriptor {
>   * Array of layers in the frame.
>   */
>  AVDRMLayerDescriptor layers[AV_DRM_MAX_PLANES];
> +/**
> + * Format of the frame (DRM_FORMAT_*).
> + */
> +uint32_t format;

Probably wants a note that it need not be set, since there may not be a 
specific format for the whole frame.  I guess it should be DRM_FORMAT_INVALID 
in that case?

>  } AVDRMFrameDescriptor;
>  
>  /**
> diff --git a/libavutil/version.h b/libavutil/version.h
> index c0968de621..12b4f9fc3a 100644
> --- a/libavutil/version.h
> +++ b/libavutil/version.h
> @@ -79,8 +79,8 @@
>   */
>  
>  #define LIBAVUTIL_VERSION_MAJOR  56
> -#define LIBAVUTIL_VERSION_MINOR  26
> -#define LIBAVUTIL_VERSION_MICRO 101
> +#define LIBAVUTIL_VERSION_MINOR  27
> +#define LIBAVUTIL_VERSION_MICRO 100
>  
>  #define LIBAVUTIL_VERSION_INT   AV_VERSION_INT(LIBAVUTIL_VERSION_MAJOR, \
> LIBAVUTIL_VERSION_MINOR, \
> 

Thanks,

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

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

Re: [FFmpeg-devel] [PATCH 0/4] Add AVDRMFrameDescriptor.format field

[Mark Thompson]

On 09/05/2019 20:38, Jonas Karlman wrote:
> Hello,
> 
> When a multi-layer AVDRMFrameDescriptor is used to describe a frame the 
> overall
> frame format is missing and applications need to deduce the frame DRM_FORMAT_*
> based on sw_format or the layers format.
> 
> This patchset adds a AVDRMFrameDescriptor.format field to remove any ambiguity
> of what frame format a multi-layer descriptor may have.
> 
> Kodi has up until now only supported single layer AVDRMFrameDescriptor,
> when trying to add support for multi-layer frame descriptors [1],
> we did not want to try and deduce the frame format, hence this patchset.
> 
> [1] https://github.com/xbmc/xbmc/pull/16102
> 
> Patch 1 adds a new field, format, to the AVDRMFrameDescriptor struct.
> Patch 2-4 adds code to set the new format field.
> 
> Regards,
> Jonas
> 
> ---
> 
> Jonas Karlman (4):
>   hwcontext_drm: Add AVDRMFrameDescriptor.format field
>   hwcontext_vaapi: Set AVDRMFrameDescriptor.format in map_from
>   rkmppdec: Set AVDRMFrameDescriptor.format
>   kmsgrab: Set AVDRMFrameDescriptor.format
> 
>  doc/APIchanges  |  3 +++
>  libavcodec/rkmppdec.c   |  1 +
>  libavdevice/kmsgrab.c   |  1 +
>  libavutil/hwcontext_drm.h   |  4 
>  libavutil/hwcontext_vaapi.c | 38 +
>  libavutil/version.h |  4 ++--
>  6 files changed, 49 insertions(+), 2 deletions(-)

Can you argue why this case should be put in FFmpeg rather than constructing 
the format you want in the client code?

The intent of the existing format information is that each layer is definitely 
usable as the specific format stated if the device supports that format and 
format modifier.  That isn't true for the top-level format - some devices 
enforce additional constraints which aren't visible.  For example, if you take 
an R8 + GR88 frame from an AMD device, it probably won't work as NV12 with 
Intel video hardware because there the whole frame is required to be in one 
object (well, not quite - actually the offset from the luma plane to the chroma 
plane just has some relatively small limit; in practice this gets enforced as 
single-object, though), but it will work perfectly well as R8 and GR88 planes.

Thanks,

- Mark
___
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

[Mark Thompson]

On 12/05/2019 16:24, 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
> 
> 
> From f815a2481a19cfd191b9f97e246b307b71d6c790 Mon Sep 17 00:00:00 2001
> From: Adam Richter 
> Date: Sun, 12 May 2019 08:02:51 -0700
> Subject: [PATCH] "assert(a && b)" --> "assert(a); assert(b)" for more
>  precise diagnostics, except for libformat.
> 
> This patch separates statements of the form "assert(a && b);" into
> "assert(a);" and "assert(b);", for more precise diagnostics when
> an assertion fails, which can be especially important in cases where
> the problem may not be easily reproducible and save developer time.
> Usually, this involves functions like av_assert0.

I don't feel very convinced by the general case of this argument.  Assertions 
are primarily present to assist a developer reading/writing the code; they 
should never be triggering at runtime in non-development contexts.

Where the statements a and b are not related then yes, splitting them is a good 
idea.  But when it's something like a bounds check on one variable 
("av_assert0(A < n && n < B)", as appears quite a few times below) then I think 
keeping it as one statement feels clearer.  Similarly for highly related 
conditions ("av_assert0(p && p->f)" or "av_assert0(x < width && y < height)").

> There are a couple of cases that this patch does not change:
> (1) assert conjunctions of the form assert(condition && "string literal
> to pass to the user as a helpful tip."), and
> (2) assert condjunctions where the first part contained a variable
> assignment that was used in the second part of the assertion and
> not outside the assert (so that the variable assignment be elided
> if the assertion checking omitted).
> 
> This patch covers all of ffmpeg except for libavformat, which was
> covered in a patch that I previously submitted separately.
> 
> These changes build without any new complaints that I noticed, and
> "make fate" succeeds, but I have not otherwise tested them.
> 
> Signed-off-by: Adam Richter 
> ...
> diff --git a/libavcodec/aacpsy.c b/libavcodec/aacpsy.c
> index fca692cb15..bef52e8b02 100644
> --- a/libavcodec/aacpsy.c
> +++ b/libavcodec/aacpsy.c
> @@ -504,9 +504,11 @@ static int calc_bit_demand(AacPsyContext *ctx, float pe, 
> int bits, int size,
>  fill_level = av_clipf((float)ctx->fill_level / size, clip_low, 
> clip_high);
>  clipped_pe = av_clipf(pe, ctx->pe.min, ctx->pe.max);
>  bit_save   = (fill_level + bitsave_add) * bitsave_slope;
> -assert(bit_save <= 0.3f && bit_save >= -0.0501f);
> +assert(bit_save <= 0.3f);
> +assert(bit_save >= -0.0501f);
>  bit_spend  = (fill_level + bitspend_add) * bitspend_slope;
> -assert(bit_spend <= 0.5f && bit_spend >= -0.1f);
> +assert(bit_spend <= 0.5f);
> +assert(bit_spend >= -0.1f);

While you're touching calls to traditional assert() please consider turning 
them into suitable av_assertN().

- Mark
___
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

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

- Mark
___
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] "assert(a && b)" --> "assert(a); assert(b)" for more precise diagnostics, except for libformat

[Adam Richter]

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
From f815a2481a19cfd191b9f97e246b307b71d6c790 Mon Sep 17 00:00:00 2001
From: Adam Richter 
Date: Sun, 12 May 2019 08:02:51 -0700
Subject: [PATCH] "assert(a && b)" --> "assert(a); assert(b)" for more
 precise diagnostics, except for libformat.

This patch separates statements of the form "assert(a && b);" into
"assert(a);" and "assert(b);", for more precise diagnostics when
an assertion fails, which can be especially important in cases where
the problem may not be easily reproducible and save developer time.
Usually, this involves functions like av_assert0.

There are a couple of cases that this patch does not change:
(1) assert conjunctions of the form assert(condition && "string literal
to pass to the user as a helpful tip."), and
(2) assert condjunctions where the first part contained a variable
assignment that was used in the second part of the assertion and
not outside the assert (so that the variable assignment be elided
if the assertion checking omitted).

This patch covers all of ffmpeg except for libavformat, which was
covered in a patch that I previously submitted separately.

These changes build without any new complaints that I noticed, and
"make fate" succeeds, but I have not otherwise tested them.

Signed-off-by: Adam Richter 
---
 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 +-
 

Re: [FFmpeg-devel] [PATCH 2/3] swscale: Add support for NV24 and NV42

[Philip Langdale]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Sun, 12 May 2019 12:54:24 +0200
Michael Niedermayer  wrote:

> 
> all these + 1 in the code above look a bit suspect. Can you explain
> what they do assuming they are intended

Good catch. I should have removed them when I removed the divide by 2.
 
> [...]
> > diff --git a/libswscale/utils.c b/libswscale/utils.c
> > index df68bcc0d9..1b1f779532 100644
> > --- a/libswscale/utils.c
> > +++ b/libswscale/utils.c
> > @@ -264,6 +264,8 @@ static const FormatEntry
> > format_entries[AV_PIX_FMT_NB] = { [AV_PIX_FMT_YUVA422P12LE] = { 1,
> > 1 }, [AV_PIX_FMT_YUVA444P12BE] = { 1, 1 },
> >  [AV_PIX_FMT_YUVA444P12LE] = { 1, 1 },
> > +[AV_PIX_FMT_NV24]= { 1, 1 },
> > +[AV_PIX_FMT_NV42]= { 1, 1 },  
> 
> nitpick: this can be aligned prettier

They are aligned to the primary alignment within the list. The lines
above are exceptions to the existing pattern due to their length.

Thanks,

- --phil
-BEGIN PGP SIGNATURE-

iHUEARYIAB0WIQRokRbWmcX6x+Nv+3hgE8jODULZ6QUCXNgw0gAKCRBgE8jODULZ
6ZHpAPoDp3JcLdqjlWr/mo0luxS0UNHwonKuFU04Dpz8FYkw9AD8DL1DC4czUMT7
qPodwqeGY6xKpeNwf6f7OL78pHP3FAM=
=+hv7
-END 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

[Tomas Härdin]

fre 2019-05-10 klockan 08:50 -0700 skrev Baptiste Coudurier:
> +static inline int get_ue_golomb(GetBitContext *gb) {
> +int i, v;
> +for (i = 0; i < 32 && !get_bits1(gb); i++)
> +;
> +for (v = 1; i--;)
> +v = (v << 1) | get_bits1(gb);

Isn't there already a function to get variable number of bits?

> +return v - 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

Why not just get 6 bits at once?

> +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
 
> +static void mxf_write_local_tags(AVIOContext *pb, const MXFLocalTagPair 
> *local_tags, int count)
> +{
> +int i;
> +for (i = 0; i < count; i++) {
> +avio_wb16(pb, local_tags[i].local_tag);
> +avio_write(pb, local_tags[i].uid, 16);
> +}
> +}

This function could be used to simplify mxf_write_primer_pack(). But
that probably belongs in a separate patch.

> +
>  static void mxf_write_primer_pack(AVFormatContext *s)
>  {
>  MXFContext *mxf = s->priv_data;
>  AVIOContext *pb = s->pb;
>  int local_tag_number, i = 0;
> +int avc_tags_count = 0;
>  
>  local_tag_number = FF_ARRAY_ELEMS(mxf_local_tag_batch);
>  local_tag_number += mxf->store_user_comments * 
> FF_ARRAY_ELEMS(mxf_user_comments_local_tag);
>  
> +for (i = 0; i < s->nb_streams; i++) {
> +MXFStreamContext *sc = s->streams[i]->priv_data;
> +if (s->streams[i]->codecpar->codec_id == AV_CODEC_ID_H264 && 
> !sc->avc_intra) {
> +avc_tags_count = 
> FF_ARRAY_ELEMS(mxf_avc_subdescriptor_local_tags);
> +local_tag_number += avc_tags_count;

This will output a broken file if there's more than one XAVC stream.
Not possible now I think, but will be a problem is someone decides to
give higher operational patterns a try

> +}
> +}
> +
>  avio_write(pb, primer_pack_key, 16);
>  klv_encode_ber_length(pb, local_tag_number * 18 + 8);
>  
> @@ -608,6 +637,8 @@ static void mxf_write_primer_pack(AVFormatContext *s)
>  avio_wb16(pb, mxf_user_comments_local_tag[i].local_tag);
>  avio_write(pb, mxf_user_comments_local_tag[i].uid, 16);
>  }
> +if (avc_tags_count > 0)
> +mxf_write_local_tags(pb, mxf_avc_subdescriptor_local_tags, 
> avc_tags_count);
>  }

No other comments for now. Don't know enough about SPS/PPS stuff to
comment on specifics about that.

/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 1/2] VP4 video decoder

[James Almer]

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.
Also, if you have distributable vp4 samples at hand, you should make at
least one fate decoding test.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [PATCH] avcodec/wmv2dec: Check input bits vs. coded MBs

[Michael Niedermayer]

On Wed, May 01, 2019 at 01:45:21AM +0200, Michael Niedermayer wrote:
> Fixes: Timeout (94sec ->8sec)
> Fixes: 
> 14387/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_WMV2_fuzzer-5723546887651328
> 
> Found-by: continuous fuzzing process 
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by: Michael Niedermayer 
> ---
>  libavcodec/wmv2dec.c | 9 +
>  1 file changed, 9 insertions(+)

will apply


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

He who knows, does not speak. He who speaks, does not know. -- Lao Tsu


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

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

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

[Adam Richter]

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
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 
---
 libavformat/au.c  | 3 ++-
 libavformat/avienc.c  | 3 ++-
 libavformat/aviobuf.c | 3 ++-
 libavformat/matroskaenc.c | 6 --
 libavformat/mov.c | 3 ++-
 libavformat/rtmppkt.c | 3 ++-
 libavformat/utils.c   | 9 +
 7 files changed, 19 insertions(+), 11 deletions(-)

diff --git a/libavformat/au.c b/libavformat/au.c
index cb48e67feb..76f23de56d 100644
--- a/libavformat/au.c
+++ b/libavformat/au.c
@@ -177,7 +177,8 @@ static int au_read_header(AVFormatContext *s)
 bps = 2;
 } else {
 const uint8_t bpcss[] = {4, 0, 3, 5};
-av_assert0(id >= 23 && id < 23 + 4);
+av_assert0(id >= 23);
+av_assert0(id < 23 + 4);
 ba = bpcss[id - 23];
 bps = bpcss[id - 23];
 }
diff --git a/libavformat/avienc.c b/libavformat/avienc.c
index ac0f04c354..e96eb27e5e 100644
--- a/libavformat/avienc.c
+++ b/libavformat/avienc.c
@@ -797,7 +797,8 @@ static int avi_write_packet(AVFormatContext *s, AVPacket *pkt)
 int pal_size = 1 << par->bits_per_coded_sample;
 int pc_tag, i;
 
-av_assert0(par->bits_per_coded_sample >= 0 && par->bits_per_coded_sample <= 8);
+av_assert0(par->bits_per_coded_sample >= 0);
+av_assert0(par->bits_per_coded_sample <= 8);
 
 if ((pb->seekable & AVIO_SEEKABLE_NORMAL) && avist->pal_offset) {
 int64_t cur_offset = avio_tell(pb);
diff --git a/libavformat/aviobuf.c b/libavformat/aviobuf.c
index 5a33f82950..e71846e0e8 100644
--- a/libavformat/aviobuf.c
+++ b/libavformat/aviobuf.c
@@ -195,7 +195,8 @@ static void flush_buffer(AVIOContext *s)
 
 void avio_w8(AVIOContext *s, int b)
 {
-av_assert2(b>=-128 && b<=255);
+av_assert2(b >= -128);
+av_assert2(b <= 255);
 *s->buf_ptr++ = b;
 if (s->buf_ptr >= s->buf_end)
 flush_buffer(s);
diff --git a/libavformat/matroskaenc.c b/libavformat/matroskaenc.c
index cef504fa05..51b6d1b16f 100644
--- a/libavformat/matroskaenc.c
+++ b/libavformat/matroskaenc.c
@@ -589,7 +589,8 @@ static int64_t mkv_write_cues(AVFormatContext *s, mkv_cues *cues, mkv_track *tra
 tracks[j].has_cue = 0;
 for (j = 0; j < cues->num_entries - i && entry[j].pts == pts; j++) {
 int tracknum = entry[j].stream_idx;
-av_assert0(tracknum>=0 && tracknum= 0);
+av_assert0(tracknum < num_tracks);
 if (tracks[tracknum].has_cue && s->streams[tracknum]->codecpar->codec_type != AVMEDIA_TYPE_SUBTITLE)
 continue;
 tracks[tracknum].has_cue = 1;
@@ -605,7 +606,8 @@ static int64_t mkv_write_cues(AVFormatContext 

Re: [FFmpeg-devel] [PATCH] avcodec/h264_ps: Check offset_for_non_ref_pic and offset_for_top_to_bottom_field

[Michael Niedermayer]

On Sat, May 11, 2019 at 03:35:26PM -0300, James Almer wrote:
> On 5/11/2019 2:59 PM, Michael Niedermayer wrote:
> > Fixes: signed integer overflow: -2147483648 + -1 cannot be represented in 
> > type 'int'
> > Fixes: 
> > 1/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_H264_fuzzer-5675880333967360
> > 
> > Found-by: continuous fuzzing process 
> > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> > Signed-off-by: Michael Niedermayer 
> > ---
> >  libavcodec/h264_ps.c | 9 +
> >  1 file changed, 9 insertions(+)
> > 
> > diff --git a/libavcodec/h264_ps.c b/libavcodec/h264_ps.c
> > index 7c92c68b38..e38cf2a533 100644
> > --- a/libavcodec/h264_ps.c
> > +++ b/libavcodec/h264_ps.c
> > @@ -451,6 +451,15 @@ int ff_h264_decode_seq_parameter_set(GetBitContext 
> > *gb, AVCodecContext *avctx,
> >  sps->delta_pic_order_always_zero_flag = get_bits1(gb);
> >  sps->offset_for_non_ref_pic   = get_se_golomb_long(gb);
> >  sps->offset_for_top_to_bottom_field   = get_se_golomb_long(gb);
> > +
> > +if (   sps->offset_for_non_ref_pic == INT32_MIN
> > +|| sps->offset_for_top_to_bottom_field == INT32_MIN
> > +) {
> > +av_log(avctx, AV_LOG_ERROR,
> > +   "offset_for_non_ref_pic or 
> > offset_for_top_to_bottom_field underflow\n");
> > +goto fail;
> > +}
> 
> The valid range is INT32_MIN + 1 to INT32_MAX, so it should be good. But
> maybe the error message should instead say it's out of range?
> 
> Fwiw, there's another get_se_golomb_long() call right below these, with
> the same range constrains.

will fix all cases togteher and use suggested error message

Thanks

[...]
-- 
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] [PATCHv2] lavfi: add gblur_opencl filter

[Paul B Mahol]

On 5/8/19, Song, Ruiling  wrote:
>
>
>> -Original Message-
>> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
>> Of Dylan Fernando
>> Sent: Tuesday, May 7, 2019 8:27 AM
>> To: ffmpeg-devel@ffmpeg.org
>> Subject: Re: [FFmpeg-devel] [PATCHv2] lavfi: add gblur_opencl filter
>>
>> Anyone have any comments/feedback?
> I think unsharp_opencl with a negative amount should do similar thing as
> this one.

Not really.

> What's the difference? Better quality? or better speed?

This one can blur image with larger radius.

But why step parameter was removed?
___
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] libswcale: Fix possible string overflow in test

[Adam Richter]

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

Signed-off-by: Adam Richter 
---
 libswscale/tests/swscale.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/libswscale/tests/swscale.c b/libswscale/tests/swscale.c
index e72c4c3306..cb731f6211 100644
--- a/libswscale/tests/swscale.c
+++ b/libswscale/tests/swscale.c
@@ -312,10 +312,10 @@ static int fileTest(const uint8_t * const ref[4], int refStride[4],
 while (fgets(buf, sizeof(buf), fp)) {
 struct Results r;
 enum AVPixelFormat srcFormat;
-char srcStr[12];
+char srcStr[13];
 int srcW = 0, srcH = 0;
 enum AVPixelFormat dstFormat;
-char dstStr[12];
+char dstStr[13];
 int dstW = 0, dstH = 0;
 int flags;
 int ret;
-- 
2.21.0

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

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

Re: [FFmpeg-devel] [PATCH] avcodec/hq_hqa: Check available space before reading slice offsets

[Michael Niedermayer]

On Sun, May 12, 2019 at 09:45:59AM +0200, Paul B Mahol wrote:
> On 5/12/19, Michael Niedermayer  wrote:
> > Fixes: Timeout (43sec -> 18sec)
> > Fixes:
> > 14556/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_HQ_HQA_fuzzer-5673543024508928
> >
> > Found-by: continuous fuzzing process
> > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> > Signed-off-by: Michael Niedermayer 
> > ---
> >  libavcodec/hq_hqa.c | 3 +++
> >  1 file changed, 3 insertions(+)
> >
> > diff --git a/libavcodec/hq_hqa.c b/libavcodec/hq_hqa.c
> > index ec9da3e04f..90bafdc72a 100644
> > --- a/libavcodec/hq_hqa.c
> > +++ b/libavcodec/hq_hqa.c
> > @@ -248,6 +248,9 @@ static int hqa_decode_frame(HQContext *ctx, AVFrame
> > *pic, size_t data_size)
> >  int width, height, quant;
> >  const uint8_t *src = ctx->gbc.buffer;
> >
> > +if (bytestream2_get_bytes_left(>gbc) < 8 + 4*(num_slices + 1))
> > +return AVERROR_INVALIDDATA;
> > +
> >  width  = bytestream2_get_be16(>gbc);
> >  height = bytestream2_get_be16(>gbc);
> >
> 
> LGTM

will apply

thx

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

Those who are best at talking, realize last or never when they are 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 3/3] swscale: Add test for isSemiPlanarYUV to pixdesc_query

[Michael Niedermayer]

On Sat, May 11, 2019 at 11:31:57AM -0700, Philip Langdale wrote:
> Lauri had asked me what the semi planar formats were and that reminded
> me that we could add it to pixdesc_query so we know exactly what the
> list is.
> 
> Signed-off-by: Philip Langdale 
> ---
>  libswscale/tests/pixdesc_query.c |  1 +
>  tests/ref/fate/sws-pixdesc-query | 13 +
>  2 files changed, 14 insertions(+)

LGTM

thx

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

"I am not trying to be anyone's saviour, I'm trying to think about the
 future and not be sad" - Elon Musk



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

[Reimar Döffinger]

On 12.05.2019, at 08:12, Peter Ross  wrote:
> +static int read_mb_value(GetBitContext *gb)
> +{
> +int v = 1;
> +int size;
> +
> +do {
> +size = 0;
> +if (!get_bits1(gb))
> +break;
> +v++;
> +do {
> +if (!get_bits1(gb))
> +break;
> +v += 1 << size++;
> +} while (size < 8);
> +} while (size == 8);
> +
> +if (size)
> +v += get_bits(gb, size);
> +
> +return v;
> +}

Maybe not worth it performance wise, but did you check if this could be 
simplified?
For example the get_bits1 cases that end up with size 0 could return directly.
Or it could peek ahead 9 bits in the bitstream and count the leading 1s to get 
v and size without looping (i.e. loop only for the 9 bits of 1s specifically).
Alternatively add a comment to clarify the encoding scheme it implements (like 
9 consecutive 1s is a prefix encoding an offset of 257 etc).
___
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: add apitch filter

[Paul B Mahol]

Signed-off-by: Paul B Mahol 
---

This filter can dynamically change both tempo and pitch of audio.
Also scale range is bigger, from 0.01 to 100.

Fixed silly out of phase bug for multichannel audio.

---
 libavfilter/Makefile |   1 +
 libavfilter/af_apitch.c  | 776 +++
 libavfilter/allfilters.c |   1 +
 3 files changed, 778 insertions(+)
 create mode 100644 libavfilter/af_apitch.c

diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index b41304d480..3662d50ae0 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -68,6 +68,7 @@ OBJS-$(CONFIG_ANULL_FILTER)  += af_anull.o
 OBJS-$(CONFIG_APAD_FILTER)   += af_apad.o
 OBJS-$(CONFIG_APERMS_FILTER) += f_perms.o
 OBJS-$(CONFIG_APHASER_FILTER)+= af_aphaser.o 
generate_wave_table.o
+OBJS-$(CONFIG_APITCH_FILTER) += af_apitch.o
 OBJS-$(CONFIG_APULSATOR_FILTER)  += af_apulsator.o
 OBJS-$(CONFIG_AREALTIME_FILTER)  += f_realtime.o
 OBJS-$(CONFIG_ARESAMPLE_FILTER)  += af_aresample.o
diff --git a/libavfilter/af_apitch.c b/libavfilter/af_apitch.c
new file mode 100644
index 00..b1ac3e0dba
--- /dev/null
+++ b/libavfilter/af_apitch.c
@@ -0,0 +1,776 @@
+/*
+ * Copyright (c) 2019 Paul B Mahol
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU Lesser General Public License as published
+ * by the Free Software Foundation; either version 2.1 of the License,
+ * or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include "libswresample/swresample.h"
+#include "libavutil/avassert.h"
+#include "libavutil/avstring.h"
+#include "libavutil/audio_fifo.h"
+#include "libavfilter/internal.h"
+#include "libavutil/common.h"
+#include "libavutil/opt.h"
+#include "libavcodec/avfft.h"
+#include "filters.h"
+#include "audio.h"
+
+typedef struct APitchContext {
+const AVClass *class;
+
+float pitch;
+float tempo;
+int window_size;
+int ratio;
+
+int fft_bits;
+int nb_channels;
+
+FFTContext *fft, *ifft;
+AVAudioFifo *ififo;
+int64_t pts;
+int eof;
+float *window_func_lut;
+
+AVFrame *buffer;
+AVFrame *magnitude;
+AVFrame *phase;
+AVFrame *acc;
+AVFrame *new_phase;
+AVFrame *last_phase;
+AVFrame *osamples;
+AVFrame *peaks;
+AVFrame *map;
+float *last_power;
+int   *power_change;
+
+intinput_overlap;
+intoutput_overlap;
+intsamples_to_drain;
+
+intflushed;
+intpitch_changed;
+struct SwrContext *swr;
+} APitchContext;
+
+#define OFFSET(x) offsetof(APitchContext, x)
+#define AF AV_OPT_FLAG_AUDIO_PARAM|AV_OPT_FLAG_FILTERING_PARAM
+
+static const AVOption apitch_options[] = {
+{ "pitch","set pitch scale factor", OFFSET(pitch),   
AV_OPT_TYPE_FLOAT, {.dbl=1},.01,   100, AF },
+{ "tempo","set tempo scale factor", OFFSET(tempo),   
AV_OPT_TYPE_FLOAT, {.dbl=1},.01,   100, AF },
+{ "oratio",   "set overlap ratio",  OFFSET(ratio),   
AV_OPT_TYPE_INT,   {.i64=4}, 1, 64, AF },
+{ NULL },
+};
+
+AVFILTER_DEFINE_CLASS(apitch);
+
+static int set_input_overlap(APitchContext *s, float rate)
+{
+s->input_overlap = s->output_overlap * rate;
+if (s->input_overlap <= 0)
+return AVERROR(EINVAL);
+return 0;
+}
+
+static int config_output(AVFilterLink *outlink)
+{
+AVFilterContext *ctx = outlink->src;
+AVFilterLink *inlink = ctx->inputs[0];
+APitchContext *s = ctx->priv;
+int ret;
+
+s->swr = swr_alloc();
+if (!s->swr)
+return AVERROR(ENOMEM);
+
+s->swr = swr_alloc_set_opts(s->swr,
+inlink->channel_layout, inlink->format, 
inlink->sample_rate,
+inlink->channel_layout, inlink->format, 
inlink->sample_rate * s->pitch,
+0, ctx);
+if (!s->swr)
+return AVERROR(ENOMEM);
+
+ret = swr_init(s->swr);
+if (ret < 0)
+return ret;
+
+s->window_size = inlink->sample_rate / 10;
+s->pts  = AV_NOPTS_VALUE;
+s->fft_bits = av_log2(s->window_size);
+s->fft  = av_fft_init(s->fft_bits, 0);
+s->ifft = av_fft_init(s->fft_bits, 1);
+if (!s->fft || !s->ifft)
+return AVERROR(ENOMEM);
+
+s->window_size = 1 << s->fft_bits;
+
+s->ratio = FFMIN(1 << av_log2(s->ratio), s->window_size >> 1);
+s->nb_channels = 

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

[Paul B Mahol]

On 5/12/19, Carl Eugen Hoyos  wrote:
> Am So., 12. Mai 2019 um 09:41 Uhr schrieb Paul B Mahol :
>
>> Also you need real review.
>
> He needs to request a review which I believe he did.

But full real review is still missing.
___
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/3] swscale: Add support for NV24 and NV42

[Michael Niedermayer]

On Sat, May 11, 2019 at 11:31:56AM -0700, Philip Langdale wrote:

> For the sake of completeness, I'm added NV24/NV42 support to swscale,
> but the specific use-case I noted when adding the pixel formats
> doesn't require swscale support (because it's OpenGL interop).

not sure this adds value to the commit message / would help
someone reading this commit in the future


> 
> The implementation is pretty straight-forward. Most of the existing
> NV12 codepaths work regardless of subsampling and are re-used as is.
> Where necessary I wrote the slightly different NV24 versions.
> 
> Finally, the one thing that confused me for a long time was the
> asm specific x86 path that did an explicit exclusion check for NV12.
> I replaced that with a semi-planar check and also updated the
> equivalent PPC code, which Lauri kindly checked.
> 
> Signed-off-by: Philip Langdale 
> ---
>  libswscale/input.c   |  2 +
>  libswscale/output.c  |  6 ++-
>  libswscale/ppc/swscale_altivec.c |  3 +-
>  libswscale/ppc/swscale_vsx.c |  3 +-
>  libswscale/swscale_unscaled.c| 51 
>  libswscale/utils.c   |  2 +
>  libswscale/version.h |  2 +-
>  libswscale/x86/swscale_template.c|  4 +-
>  tests/ref/fate/filter-pixfmts-copy   |  2 +
>  tests/ref/fate/filter-pixfmts-crop   |  2 +
>  tests/ref/fate/filter-pixfmts-field  |  2 +
>  tests/ref/fate/filter-pixfmts-fieldorder |  2 +
>  tests/ref/fate/filter-pixfmts-hflip  |  2 +
>  tests/ref/fate/filter-pixfmts-il |  2 +
>  tests/ref/fate/filter-pixfmts-null   |  2 +
>  tests/ref/fate/filter-pixfmts-pad|  2 +
>  tests/ref/fate/filter-pixfmts-scale  |  2 +
>  tests/ref/fate/filter-pixfmts-transpose  |  2 +
>  tests/ref/fate/filter-pixfmts-vflip  |  2 +
>  tests/ref/fate/sws-pixdesc-query |  6 +++
>  20 files changed, 92 insertions(+), 9 deletions(-)
> 
> diff --git a/libswscale/input.c b/libswscale/input.c
> index c2dc356b5d..064f8da314 100644
> --- a/libswscale/input.c
> +++ b/libswscale/input.c
> @@ -1020,9 +1020,11 @@ av_cold void ff_sws_init_input_funcs(SwsContext *c)
>  c->chrToYV12 = uyvyToUV_c;
>  break;
>  case AV_PIX_FMT_NV12:
> +case AV_PIX_FMT_NV24:
>  c->chrToYV12 = nv12ToUV_c;
>  break;
>  case AV_PIX_FMT_NV21:
> +case AV_PIX_FMT_NV42:
>  c->chrToYV12 = nv21ToUV_c;
>  break;
>  case AV_PIX_FMT_RGB8:
> diff --git a/libswscale/output.c b/libswscale/output.c
> index d3401f0cd1..26b0ff3d48 100644
> --- a/libswscale/output.c
> +++ b/libswscale/output.c
> @@ -410,7 +410,8 @@ static void yuv2nv12cX_c(SwsContext *c, const int16_t 
> *chrFilter, int chrFilterS
>  const uint8_t *chrDither = c->chrDither8;
>  int i;
>  
> -if (dstFormat == AV_PIX_FMT_NV12)
> +if (dstFormat == AV_PIX_FMT_NV12 ||
> +dstFormat == AV_PIX_FMT_NV24)
>  for (i=0; i  int u = chrDither[i & 7] << 12;
>  int v = chrDither[(i + 3) & 7] << 12;
> @@ -2496,7 +2497,8 @@ av_cold void ff_sws_init_output_funcs(SwsContext *c,
>  } else {
>  *yuv2plane1 = yuv2plane1_8_c;
>  *yuv2planeX = yuv2planeX_8_c;
> -if (dstFormat == AV_PIX_FMT_NV12 || dstFormat == AV_PIX_FMT_NV21)
> +if (dstFormat == AV_PIX_FMT_NV12 || dstFormat == AV_PIX_FMT_NV21 ||
> +dstFormat == AV_PIX_FMT_NV24 || dstFormat == AV_PIX_FMT_NV42)
>  *yuv2nv12cX = yuv2nv12cX_c;
>  }
>  
> diff --git a/libswscale/ppc/swscale_altivec.c 
> b/libswscale/ppc/swscale_altivec.c
> index 3cd9782da4..6b8cc2c194 100644
> --- a/libswscale/ppc/swscale_altivec.c
> +++ b/libswscale/ppc/swscale_altivec.c
> @@ -247,8 +247,7 @@ av_cold void ff_sws_init_swscale_ppc(SwsContext *c)
>  if (c->srcBpc == 8 && c->dstBpc <= 14) {
>  c->hyScale = c->hcScale = hScale_real_altivec;
>  }
> -if (!is16BPS(dstFormat) && !isNBPS(dstFormat) &&
> -dstFormat != AV_PIX_FMT_NV12 && dstFormat != AV_PIX_FMT_NV21 &&
> +if (!is16BPS(dstFormat) && !isNBPS(dstFormat) && 
> !isSemiPlanarYUV(dstFormat) &&
>  dstFormat != AV_PIX_FMT_GRAYF32BE && dstFormat != 
> AV_PIX_FMT_GRAYF32LE &&
>  !c->needAlpha) {
>  c->yuv2planeX = yuv2planeX_altivec;
> diff --git a/libswscale/ppc/swscale_vsx.c b/libswscale/ppc/swscale_vsx.c
> index a617f76741..75dee5ea58 100644
> --- a/libswscale/ppc/swscale_vsx.c
> +++ b/libswscale/ppc/swscale_vsx.c
> @@ -2096,8 +2096,7 @@ av_cold void ff_sws_init_swscale_vsx(SwsContext *c)
>   : hScale16To15_vsx;
>  }
>  }
> -if (!is16BPS(dstFormat) && !isNBPS(dstFormat) &&
> -dstFormat != AV_PIX_FMT_NV12 && dstFormat != AV_PIX_FMT_NV21 &&
> +if (!is16BPS(dstFormat) && !isNBPS(dstFormat) && 
> !isSemiPlanarYUV(dstFormat) &&
>  dstFormat != AV_PIX_FMT_GRAYF32BE && dstFormat != 
> 

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

[Carl Eugen Hoyos]

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

No new patch needed, 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 1/2] VP4 video decoder

[Carl Eugen Hoyos]

Am So., 12. Mai 2019 um 09:41 Uhr schrieb Paul B Mahol :

> Also you need real review.

He needs to request a review which I believe he did.

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 1/3] avutil: Add NV24 and NV42 pixel formats

[Carl Eugen Hoyos]

Am So., 12. Mai 2019 um 05:38 Uhr schrieb Fu, Linjie :

> I'm working on adding support for HEVC 4:2:2/ 4:4:4, 8/10 bit, in vaapi 
> decoding.
> And I'm aslo thinking of add some new pix_fmt for packed FourCC:
> 444 8 bit :  AYUV
> 444 10 bit: Y410
> 422 10 bit: Y210

Do I understand correctly that for 420 8 bit, vaapi produces the
decoded image in a planar format but for 444 8 bit (and 10 bit),
you decided that a packed format makes more sense?
(Aren't luma and chroma stored independently in hevc?)

Note that no matter what you do with the decoded image, there
will be a (measurable) performance hit because of the needed
transformation into something (planar) that other filters and
encoders understand.

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] avcodec/hq_hqa: Check available space before reading slice offsets

[Paul B Mahol]

On 5/12/19, Michael Niedermayer  wrote:
> Fixes: Timeout (43sec -> 18sec)
> Fixes:
> 14556/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_HQ_HQA_fuzzer-5673543024508928
>
> Found-by: continuous fuzzing process
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by: Michael Niedermayer 
> ---
>  libavcodec/hq_hqa.c | 3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/libavcodec/hq_hqa.c b/libavcodec/hq_hqa.c
> index ec9da3e04f..90bafdc72a 100644
> --- a/libavcodec/hq_hqa.c
> +++ b/libavcodec/hq_hqa.c
> @@ -248,6 +248,9 @@ static int hqa_decode_frame(HQContext *ctx, AVFrame
> *pic, size_t data_size)
>  int width, height, quant;
>  const uint8_t *src = ctx->gbc.buffer;
>
> +if (bytestream2_get_bytes_left(>gbc) < 8 + 4*(num_slices + 1))
> +return AVERROR_INVALIDDATA;
> +
>  width  = bytestream2_get_be16(>gbc);
>  height = bytestream2_get_be16(>gbc);
>

LGTM

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

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

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

[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(-)
 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
 
 
 version 4.1:
diff --git a/doc/general.texi b/doc/general.texi
index d2324612c2..146ab18dc8 100644
--- a/doc/general.texi
+++ b/doc/general.texi
@@ -937,6 +937,8 @@ following image formats are supported:
 @tab Video encoding used in NuppelVideo files.
 @item On2 VP3@tab @tab  X
 @tab still experimental
+@item On2 VP4@tab @tab  X
+@tab fourcc: VP40
 @item On2 VP5@tab @tab  X
 @tab fourcc: VP50
 @item On2 VP6@tab @tab  X
diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
index 6178d31b5c..d2f9a39ce5 100644
--- a/libavcodec/allcodecs.c
+++ b/libavcodec/allcodecs.c
@@ -330,6 +330,7 @@ extern AVCodec ff_vcr1_decoder;
 extern AVCodec ff_vmdvideo_decoder;
 extern AVCodec ff_vmnc_decoder;
 extern AVCodec ff_vp3_decoder;
+extern AVCodec ff_vp4_decoder;
 extern AVCodec ff_vp5_decoder;
 extern AVCodec ff_vp6_decoder;
 extern AVCodec ff_vp6a_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,
 
 AV_CODEC_ID_Y41P = 0x8000,
 AV_CODEC_ID_AVRP,
diff --git a/libavcodec/codec_desc.c b/libavcodec/codec_desc.c
index 621b16e160..e047981211 100644
--- a/libavcodec/codec_desc.c
+++ b/libavcodec/codec_desc.c
@@ -1403,6 +1403,13 @@ static const AVCodecDescriptor codec_descriptors[] = {
 .long_name = NULL_IF_CONFIG_SMALL("AVS2-P2/IEEE1857.4"),
 .props = AV_CODEC_PROP_LOSSY,
 },
+{
+.id= AV_CODEC_ID_VP4,
+.type  = AVMEDIA_TYPE_VIDEO,
+.name  = "vp4",
+.long_name = NULL_IF_CONFIG_SMALL("On2 VP4"),
+.props = AV_CODEC_PROP_LOSSY,
+},
 {
 .id= AV_CODEC_ID_Y41P,
 .type  = AVMEDIA_TYPE_VIDEO,
diff --git a/libavcodec/vp3.c b/libavcodec/vp3.c
index b248c90413..9084ff33e3 100644
--- a/libavcodec/vp3.c
+++ b/libavcodec/vp3.c
@@ -1,5 +1,6 @@
 /*
  * Copyright (C) 2003-2004 The FFmpeg project
+ * Copyright (C) 2019 Peter Ross
  *
  * This file is part of FFmpeg.
  *
@@ -20,7 +21,7 @@
 
 /**
  * @file
- * On2 VP3 Video Decoder
+ * On2 VP3/VP4 Video Decoder
  *
  * VP3 Video Decoder by Mike Melanson (mike at multimedia.cx)
  * For more information about the VP3 coding process, visit:
@@ -43,6 +44,7 @@
 #include "thread.h"
 #include "videodsp.h"
 #include "vp3data.h"
+#include "vp4data.h"
 #include "vp3dsp.h"
 #include "xiph.h"
 
@@ -127,6 +129,30 @@ static const uint8_t hilbert_offset[16][2] = {
 { 3, 1 }, { 2, 1 }, { 2, 0 }, { 3, 0 }
 };
 
+enum {
+VP4_DC_INTRA  = 0,
+VP4_DC_INTER  = 1,
+VP4_DC_GOLDEN = 2,
+NB_VP4_DC_TYPES,
+VP4_DC_UNDEFINED = NB_VP4_DC_TYPES
+};
+
+static const uint8_t vp4_pred_block_type_map[8] = {
+[MODE_INTER_NO_MV]  = VP4_DC_INTER,
+[MODE_INTRA]= VP4_DC_INTRA,
+[MODE_INTER_PLUS_MV]= VP4_DC_INTER,
+[MODE_INTER_LAST_MV]= VP4_DC_INTER,
+[MODE_INTER_PRIOR_LAST] = VP4_DC_INTER,
+[MODE_USING_GOLDEN] = VP4_DC_GOLDEN,
+[MODE_GOLDEN_MV]= VP4_DC_GOLDEN,
+[MODE_INTER_FOURMV] = VP4_DC_INTER,
+};
+
+typedef struct {
+int dc;
+int type;
+} VP4Predictor;
+
 #define MIN_DEQUANT_VAL 2
 
 typedef struct Vp3DecodeContext {
@@ -164,9 +190,13 @@ typedef struct Vp3DecodeContext {
 int v_superblock_start;
 unsigned char *superblock_coding;
 
-int macroblock_count;
+int macroblock_count; /* y macroblock count */
 int macroblock_width;
 int macroblock_height;
+int c_macroblock_count;
+int c_macroblock_width;
+int c_macroblock_height;
+int yuv_macroblock_count; /* y+u+v macroblock count */
 
 int fragment_count;
 int fragment_width[2];
@@ -182,7 +212,7 @@ typedef struct Vp3DecodeContext {
 int8_t (*motion_val[2])[2];
 
 /* tables */
-uint16_t coded_dc_scale_factor[64];
+uint16_t coded_dc_scale_factor[2][64];
 uint32_t coded_ac_scale_factor[64];
 uint8_t base_matrix[384][64];
 uint8_t qr_count[2][3];
@@ -233,10 +263,12 @@ typedef 

[FFmpeg-devel] [PATCH 2/2] avformat/riff: add VP4 fourcc

[Peter Ross]

---
 libavformat/riff.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/libavformat/riff.c b/libavformat/riff.c
index 0f5cd62547..56387916f2 100644
--- a/libavformat/riff.c
+++ b/libavformat/riff.c
@@ -307,6 +307,7 @@ const AVCodecTag ff_codec_bmp_tags[] = {
 { AV_CODEC_ID_INDEO5,   MKTAG('I', 'V', '5', '0') },
 { AV_CODEC_ID_VP3,  MKTAG('V', 'P', '3', '1') },
 { AV_CODEC_ID_VP3,  MKTAG('V', 'P', '3', '0') },
+{ AV_CODEC_ID_VP4,  MKTAG('V', 'P', '4', '0') },
 { AV_CODEC_ID_VP5,  MKTAG('V', 'P', '5', '0') },
 { AV_CODEC_ID_VP6,  MKTAG('V', 'P', '6', '0') },
 { AV_CODEC_ID_VP6,  MKTAG('V', 'P', '6', '1') },
-- 
2.20.1

-- 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] lavf/dashdec: fix the coding logic after open_input fail

[Steven Liu]

> 在 2019年5月11日，15:23，Jun Zhao  写道：
> 
> From: Jun Zhao 
> 
> setting return status following goto will never be executed, so
> adjust the location in the code.
> 
> Signed-off-by: Jun Zhao 
> ---
> libavformat/dashdec.c |2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/libavformat/dashdec.c b/libavformat/dashdec.c
> index 6e3e7e4..ce8bd4a 100644
> --- a/libavformat/dashdec.c
> +++ b/libavformat/dashdec.c
> @@ -1793,8 +1793,8 @@ restart:
> ret = open_input(c, v, v->cur_seg);
> if (ret < 0) {
> if (ff_check_interrupt(c->interrupt_callback)) {
> -goto end;
> ret = AVERROR_EXIT;
> +goto end;
> }
> av_log(v->parent, AV_LOG_WARNING, "Failed to open fragment of 
> playlist %d\n", v->rep_idx);
> v->cur_seq_no++;
> -- 
> 1.7.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”.


Pushed

Thanks
Steven





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