Re: [FFmpeg-devel] [PATCH] avformat/matroskadec: use a linked list to queue packets

[wm4]

On Wed, 21 Feb 2018 00:08:45 -0300
James Almer  wrote:

> It's more robust and efficient.
> 
> Signed-off-by: James Almer 
> ---
>  libavformat/matroskadec.c | 90 
> +++
>  1 file changed, 52 insertions(+), 38 deletions(-)
> 
> diff --git a/libavformat/matroskadec.c b/libavformat/matroskadec.c
> index 2faaf9dfb8..241ee5fed1 100644
> --- a/libavformat/matroskadec.c
> +++ b/libavformat/matroskadec.c
> @@ -338,9 +338,8 @@ typedef struct MatroskaDemuxContext {
>  int64_t segment_start;
>  
>  /* the packet queue */
> -AVPacket **packets;
> -int num_packets;
> -AVPacket *prev_pkt;
> +AVPacketList *queue;
> +AVPacketList *queue_end;
>  
>  int done;
>  
> @@ -2722,11 +2721,14 @@ fail:
>  static int matroska_deliver_packet(MatroskaDemuxContext *matroska,
> AVPacket *pkt)
>  {
> -if (matroska->num_packets > 0) {
> +if (matroska->queue) {
>  MatroskaTrack *tracks = matroska->tracks.elem;
>  MatroskaTrack *track;
> -memcpy(pkt, matroska->packets[0], sizeof(AVPacket));
> -av_freep(>packets[0]);
> +AVPacketList *pktl = matroska->queue;
> +
> +av_packet_move_ref(pkt, >pkt);
> +matroska->queue = pktl->next;
> +av_free(pktl);
>  track = [pkt->stream_index];
>  if (track->has_palette) {
>  uint8_t *pal = av_packet_new_side_data(pkt, AV_PKT_DATA_PALETTE, 
> AVPALETTE_SIZE);
> @@ -2737,41 +2739,45 @@ static int 
> matroska_deliver_packet(MatroskaDemuxContext *matroska,
>  }
>  track->has_palette = 0;
>  }
> -if (matroska->num_packets > 1) {
> -void *newpackets;
> -memmove(>packets[0], >packets[1],
> -(matroska->num_packets - 1) * sizeof(AVPacket *));
> -newpackets = av_realloc(matroska->packets,
> -(matroska->num_packets - 1) *
> -sizeof(AVPacket *));
> -if (newpackets)
> -matroska->packets = newpackets;
> -} else {
> -av_freep(>packets);
> -matroska->prev_pkt = NULL;
> -}
> -matroska->num_packets--;
> +if (!matroska->queue)
> +matroska->queue_end = NULL;
>  return 0;
>  }
>  
>  return -1;
>  }
>  
> +static int matroska_queue_packet(MatroskaDemuxContext *matroska, AVPacket 
> *pkt)
> +{
> +AVPacketList *pktl = av_malloc(sizeof(*pktl));
> +
> +if (!pktl)
> +return AVERROR(ENOMEM);
> +av_packet_move_ref(>pkt, pkt);
> +pktl->next = NULL;
> +
> +if (matroska->queue_end)
> +matroska->queue_end->next = pktl;
> +else
> +matroska->queue = pktl;
> +matroska->queue_end = pktl;
> +
> +return 0;
> +}
> +
>  /*
>   * Free all packets in our internal queue.
>   */
>  static void matroska_clear_queue(MatroskaDemuxContext *matroska)
>  {
> -matroska->prev_pkt = NULL;
> -if (matroska->packets) {
> -int n;
> -for (n = 0; n < matroska->num_packets; n++) {
> -av_packet_unref(matroska->packets[n]);
> -av_freep(>packets[n]);
> -}
> -av_freep(>packets);
> -matroska->num_packets = 0;
> +AVPacketList *pktl;
> +
> +while (pktl = matroska->queue) {
> +av_packet_unref(>pkt);
> +matroska->queue = pktl->next;
> +av_free(pktl);
>  }
> +matroska->queue_end = NULL;
>  }
>  
>  static int matroska_parse_laces(MatroskaDemuxContext *matroska, uint8_t 
> **buf,
> @@ -2953,7 +2959,11 @@ static int 
> matroska_parse_rm_audio(MatroskaDemuxContext *matroska,
>  track->audio.buf_timecode = AV_NOPTS_VALUE;
>  pkt->pos  = pos;
>  pkt->stream_index = st->index;
> -dynarray_add(>packets, >num_packets, pkt);
> +ret = matroska_queue_packet(matroska, pkt);
> +if (ret < 0) {
> +av_packet_free();
> +return AVERROR(ENOMEM);
> +}
>  }
>  
>  return 0;
> @@ -3152,8 +3162,11 @@ static int matroska_parse_webvtt(MatroskaDemuxContext 
> *matroska,
>  pkt->duration = duration;
>  pkt->pos = pos;
>  
> -dynarray_add(>packets, >num_packets, pkt);
> -matroska->prev_pkt = pkt;
> +err = matroska_queue_packet(matroska, pkt);
> +if (err < 0) {
> +av_packet_free();
> +return AVERROR(ENOMEM);
> +}
>  
>  return 0;
>  }
> @@ -3268,8 +3281,11 @@ FF_DISABLE_DEPRECATION_WARNINGS
>  FF_ENABLE_DEPRECATION_WARNINGS
>  #endif
>  
> -dynarray_add(>packets, >num_packets, pkt);
> -matroska->prev_pkt = pkt;
> +res = matroska_queue_packet(matroska, pkt);
> +if (res < 0) {
> +av_packet_free();
> +return AVERROR(ENOMEM);
> +}
>  
>  return 0;
>  
> @@ -3433,7 +3449,6 @@ static int 
> 

Re: [FFmpeg-devel] [PATCH 2/2] avformat/mpegenc - reject unsupported audio streams

[Gyan Doshi]

On 2/21/2018 3:03 AM, Carl Eugen Hoyos wrote:

2018-02-20 16:17 GMT+01:00 Gyan Doshi :

Please also mention LPCM.


Only 16-bit LPCM BE can be muxed, which is mentioned.

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

Re: [FFmpeg-devel] [PATCH 2/2] Implement dynamic loading of NewTek NDI library

[Maksym Veremeyenko]

21.02.2018 0:39, Carl Eugen Hoyos пише:

2018-02-20 23:35 GMT+01:00 Marton Balint :


On Tue, 20 Feb 2018, Carl Eugen Hoyos wrote:


2018-02-20 17:32 GMT+01:00 Maksym Veremeyenko :


attached patch implement dynamic loading of NewTek library and
drop dependencies from NewTek SDK (if previous patch with
including headers applied)


This patch is not ok assuming the runtime library is not open
source and has a license compatible with the GPL.


The patch might has merits even if the library remains in the
NONFREE section, no?


It might, I do not immediately see them, though.


patch without altering *EXTERNAL_LIBRARY_NONFREE_LIST* has any chance to 
be reviewed?


--
Maksym Veremeyenko

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

Re: [FFmpeg-devel] [aacdec] Parse and drop gain control data, so that SSR packets decode.

[Alex Converse]

On Tue, Feb 20, 2018 at 4:56 PM, Dale Curtis  wrote:
> On Tue, Feb 20, 2018 at 4:18 PM, Alex Converse 
> wrote:
>
>>
>> I would make this uint8_t
>>
>
> Done.
>
>
>> I would drop this stack struck and replace the leaf get_bits() with
>> skip bits. It makes the code that much harder to exploit and there is
>> no point in storing data we don't plan on decoding
>>
>
> Done.
>
>
>> This block seems funny. decode_gain_control() always returns zero.
>> Maybe make this warn once per stream when present like some of the
>> other AAC warn
>> cases.
>>
>
> Done. I've added an AACContext::warn_gain_control member to do this.
>
> This patch set also changes the attribution from Robert Swain to Maxim
> Gavrilov based on svn blame of the SoC repository after discussion at
> https://trac.ffmpeg.org/ticket/1693#comment:34
>

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

[FFmpeg-devel] [PATCH 2/2] avcodec/cavsdec: Check alpha/beta offset

[Michael Niedermayer]

Fixes: Integer overflow
Fixes: 6183/clusterfuzz-testcase-minimized-6269224436629504

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

diff --git a/libavcodec/cavsdec.c b/libavcodec/cavsdec.c
index 06c752735e..c7fff67c06 100644
--- a/libavcodec/cavsdec.c
+++ b/libavcodec/cavsdec.c
@@ -1067,6 +1067,11 @@ static int decode_pic(AVSContext *h)
 if (!h->loop_filter_disable && get_bits1(>gb)) {
 h->alpha_offset= get_se_golomb(>gb);
 h->beta_offset = get_se_golomb(>gb);
+if (   h->alpha_offset < -64 || h->alpha_offset > 64
+|| h-> beta_offset < -64 || h-> beta_offset > 64) {
+h->alpha_offset = h->beta_offset  = 0;
+return AVERROR_INVALIDDATA;
+}
 } else {
 h->alpha_offset = h->beta_offset  = 0;
 }
-- 
2.16.1

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

[FFmpeg-devel] [PATCH 1/2] avcodec/exr: fix invalid shift in unpack_14()

[Michael Niedermayer]

Fixes: 6154/clusterfuzz-testcase-minimized-5762231061970944
Fixes: runtime error: shift exponent 63 is too large for 32-bit type 'int'

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

diff --git a/libavcodec/exr.c b/libavcodec/exr.c
index 47f59bd638..ff31d7267c 100644
--- a/libavcodec/exr.c
+++ b/libavcodec/exr.c
@@ -899,7 +899,7 @@ static int pxr24_uncompress(EXRContext *s, const uint8_t 
*src,
 
 static void unpack_14(const uint8_t b[14], uint16_t s[16])
 {
-unsigned short shift = (b[ 2] >> 2);
+unsigned short shift = (b[ 2] >> 2) & 15;
 unsigned short bias = (0x20 << shift);
 int i;
 
-- 
2.16.1

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

[FFmpeg-devel] [PATCH] avformat/matroskadec: use a linked list to queue packets

[James Almer]

It's more robust and efficient.

Signed-off-by: James Almer 
---
 libavformat/matroskadec.c | 90 +++
 1 file changed, 52 insertions(+), 38 deletions(-)

diff --git a/libavformat/matroskadec.c b/libavformat/matroskadec.c
index 2faaf9dfb8..241ee5fed1 100644
--- a/libavformat/matroskadec.c
+++ b/libavformat/matroskadec.c
@@ -338,9 +338,8 @@ typedef struct MatroskaDemuxContext {
 int64_t segment_start;
 
 /* the packet queue */
-AVPacket **packets;
-int num_packets;
-AVPacket *prev_pkt;
+AVPacketList *queue;
+AVPacketList *queue_end;
 
 int done;
 
@@ -2722,11 +2721,14 @@ fail:
 static int matroska_deliver_packet(MatroskaDemuxContext *matroska,
AVPacket *pkt)
 {
-if (matroska->num_packets > 0) {
+if (matroska->queue) {
 MatroskaTrack *tracks = matroska->tracks.elem;
 MatroskaTrack *track;
-memcpy(pkt, matroska->packets[0], sizeof(AVPacket));
-av_freep(>packets[0]);
+AVPacketList *pktl = matroska->queue;
+
+av_packet_move_ref(pkt, >pkt);
+matroska->queue = pktl->next;
+av_free(pktl);
 track = [pkt->stream_index];
 if (track->has_palette) {
 uint8_t *pal = av_packet_new_side_data(pkt, AV_PKT_DATA_PALETTE, 
AVPALETTE_SIZE);
@@ -2737,41 +2739,45 @@ static int matroska_deliver_packet(MatroskaDemuxContext 
*matroska,
 }
 track->has_palette = 0;
 }
-if (matroska->num_packets > 1) {
-void *newpackets;
-memmove(>packets[0], >packets[1],
-(matroska->num_packets - 1) * sizeof(AVPacket *));
-newpackets = av_realloc(matroska->packets,
-(matroska->num_packets - 1) *
-sizeof(AVPacket *));
-if (newpackets)
-matroska->packets = newpackets;
-} else {
-av_freep(>packets);
-matroska->prev_pkt = NULL;
-}
-matroska->num_packets--;
+if (!matroska->queue)
+matroska->queue_end = NULL;
 return 0;
 }
 
 return -1;
 }
 
+static int matroska_queue_packet(MatroskaDemuxContext *matroska, AVPacket *pkt)
+{
+AVPacketList *pktl = av_malloc(sizeof(*pktl));
+
+if (!pktl)
+return AVERROR(ENOMEM);
+av_packet_move_ref(>pkt, pkt);
+pktl->next = NULL;
+
+if (matroska->queue_end)
+matroska->queue_end->next = pktl;
+else
+matroska->queue = pktl;
+matroska->queue_end = pktl;
+
+return 0;
+}
+
 /*
  * Free all packets in our internal queue.
  */
 static void matroska_clear_queue(MatroskaDemuxContext *matroska)
 {
-matroska->prev_pkt = NULL;
-if (matroska->packets) {
-int n;
-for (n = 0; n < matroska->num_packets; n++) {
-av_packet_unref(matroska->packets[n]);
-av_freep(>packets[n]);
-}
-av_freep(>packets);
-matroska->num_packets = 0;
+AVPacketList *pktl;
+
+while (pktl = matroska->queue) {
+av_packet_unref(>pkt);
+matroska->queue = pktl->next;
+av_free(pktl);
 }
+matroska->queue_end = NULL;
 }
 
 static int matroska_parse_laces(MatroskaDemuxContext *matroska, uint8_t **buf,
@@ -2953,7 +2959,11 @@ static int matroska_parse_rm_audio(MatroskaDemuxContext 
*matroska,
 track->audio.buf_timecode = AV_NOPTS_VALUE;
 pkt->pos  = pos;
 pkt->stream_index = st->index;
-dynarray_add(>packets, >num_packets, pkt);
+ret = matroska_queue_packet(matroska, pkt);
+if (ret < 0) {
+av_packet_free();
+return AVERROR(ENOMEM);
+}
 }
 
 return 0;
@@ -3152,8 +3162,11 @@ static int matroska_parse_webvtt(MatroskaDemuxContext 
*matroska,
 pkt->duration = duration;
 pkt->pos = pos;
 
-dynarray_add(>packets, >num_packets, pkt);
-matroska->prev_pkt = pkt;
+err = matroska_queue_packet(matroska, pkt);
+if (err < 0) {
+av_packet_free();
+return AVERROR(ENOMEM);
+}
 
 return 0;
 }
@@ -3268,8 +3281,11 @@ FF_DISABLE_DEPRECATION_WARNINGS
 FF_ENABLE_DEPRECATION_WARNINGS
 #endif
 
-dynarray_add(>packets, >num_packets, pkt);
-matroska->prev_pkt = pkt;
+res = matroska_queue_packet(matroska, pkt);
+if (res < 0) {
+av_packet_free();
+return AVERROR(ENOMEM);
+}
 
 return 0;
 
@@ -3433,7 +3449,6 @@ static int 
matroska_parse_cluster_incremental(MatroskaDemuxContext *matroska)
 memset(>current_cluster, 0, sizeof(MatroskaCluster));
 matroska->current_cluster_num_blocks = 0;
 matroska->current_cluster_pos= avio_tell(matroska->ctx->pb);
-matroska->prev_pkt   = NULL;
 /* sizeof the ID which was already read */
 if (matroska->current_id)
 

Re: [FFmpeg-devel] [aacdec] Parse and drop gain control data, so that SSR packets decode.

[Dale Curtis]

On Tue, Feb 20, 2018 at 4:18 PM, Alex Converse 
wrote:

>
> I would make this uint8_t
>

Done.


> I would drop this stack struck and replace the leaf get_bits() with
> skip bits. It makes the code that much harder to exploit and there is
> no point in storing data we don't plan on decoding
>

Done.


> This block seems funny. decode_gain_control() always returns zero.
> Maybe make this warn once per stream when present like some of the
> other AAC warn
> cases.
>

Done. I've added an AACContext::warn_gain_control member to do this.

This patch set also changes the attribution from Robert Swain to Maxim
Gavrilov based on svn blame of the SoC repository after discussion at
https://trac.ffmpeg.org/ticket/1693#comment:34
From 8e5a3cc04400a1186df0714524ccb24dbe3f627d Mon Sep 17 00:00:00 2001
From: Dale Curtis 
Date: Thu, 15 Feb 2018 16:22:55 -0800
Subject: [PATCH] [aacdec] Parse and drop gain control data, so that SSR
 packets decode.

This will result in poor quality audio for SSR streams, but they
will at least demux and decode without error; partially fixing
ticket #1693.

This pulls in the decode_gain_control() function from the
ffmpeg summer-of-code repo (original author Maxim Gavrilov) at
svn://svn.mplayerhq.hu/soc/aac/aac.c with some minor modifications
and adds AOT_AAC_SSR to decode_audio_specific_config_gb().

Signed-off-by: Dale Curtis 
Co-authored-by: Maxim Gavrilov 
---
 libavcodec/aac.h |  2 ++
 libavcodec/aacdec_template.c | 36 +---
 2 files changed, 35 insertions(+), 3 deletions(-)

diff --git a/libavcodec/aac.h b/libavcodec/aac.h
index 4910c661d6..05bc95385f 100644
--- a/libavcodec/aac.h
+++ b/libavcodec/aac.h
@@ -357,6 +357,8 @@ struct AACContext {
 int warned_num_aac_frames;
 int warned_960_sbr;
 
+int warned_gain_control;
+
 /* aacdec functions pointers */
 void (*imdct_and_windowing)(AACContext *ac, SingleChannelElement *sce);
 void (*apply_ltp)(AACContext *ac, SingleChannelElement *sce);
diff --git a/libavcodec/aacdec_template.c b/libavcodec/aacdec_template.c
index c2d9802023..cf97181092 100644
--- a/libavcodec/aacdec_template.c
+++ b/libavcodec/aacdec_template.c
@@ -997,6 +997,7 @@ static int decode_audio_specific_config_gb(AACContext *ac,
 switch (m4ac->object_type) {
 case AOT_AAC_MAIN:
 case AOT_AAC_LC:
+case AOT_AAC_SSR:
 case AOT_AAC_LTP:
 case AOT_ER_AAC_LC:
 case AOT_ER_AAC_LD:
@@ -1967,6 +1968,33 @@ static void apply_prediction(AACContext *ac, SingleChannelElement *sce)
 reset_all_predictors(sce->predictor_state);
 }
 
+static void decode_gain_control(SingleChannelElement * sce, GetBitContext * gb)
+{
+// wd_num, wd_test, aloc_size
+static const uint8_t gain_mode[4][3] = {
+{1, 0, 5},  // ONLY_LONG_SEQUENCE = 0,
+{2, 1, 2},  // LONG_START_SEQUENCE,
+{8, 0, 2},  // EIGHT_SHORT_SEQUENCE,
+{2, 1, 5},  // LONG_STOP_SEQUENCE
+};
+
+const int mode = sce->ics.window_sequence[0];
+uint8_t bd, wd, ad;
+
+// FIXME: Store the gain control data on |sce| and do something with it.
+uint8_t max_band = get_bits(gb, 2);
+for (bd = 0; bd < max_band; bd++) {
+for (wd = 0; wd < gain_mode[mode][0]; wd++) {
+uint8_t adjust_num = get_bits(gb, 3);
+for (ad = 0; ad < adjust_num; ad++) {
+skip_bits(gb, 4 + ((wd == 0 && gain_mode[mode][1])
+ ? 4
+ : gain_mode[mode][2]));
+}
+}
+}
+}
+
 /**
  * Decode an individual_channel_stream payload; reference: table 4.44.
  *
@@ -2034,9 +2062,11 @@ static int decode_ics(AACContext *ac, SingleChannelElement *sce,
 goto fail;
 }
 if (!eld_syntax && get_bits1(gb)) {
-avpriv_request_sample(ac->avctx, "SSR");
-ret = AVERROR_PATCHWELCOME;
-goto fail;
+decode_gain_control(sce, gb);
+if (!ac->warned_gain_control) {
+avpriv_report_missing_feature(ac->avctx, "Gain control");
+ac->warned_gain_control = 1;
+}
 }
 // I see no textual basis in the spec for this occurring after SSR gain
 // control, but this is what both reference and real implmentations do
-- 
2.16.1.291.g4437f3f132-goog

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

[FFmpeg-devel] [PATCH] Added support for version field flag 0x04 in OpenEXR files

[Daniel Flehner Heen]

Hi!

First time poster so please excuse any mistakes made. I've tried submitting
a patch through git send-email but got issues authentication through gmail.
Attached is a patch file created with git format-patch.

Commit message:

Added support for version field flag 0x04 in OpenEXR files regarding long
names in attributes.
Should have no impact on decoding of images.

Also added a bit more verbose logging of OpenEXR 2.x flags not yet
supported.

-- 
-Daniel
From 0a8c7b74ef6ad39c7ce4a2eaa8327dd4a1f9d851 Mon Sep 17 00:00:00 2001
From: Daniel Flehner Heen 
Date: Tue, 20 Feb 2018 23:36:29 +0100
Subject: [PATCH] Added support for version field flag 0x04 in OpenEXR files

Added support for version field flag 0x04 in OpenEXR files regarding long names in attributes.
Should have no impact on decoding of images.

Also added a bit more verbose logging of OpenEXR 2.x flags not yet supported.
---
 libavcodec/exr.c | 10 +-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/libavcodec/exr.c b/libavcodec/exr.c
index 47f59bd..238ee4a 100644
--- a/libavcodec/exr.c
+++ b/libavcodec/exr.c
@@ -1354,7 +1354,15 @@ static int decode_header(EXRContext *s, AVFrame *frame)
 s->is_tile = 0;
 else if (flags & 0x02)
 s->is_tile = 1;
-else{
+else if (flags & 0x04)
+av_log(s->avctx, AV_LOG_DEBUG, "Long attribute names flag detected %d.\n", flags);
+else if (flags & 0x08) {
+avpriv_report_missing_feature(s->avctx, "OpenEXR 2.x deep format flag %d", flags);
+return AVERROR_PATCHWELCOME;
+} else if (flags & 0x10) {
+avpriv_report_missing_feature(s->avctx, "OpenEXR 2.x multipart flag %d", flags);
+return AVERROR_PATCHWELCOME;
+} else {
 avpriv_report_missing_feature(s->avctx, "flags %d", flags);
 return AVERROR_PATCHWELCOME;
 }
-- 
2.7.4

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

Re: [FFmpeg-devel] [aacdec] Parse and drop gain control data, so that SSR packets decode.

[Alex Converse]

On Tue, Feb 20, 2018 at 3:37 PM, Dale Curtis  wrote:
> From 97380752ef12337d9b9a01801a9a84df3b4b9c0a Mon Sep 17 00:00:00 2001
> From: Dale Curtis 
> Date: Thu, 15 Feb 2018 16:22:55 -0800
> Subject: [PATCH] [aacdec] Parse and drop gain control data, so that SSR
>  packets decode.
>
> This will result in poor quality audio for SSR streams, but they
> will at least demux and decode without error; partially fixing
> ticket #1693.
>
> This just pulls in the decode_gain_control() function from the
> ffmpeg summer-of-code repo (original author Robert Swain) at
> svn://svn.mplayerhq.hu/soc/aac/aac.c and adds AOT_AAC_SSR to
> decode_audio_specific_config_gb().
>
> Signed-off-by: Dale Curtis 
> Co-authored-by: Robert Swain 
> ---
>  libavcodec/aacdec_template.c | 49 +---
>  1 file changed, 46 insertions(+), 3 deletions(-)
>
> diff --git a/libavcodec/aacdec_template.c b/libavcodec/aacdec_template.c
> index c2d9802023..c3ec3eefe8 100644
> --- a/libavcodec/aacdec_template.c
> +++ b/libavcodec/aacdec_template.c
> @@ -997,6 +997,7 @@ static int decode_audio_specific_config_gb(AACContext *ac,
>  switch (m4ac->object_type) {
>  case AOT_AAC_MAIN:
>  case AOT_AAC_LC:
> +case AOT_AAC_SSR:
>  case AOT_AAC_LTP:
>  case AOT_ER_AAC_LC:
>  case AOT_ER_AAC_LD:
> @@ -1967,6 +1968,44 @@ static void apply_prediction(AACContext *ac, 
> SingleChannelElement *sce)
>  reset_all_predictors(sce->predictor_state);
>  }
>
> +static int decode_gain_control(SingleChannelElement * sce, GetBitContext * 
> gb)
> +{
> +// wd_num, wd_test, aloc_size
> +static const int gain_mode[4][3] = {

I would make this uint8_t

> +{1, 0, 5},  // ONLY_LONG_SEQUENCE = 0,
> +{2, 1, 2},  // LONG_START_SEQUENCE,
> +{8, 0, 2},  // EIGHT_SHORT_SEQUENCE,
> +{2, 1, 5},  // LONG_STOP_SEQUENCE
> +};
> +
> +// per-element gain control for SSR
> +struct {
> +  int max_band;
> +  int adjust_num[4][8];
> +  int alev[4][8][8];
> +  int aloc[4][8][8];
> +} ssr;

I would drop this stack struck and replace the leaf get_bits() with
skip bits. It makes the code that much harder to exploit and there is
no point in storing data we don't plan on decoding

> +
> +const int mode = sce->ics.window_sequence[0];
> +int bd, wd, ad;
> +
> +// FIXME: Store the gain control data on |sce| and do something with it.
> +ssr.max_band = get_bits(gb, 2);
> +for (bd = 0; bd < ssr.max_band; bd++) {
> +for (wd = 0; wd < gain_mode[mode][0]; wd++) {
> +ssr.adjust_num[bd][wd] = get_bits(gb, 3);
> +for (ad = 0; ad < ssr.adjust_num[bd][wd]; ad++) {
> +ssr.alev[bd][wd][ad] = get_bits(gb, 4);
> +if (wd == 0 && gain_mode[mode][1])
> +ssr.aloc[bd][wd][ad] = get_bits(gb, 4);
> +else
> +ssr.aloc[bd][wd][ad] = get_bits(gb, gain_mode[mode][2]);
> +}
> +}
> +}
> +return 0;
> +}
> +
>  /**
>   * Decode an individual_channel_stream payload; reference: table 4.44.
>   *
> @@ -2034,9 +2073,13 @@ static int decode_ics(AACContext *ac, 
> SingleChannelElement *sce,
>  goto fail;
>  }
>  if (!eld_syntax && get_bits1(gb)) {
> -avpriv_request_sample(ac->avctx, "SSR");
> -ret = AVERROR_PATCHWELCOME;
> -goto fail;
> +// FIXME: Do something with the gain control data...
> +ret = decode_gain_control(sce, gb);
> +if (ret < 0) {
> +ret = AVERROR_PATCHWELCOME;
> +avpriv_request_sample(ac->avctx, "SSR");
> +goto fail;
> +}

This block seems funny. decode_gain_control() always returns zero.
Maybe make this warn once per stream when present like some of the
other AAC warn
cases.

>  }
>  // I see no textual basis in the spec for this occurring after SSR 
> gain
>  // control, but this is what both reference and real implmentations 
> do
> --
> 2.16.1.291.g4437f3f132-goog
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [aacdec] Parse and drop gain control data, so that SSR packets decode.

[Dale Curtis]

This will result in poor quality audio for SSR streams, but they
will at least demux and decode without error; partially fixing
ticket #1693.

This just pulls in the decode_gain_control() function from the
ffmpeg summer-of-code repo (original author Robert Swain) at
svn://svn.mplayerhq.hu/soc/aac/aac.c and adds AOT_AAC_SSR to
decode_audio_specific_config_gb().

Signed-off-by: Dale Curtis 
Co-authored-by: Robert Swain 
From 97380752ef12337d9b9a01801a9a84df3b4b9c0a Mon Sep 17 00:00:00 2001
From: Dale Curtis 
Date: Thu, 15 Feb 2018 16:22:55 -0800
Subject: [PATCH] [aacdec] Parse and drop gain control data, so that SSR
 packets decode.

This will result in poor quality audio for SSR streams, but they
will at least demux and decode without error; partially fixing
ticket #1693.

This just pulls in the decode_gain_control() function from the
ffmpeg summer-of-code repo (original author Robert Swain) at
svn://svn.mplayerhq.hu/soc/aac/aac.c and adds AOT_AAC_SSR to
decode_audio_specific_config_gb().

Signed-off-by: Dale Curtis 
Co-authored-by: Robert Swain 
---
 libavcodec/aacdec_template.c | 49 +---
 1 file changed, 46 insertions(+), 3 deletions(-)

diff --git a/libavcodec/aacdec_template.c b/libavcodec/aacdec_template.c
index c2d9802023..c3ec3eefe8 100644
--- a/libavcodec/aacdec_template.c
+++ b/libavcodec/aacdec_template.c
@@ -997,6 +997,7 @@ static int decode_audio_specific_config_gb(AACContext *ac,
 switch (m4ac->object_type) {
 case AOT_AAC_MAIN:
 case AOT_AAC_LC:
+case AOT_AAC_SSR:
 case AOT_AAC_LTP:
 case AOT_ER_AAC_LC:
 case AOT_ER_AAC_LD:
@@ -1967,6 +1968,44 @@ static void apply_prediction(AACContext *ac, SingleChannelElement *sce)
 reset_all_predictors(sce->predictor_state);
 }
 
+static int decode_gain_control(SingleChannelElement * sce, GetBitContext * gb)
+{
+// wd_num, wd_test, aloc_size
+static const int gain_mode[4][3] = {
+{1, 0, 5},  // ONLY_LONG_SEQUENCE = 0,
+{2, 1, 2},  // LONG_START_SEQUENCE,
+{8, 0, 2},  // EIGHT_SHORT_SEQUENCE,
+{2, 1, 5},  // LONG_STOP_SEQUENCE
+};
+
+// per-element gain control for SSR
+struct {
+  int max_band;
+  int adjust_num[4][8];
+  int alev[4][8][8];
+  int aloc[4][8][8];
+} ssr;
+
+const int mode = sce->ics.window_sequence[0];
+int bd, wd, ad;
+
+// FIXME: Store the gain control data on |sce| and do something with it.
+ssr.max_band = get_bits(gb, 2);
+for (bd = 0; bd < ssr.max_band; bd++) {
+for (wd = 0; wd < gain_mode[mode][0]; wd++) {
+ssr.adjust_num[bd][wd] = get_bits(gb, 3);
+for (ad = 0; ad < ssr.adjust_num[bd][wd]; ad++) {
+ssr.alev[bd][wd][ad] = get_bits(gb, 4);
+if (wd == 0 && gain_mode[mode][1])
+ssr.aloc[bd][wd][ad] = get_bits(gb, 4);
+else
+ssr.aloc[bd][wd][ad] = get_bits(gb, gain_mode[mode][2]);
+}
+}
+}
+return 0;
+}
+
 /**
  * Decode an individual_channel_stream payload; reference: table 4.44.
  *
@@ -2034,9 +2073,13 @@ static int decode_ics(AACContext *ac, SingleChannelElement *sce,
 goto fail;
 }
 if (!eld_syntax && get_bits1(gb)) {
-avpriv_request_sample(ac->avctx, "SSR");
-ret = AVERROR_PATCHWELCOME;
-goto fail;
+// FIXME: Do something with the gain control data...
+ret = decode_gain_control(sce, gb);
+if (ret < 0) {
+ret = AVERROR_PATCHWELCOME;
+avpriv_request_sample(ac->avctx, "SSR");
+goto fail;
+}
 }
 // I see no textual basis in the spec for this occurring after SSR gain
 // control, but this is what both reference and real implmentations do
-- 
2.16.1.291.g4437f3f132-goog

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

Re: [FFmpeg-devel] [PATCH 2/2] Implement dynamic loading of NewTek NDI library

[Carl Eugen Hoyos]

2018-02-20 23:35 GMT+01:00 Marton Balint :
>
> On Tue, 20 Feb 2018, Carl Eugen Hoyos wrote:
>
>> 2018-02-20 17:32 GMT+01:00 Maksym Veremeyenko :
>>
>>> attached patch implement dynamic loading of NewTek library and
>>> drop dependencies from NewTek SDK (if previous patch with
>>> including headers applied)
>>
>> This patch is not ok assuming the runtime library is not open
>> source and has a license compatible with the GPL.
>
> The patch might has merits even if the library remains in the
> NONFREE section, no?

It might, I do not immediately see them, though.

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

Re: [FFmpeg-devel] [PATCH 2/2] Implement dynamic loading of NewTek NDI library

[Marton Balint]

On Tue, 20 Feb 2018, Carl Eugen Hoyos wrote:


2018-02-20 17:32 GMT+01:00 Maksym Veremeyenko :


attached patch implement dynamic loading of NewTek library and
drop dependencies from NewTek SDK (if previous patch with
including headers applied)


This patch is not ok assuming the runtime library is not open source
and has a license compatible with the GPL.


The patch might has merits even if the library remains in the NONFREE 
section, no?


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

Re: [FFmpeg-devel] [PATCH 2/2] Implement dynamic loading of NewTek NDI library

[Carl Eugen Hoyos]

2018-02-20 17:32 GMT+01:00 Maksym Veremeyenko :

> attached patch implement dynamic loading of NewTek library and
> drop dependencies from NewTek SDK (if previous patch with
> including headers applied)

This patch is not ok assuming the runtime library is not open source
and has a license compatible with the GPL.

I suggest you leave the code as-is, Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 2/2] avformat/mpegenc - reject unsupported audio streams

[Carl Eugen Hoyos]

2018-02-20 16:17 GMT+01:00 Gyan Doshi :

Please also mention LPCM.

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

Re: [FFmpeg-devel] [PATCH] libavformat/tls: pass numeric hostnames to tls_connect_cbs()

[Carl Eugen Hoyos]

2018-02-20 19:40 GMT+01:00 Stefan _ :

> attached patch fixes a small issue with the libtls backend.

Please mention ticket #7029 if it is related.

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

Re: [FFmpeg-devel] [PATCH 0/3] Finish new iteration APIs

[Michael Niedermayer]

On Tue, Feb 20, 2018 at 06:28:20PM +0100, wm4 wrote:
> On Tue, 20 Feb 2018 17:30:32 +0100
> Michael Niedermayer  wrote:
> 
> > On Tue, Feb 20, 2018 at 10:17:02AM -0300, James Almer wrote:
> > > On 2/20/2018 9:21 AM, wm4 wrote:  
> > > > On Tue, 20 Feb 2018 08:47:51 -0300
> > > > James Almer  wrote:
> > > >   
> > > >>> It has fully achieved its objectives. There's no more visible global
> > > >>> mutable state, and the actual global mutable state has been reduced to
> > > >>> less than 5 codec entries.
> > > >>
> > > >> It's true that after the deprecation period they will effectively be 
> > > >> the
> > > >> only ones still mutable, but shouldn't the objective be to cover them 
> > > >> all?  
> > > > 
> > > > That would be nice. But this has been discussed before. No kind of
> > > > different registration API could fix this issue either, unless we start
> > > > mallocing AVCodec structs and require the user to free them, or
> > > > something equally absurd. The proper solution for this specific issue
> > > > would be making a new API that somehow replaces AVCodec.pix_fmts.
> > > >   
> > > >>>
> > > >>> Why are we discussing this _again_?
> > > >>
> > > >> Because a drawback has been found, namely that link time optimization
> > > >> using static libraries can't remove "non registered" modules anymore,
> > > >> and now depends fully on what's enabled at configure time.
> > > >> Ideally, a better registration based API that follows what i described
> > > >> above should be designed with care.  
> > > > 
> > > > Oh yeah, bikeshed attack by Michael. As it was said a few thousand times
> > > > already, public API users could NOT use the registration stuff to
> > > > register only specific components at runtime. So they have to use the
> > > > register_all variants, which pull in _all_ components even with static
> > > > linking.  
> > > 
> > > Oh, i assumed it was possible to use avcodec_register() on a manual
> > > basis in a proper API usage scenario, but i see now that's not the case.  
> > 
> > of course its possible to use avcodec_register() on a manual basis in a 
> > proper API usage scenario, why would it not be ?
> > 
> > why do you think this function exists or was written ?
> 
> I don't know, but it didn't make any sense. And wouldn't have made for
> years to come.

thats backward

if you look at git history the very first checkin 
commit 9aeeeb63f7e1ab7b0b7bb839a5f258667a2d2d78 (HEAD)
Author: Fabrice Bellard 
Date:   Wed Dec 20 00:02:47 2000 +

Initial revision

has code like this:

ffmpeg.c:register_avencoder(_encoder);
ffmpeg.c:register_avencoder(_encoder);
ffmpeg.c:register_avencoder(_encoder);
ffmpeg.c:register_avencoder(_encoder);

Here the application did use the register API to selectivly register
codecs.



> 
> And for the 100th time: the new API is completely orthogonal to
> allowing user-registered components. Since nobody could actually use
> the API before, it's no problem to drop the old APIs now, and to add
> actually working API once the other, much much much bigger problems are
> solved.
> 
> Even if you argue that keeping the linked list is absolutely necessary,
> the new API could support a linked list too.
> 
> > is it the ff_* symbols you are thinking of ?
> 
> ff_ symbols are private.
> 
> > This is a problem for an existing API it is not a problem for a new API as
> > we can change the symbols if they are intended to be used for individual
> > component registration.
> > The whole discussion is about designing a new API. So any limitation of
> > an existing API can be changed.
> > 
> > There also should be no need to call register_all in the existing API,
> > and there cannot be such a problem in a new design because it would be
> > a new design you wouldnt design it to "not work".
> 
> You're just being contradictory all across the board here. In other
> places you're claiming this register mechanism is needed for
> security or to make it possible to eliminate unused components when
> static linking. But if all components are already registered without
> doing anything, how is that supposed to work?

If an application wants to register all, it calls the register_all()
function
If an application wants to register a subset it registers just that
subset and does not call register_all

And even the documentation says this currently:
/**
 * Register all the codecs, parsers and bitstream filters which were enabled at
 * configuration time. If you do not call this function you can select exactly
 * which formats you want to support, by using the individual registration
 * functions.
 *


> 
> > 
> > > 
> > > Nevermind then, my argument was focused on preventing losing some link
> > > time optimization for static libraries assuming proper API usage.
> > >   
> > > > 
> > > > And that can't be made with dynamic linking either. If you statically
> > > > link anyway, you probably control 

Re: [FFmpeg-devel] [PATCH v2 2/3] libavfilter/vf_fps: Rewrite using activate callback

[Calvin Walton]

I've found one minor problem with this patch. The actual functionality
is correct, as best I can tell, but the stats collection
(dropped/duplicated frames) will under-report dropped frames in my
testing. I'm going to rework the stats collection code a bit, but I
expect this to be a relatively minor change.

I'll post the updated patch later this week, so please let me know if
you have any other changes I should incorporate.

Calvin.

On Mon, 2018-02-19 at 19:54 -0500, Calvin Walton wrote:
> The old version of the filter had a problem where it would queue up
> all of the duplicate frames required to fill a timestamp gap in a
> single call to filter_frame. In problematic files - I've hit this in
> webcam streams with large gaps due to network issues - this will
> queue
> up a potentially huge number of frames. (I've seen it trigger the
> Linux
> OOM-killer on particularly large pts gaps.)
> 
> This revised version of the filter using the activate callback will
> generate at most 1 frame each time it is called.
> ---
>  libavfilter/vf_fps.c | 383 ++---
> --
>  1 file changed, 199 insertions(+), 184 deletions(-)

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

[FFmpeg-devel] [PATCH] libavformat/tls: pass numeric hostnames to tls_connect_cbs()

[Stefan _]

Hi,

attached patch fixes a small issue with the libtls backend.

reported here: https://github.com/shinchiro/mpv-winbuild-cmake/issues/61

From 4bba90874839cf98ac27756c4a3137be4c84c669 Mon Sep 17 00:00:00 2001
From: sfan5 
Date: Tue, 20 Feb 2018 19:18:13 +0100
Subject: [PATCH] libavformat/tls: pass numeric hostnames to tls_connect_cbs()

Numeric hosts in certificates are not very common, but supported by LibreSSL.
Forward the IP address to make verification work in this case.
---
 libavformat/tls_libtls.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavformat/tls_libtls.c b/libavformat/tls_libtls.c
index 1321f7922..ba83b56ff 100644
--- a/libavformat/tls_libtls.c
+++ b/libavformat/tls_libtls.c
@@ -119,7 +119,7 @@ static int ff_tls_open(URLContext *h, const char *uri, int flags, AVDictionary *
 
 if (!c->listen) {
 ret = tls_connect_cbs(p->ctx, tls_read_callback, tls_write_callback,
-c->tcp, !c->numerichost ? c->host : NULL);
+c->tcp, c->host);
 } else {
 struct tls *ctx_new;
 ret = tls_accept_cbs(p->ctx, _new, tls_read_callback,
-- 
2.16.2

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

Re: [FFmpeg-devel] [PATCH 0/3] Finish new iteration APIs

[Michael Niedermayer]

On Tue, Feb 20, 2018 at 02:02:14PM -0300, James Almer wrote:
> On 2/20/2018 1:30 PM, Michael Niedermayer wrote:
> > On Tue, Feb 20, 2018 at 10:17:02AM -0300, James Almer wrote:
> >> On 2/20/2018 9:21 AM, wm4 wrote:
> >>> On Tue, 20 Feb 2018 08:47:51 -0300
> >>> James Almer  wrote:
> >>>
> > It has fully achieved its objectives. There's no more visible global
> > mutable state, and the actual global mutable state has been reduced to
> > less than 5 codec entries.  
> 
>  It's true that after the deprecation period they will effectively be the
>  only ones still mutable, but shouldn't the objective be to cover them 
>  all?
> >>>
> >>> That would be nice. But this has been discussed before. No kind of
> >>> different registration API could fix this issue either, unless we start
> >>> mallocing AVCodec structs and require the user to free them, or
> >>> something equally absurd. The proper solution for this specific issue
> >>> would be making a new API that somehow replaces AVCodec.pix_fmts.
> >>>
> >
> > Why are we discussing this _again_?  
> 
>  Because a drawback has been found, namely that link time optimization
>  using static libraries can't remove "non registered" modules anymore,
>  and now depends fully on what's enabled at configure time.
>  Ideally, a better registration based API that follows what i described
>  above should be designed with care.
> >>>
> >>> Oh yeah, bikeshed attack by Michael. As it was said a few thousand times
> >>> already, public API users could NOT use the registration stuff to
> >>> register only specific components at runtime. So they have to use the
> >>> register_all variants, which pull in _all_ components even with static
> >>> linking.
> >>
> >> Oh, i assumed it was possible to use avcodec_register() on a manual
> >> basis in a proper API usage scenario, but i see now that's not the case.
> > 
> > of course its possible to use avcodec_register() on a manual basis in a 
> > proper API usage scenario, why would it not be ?
> > 
> > why do you think this function exists or was written ?
> > 
> > is it the ff_* symbols you are thinking of ?
> 
> Yes. You can't register individual AVCodecs using avcodec_register()
> without those symbols, and in a normal API usage scenario, be it with
> the old or the new iterate one, they are not available.
> 
> > This is a problem for an existing API it is not a problem for a new API as
> > we can change the symbols if they are intended to be used for individual
> > component registration.> The whole discussion is about designing a new API. 
> > So any limitation of
> > an existing API can be changed.
> 
> Hence me also being a proponent of a different, better registration
> based API.
> I think you misunderstood what i tried to say in the email you replied
> to. You reported a drawback of this new API by giving the example of the
> fuzzer not being able to discard unused codec symbols since all are
> unconditionally referenced now. 


> I assumed that the fuzzer was using the
> API properly all this time, but turns out it's not, digging the
> internals instead to register single codecs. 

You certainly have a point here
though most strictly looking at it, the fuzzer is internal in our tree and
thus it doesnt really violate the API any more than other internal
components do.


> This therefore can't be
> considered a change in behavior compared to the current/old registration
> based API.

Well, the fuzzer binaries are like several times bigger than before that is a
difference caused by the patches. Not by the puiblic API, no
but iam not sure this way of looking at it is really helpfull to any side of
this arguemnt


> 
> Which brings me to the next part below.
> 
> > 
> > There also should be no need to call register_all in the existing API,
> > and there cannot be such a problem in a new design because it would be
> > a new design you wouldnt design it to "not work".
> > 
> > 
> >>
> >> Nevermind then, my argument was focused on preventing losing some link
> >> time optimization for static libraries assuming proper API usage.
> >>
> >>>
> >>> And that can't be made with dynamic linking either. If you statically
> >>> link anyway, you probably control everything, and you can configure this
> >>> stuff at compile time.
> >>>
> >>> Then I guess there's this very special case where a fuzzer statically
> >>> links to libavcodec, and registers only a few components (technically
> >>> violating the API and by guessing the component symbol name), and
> >>> without calling the register_all functions. This would make the
> >>> resulting executable much smaller, which is apparently important
> >>> because Google (who runs the fuzzers for their oss-fuzz project) is too
> >>> poor (?) to host all the statically linked fuzzers, _or_ the whitelist
> >>> stuff is not enough to trick the fuzzer into not trying to fuzz the
> >>> wrong code. In addition, it's apparently 

Re: [FFmpeg-devel] [PATCH 0/3] Finish new iteration APIs

[Michael Niedermayer]

On Tue, Feb 20, 2018 at 04:44:13PM +, Rostislav Pehlivanov wrote:
> On 20 February 2018 at 16:30, Michael Niedermayer 
> wrote:
> 
> > On Tue, Feb 20, 2018 at 10:17:02AM -0300, James Almer wrote:
> > > On 2/20/2018 9:21 AM, wm4 wrote:
> > > > On Tue, 20 Feb 2018 08:47:51 -0300
> > > > James Almer  wrote:
> > > >
> > > >>> It has fully achieved its objectives. There's no more visible global
> > > >>> mutable state, and the actual global mutable state has been reduced
> > to
> > > >>> less than 5 codec entries.
> > > >>
> > > >> It's true that after the deprecation period they will effectively be
> > the
> > > >> only ones still mutable, but shouldn't the objective be to cover them
> > all?
> > > >
> > > > That would be nice. But this has been discussed before. No kind of
> > > > different registration API could fix this issue either, unless we start
> > > > mallocing AVCodec structs and require the user to free them, or
> > > > something equally absurd. The proper solution for this specific issue
> > > > would be making a new API that somehow replaces AVCodec.pix_fmts.
> > > >
> > > >>>
> > > >>> Why are we discussing this _again_?
> > > >>
> > > >> Because a drawback has been found, namely that link time optimization
> > > >> using static libraries can't remove "non registered" modules anymore,
> > > >> and now depends fully on what's enabled at configure time.
> > > >> Ideally, a better registration based API that follows what i described
> > > >> above should be designed with care.
> > > >
> > > > Oh yeah, bikeshed attack by Michael. As it was said a few thousand
> > times
> > > > already, public API users could NOT use the registration stuff to
> > > > register only specific components at runtime. So they have to use the
> > > > register_all variants, which pull in _all_ components even with static
> > > > linking.
> > >
> > > Oh, i assumed it was possible to use avcodec_register() on a manual
> > > basis in a proper API usage scenario, but i see now that's not the case.
> >
> > of course its possible to use avcodec_register() on a manual basis in a
> > proper API usage scenario, why would it not be ?
> >
> > why do you think this function exists or was written ?
> >
> > is it the ff_* symbols you are thinking of ?
> > This is a problem for an existing API it is not a problem for a new API as
> > we can change the symbols if they are intended to be used for individual
> > component registration.
> > The whole discussion is about designing a new API. So any limitation of
> > an existing API can be changed.
> >
> > There also should be no need to call register_all in the existing API,
> > and there cannot be such a problem in a new design because it would be
> > a new design you wouldnt design it to "not work".
> >
> >
> > >
> > > Nevermind then, my argument was focused on preventing losing some link
> > > time optimization for static libraries assuming proper API usage.
> > >
> > > >
> > > > And that can't be made with dynamic linking either. If you statically
> > > > link anyway, you probably control everything, and you can configure
> > this
> > > > stuff at compile time.
> > > >
> > > > Then I guess there's this very special case where a fuzzer statically
> > > > links to libavcodec, and registers only a few components (technically
> > > > violating the API and by guessing the component symbol name), and
> > > > without calling the register_all functions. This would make the
> > > > resulting executable much smaller, which is apparently important
> > > > because Google (who runs the fuzzers for their oss-fuzz project) is too
> > > > poor (?) to host all the statically linked fuzzers, _or_ the whitelist
> > > > stuff is not enough to trick the fuzzer into not trying to fuzz the
> > > > wrong code. In addition, it's apparently infeasible to just build
> > > > every fuzzer with a separate libavcodec. (Not sure about the details,
> > it
> > > > was something like this.)
> > > >
> > > > Those requirements are really quite nebulous. I don't know why we even
> > > > should care - surely whoever does this will find a solution that works
> > > > for them. For example they could apply a small patch that makes the
> > > > codec_list[] symbol non-static non-const, which would allow them to
> > > > overwrite it (i.e. deleting unneeded entries). It's a really simple
> > > > solution that took me 5 minutes to come up with.
> > >
> > > Something like this is probably the best solution for the fuzzer issue,
> > yes.
> >
> > This basically says one should fork ffmpeg if one has problems with the
> > new API
> >
> > Thats a very chilling response to be honest in a discussion about that APIs
> > design. More so as this is at a time we still can change the API.
> >
> > and anyone who wants to only register a subset of components (due to
> > security)
> > has to either link to a seperate binary (which is  disallowed in some
> > major distributions which mandate shared libs 

Re: [FFmpeg-devel] [PATCH 1/2] Add NewTek NDI headers

[Nicolas George]

Maksym Veremeyenko (2018-02-20):
> attached patch add a NewTek NDI headers to source tree.

I am against this, and the second patch, based on principles: this is
helping NewTek circumvent the GPL.

Regards,

-- 
  Nicolas George


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

Re: [FFmpeg-devel] [PATCH 1/2] Add NewTek NDI headers

[Ricardo Constantino]

On 20 February 2018 at 16:32, Maksym Veremeyenko  wrote:

> Hi
>
> attached patch add a NewTek NDI headers to source tree.
>
> these headers is under MIT license.
>
> please apply.
>

Also, there's still no consideration that there's other compilers in
Windows other than MSVC:

+#ifdef _WIN32
+#define PROCESSINGNDILIB_DEPRECATED __declspec(deprecated)
+#ifdef PROCESSINGNDILIB_EXPORTS
+#ifdef __cplusplus
+#define PROCESSINGNDILIB_API extern "C" __declspec(dllexport)
+#else
+#define PROCESSINGNDILIB_API __declspec(dllexport)
+#endif
+#else
+#ifdef __cplusplus
+#define PROCESSINGNDILIB_API extern "C" __declspec(dllimport)
+#else
+#define PROCESSINGNDILIB_API __declspec(dllimport)
+#endif
+#ifdef _MSC_VER
+#ifdef _WIN64
+#define NDILIB_LIBRARY_NAME"Processing.NDI.Lib.x64.dll"
+#define NDILIB_REDIST_FOLDER   "NDI_RUNTIME_DIR_V3"
+#define NDILIB_REDIST_URL  "http://new.tk/NDIRedistV3;
+#else
+#define NDILIB_LIBRARY_NAME"Processing.NDI.Lib.x86.dll"
+#define NDILIB_REDIST_FOLDER   "NDI_RUNTIME_DIR_V3"
+#define NDILIB_REDIST_URL  "http://new.tk/NDIRedistV3;
+#endif
+#endif
+#endif
+#else
+#ifdef __APPLE__
+#define NDILIB_LIBRARY_NAME"libndi.3.dylib"
+#define NDILIB_REDIST_FOLDER   "NDI_RUNTIME_DIR_V3"
+#define NDILIB_REDIST_URL  "http://new.tk/NDIRedistV3Apple;
+#else // __APPLE__
+#define NDILIB_LIBRARY_NAME"libndi.so.3"
+#define NDILIB_REDIST_FOLDER   "NDI_RUNTIME_DIR_V3"
+#define NDILIB_REDIST_URL  ""
+#endif // __APPLE__
+#define PROCESSINGNDILIB_DEPRECATED
+#ifdef __cplusplus
+#define PROCESSINGNDILIB_API extern "C" __attribute((visibility("default")))
+#else
+#define PROCESSINGNDILIB_API __attribute((visibility("default")))
+#endif
+#endif




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

Re: [FFmpeg-devel] [PATCH 1/2] Add NewTek NDI headers

[wm4]

On Tue, 20 Feb 2018 18:32:48 +0200
Maksym Veremeyenko  wrote:

> Hi
> 
> attached patch add a NewTek NDI headers to source tree.
> 
> these headers is under MIT license.
> 
> please apply.
> 

As it was concluded in the discussion about the AMD headers, we don't
accept vendor headers in the main git repo anymore. The only case when
we did was for nvidia, but we consider that a mistake.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 0/3] Finish new iteration APIs

[wm4]

On Tue, 20 Feb 2018 17:30:32 +0100
Michael Niedermayer  wrote:

> On Tue, Feb 20, 2018 at 10:17:02AM -0300, James Almer wrote:
> > On 2/20/2018 9:21 AM, wm4 wrote:  
> > > On Tue, 20 Feb 2018 08:47:51 -0300
> > > James Almer  wrote:
> > >   
> > >>> It has fully achieved its objectives. There's no more visible global
> > >>> mutable state, and the actual global mutable state has been reduced to
> > >>> less than 5 codec entries.
> > >>
> > >> It's true that after the deprecation period they will effectively be the
> > >> only ones still mutable, but shouldn't the objective be to cover them 
> > >> all?  
> > > 
> > > That would be nice. But this has been discussed before. No kind of
> > > different registration API could fix this issue either, unless we start
> > > mallocing AVCodec structs and require the user to free them, or
> > > something equally absurd. The proper solution for this specific issue
> > > would be making a new API that somehow replaces AVCodec.pix_fmts.
> > >   
> > >>>
> > >>> Why are we discussing this _again_?
> > >>
> > >> Because a drawback has been found, namely that link time optimization
> > >> using static libraries can't remove "non registered" modules anymore,
> > >> and now depends fully on what's enabled at configure time.
> > >> Ideally, a better registration based API that follows what i described
> > >> above should be designed with care.  
> > > 
> > > Oh yeah, bikeshed attack by Michael. As it was said a few thousand times
> > > already, public API users could NOT use the registration stuff to
> > > register only specific components at runtime. So they have to use the
> > > register_all variants, which pull in _all_ components even with static
> > > linking.  
> > 
> > Oh, i assumed it was possible to use avcodec_register() on a manual
> > basis in a proper API usage scenario, but i see now that's not the case.  
> 
> of course its possible to use avcodec_register() on a manual basis in a 
> proper API usage scenario, why would it not be ?
> 
> why do you think this function exists or was written ?

I don't know, but it didn't make any sense. And wouldn't have made for
years to come.

And for the 100th time: the new API is completely orthogonal to
allowing user-registered components. Since nobody could actually use
the API before, it's no problem to drop the old APIs now, and to add
actually working API once the other, much much much bigger problems are
solved.

Even if you argue that keeping the linked list is absolutely necessary,
the new API could support a linked list too.

> is it the ff_* symbols you are thinking of ?

ff_ symbols are private.

> This is a problem for an existing API it is not a problem for a new API as
> we can change the symbols if they are intended to be used for individual
> component registration.
> The whole discussion is about designing a new API. So any limitation of
> an existing API can be changed.
> 
> There also should be no need to call register_all in the existing API,
> and there cannot be such a problem in a new design because it would be
> a new design you wouldnt design it to "not work".

You're just being contradictory all across the board here. In other
places you're claiming this register mechanism is needed for
security or to make it possible to eliminate unused components when
static linking. But if all components are already registered without
doing anything, how is that supposed to work?

> 
> > 
> > Nevermind then, my argument was focused on preventing losing some link
> > time optimization for static libraries assuming proper API usage.
> >   
> > > 
> > > And that can't be made with dynamic linking either. If you statically
> > > link anyway, you probably control everything, and you can configure this
> > > stuff at compile time.
> > > 
> > > Then I guess there's this very special case where a fuzzer statically
> > > links to libavcodec, and registers only a few components (technically
> > > violating the API and by guessing the component symbol name), and
> > > without calling the register_all functions. This would make the
> > > resulting executable much smaller, which is apparently important
> > > because Google (who runs the fuzzers for their oss-fuzz project) is too
> > > poor (?) to host all the statically linked fuzzers, _or_ the whitelist
> > > stuff is not enough to trick the fuzzer into not trying to fuzz the
> > > wrong code. In addition, it's apparently infeasible to just build
> > > every fuzzer with a separate libavcodec. (Not sure about the details, it
> > > was something like this.)
> > > 
> > > Those requirements are really quite nebulous. I don't know why we even
> > > should care - surely whoever does this will find a solution that works
> > > for them. For example they could apply a small patch that makes the
> > > codec_list[] symbol non-static non-const, which would allow them to
> > > overwrite it (i.e. deleting unneeded entries). It's a really 

[FFmpeg-devel] [PATCH v3] lavf/mpegts: add supplementary audio descriptor

[Stefan Pöschel]

The supplementary audio descriptor is defined in ETSI EN 300 468 and
provides more details regarding accessibility audio tracks, especially
the normative annex J contains a detailed description of its use.

Its language code (if present) overrides the language code of an also
present ISO 639 language descriptor.

Note that this also changes the priority of multiple descriptors with
language from "the last descriptor with language within the ES loop" to
"specific descriptor over general ISO 639 descriptor".
---
 libavformat/mpegts.c | 37 -
 1 file changed, 36 insertions(+), 1 deletion(-)

diff --git a/libavformat/mpegts.c b/libavformat/mpegts.c
index 0a3ad05..bca7a7a 100644
--- a/libavformat/mpegts.c
+++ b/libavformat/mpegts.c
@@ -1840,7 +1840,9 @@ int ff_parse_mpeg2_descriptor(AVFormatContext *fc, 
AVStream *st, int stream_type
 }
 if (i && language[0]) {
 language[i - 1] = 0;
-av_dict_set(>metadata, "language", language, 0);
+/* don't overwrite language, as it may already have been set by
+ * another, more specific descriptor (e.g. supplementary audio) */
+av_dict_set(>metadata, "language", language, 
AV_DICT_DONT_OVERWRITE);
 }
 break;
 case 0x05: /* registration descriptor */
@@ -1895,6 +1897,39 @@ int ff_parse_mpeg2_descriptor(AVFormatContext *fc, 
AVStream *st, int stream_type
 st->internal->need_context_update = 1;
 }
 }
+if (ext_desc_tag == 0x06) { /* supplementary audio descriptor */
+int flags;
+
+if (desc_len < 1)
+return AVERROR_INVALIDDATA;
+flags = get8(pp, desc_end);
+
+switch ((flags >> 2) & 0x1F) { /* editorial_classification */
+case 0x01:
+st->disposition |= AV_DISPOSITION_VISUAL_IMPAIRED;
+break;
+case 0x02:
+st->disposition |= AV_DISPOSITION_HEARING_IMPAIRED;
+break;
+case 0x03:
+st->disposition |= AV_DISPOSITION_VISUAL_IMPAIRED;
+break;
+}
+
+if (flags & 0x01) { /* language_code_present */
+if (desc_len < 4)
+return AVERROR_INVALIDDATA;
+language[0] = get8(pp, desc_end);
+language[1] = get8(pp, desc_end);
+language[2] = get8(pp, desc_end);
+language[3] = 0;
+
+/* This language always has to override a possible
+ * ISO 639 language descriptor language */
+if (language[0])
+av_dict_set(>metadata, "language", language, 0);
+}
+}
 break;
 default:
 break;
-- 
2.7.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v2] lavf/mpegts: add supplementary audio descriptor

[Stefan Pöschel]

Am 20.02.2018 um 00:13 schrieb Marton Balint:

>>> +    if (ext_desc_tag == 0x06) { /* supplementary audio descriptor */
>>> +    char flags;
> 
> Change this to int, I see no reason why this is a char.

OK, I will fix that with v3.

>> LGTM. Will commit in a couple days along with my AV_DISPOSITION_DEPENDENT
>> if no one objects.
> 
> LGTM too otherwise.

Great, thanks!

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

Re: [FFmpeg-devel] [PATCH 1/2] Add NewTek NDI headers

[Ricardo Constantino]

On 20 February 2018 at 16:32, Maksym Veremeyenko  wrote:

> Hi
>
> attached patch add a NewTek NDI headers to source tree.
>
> these headers is under MIT license.
>
> please apply.
>

Why not make them available in a public git repository instead?
FFmpeg is trying to remove these third-party headers, not accepting some
more.


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

Re: [FFmpeg-devel] [PATCH 0/3] Finish new iteration APIs

[James Almer]

On 2/20/2018 1:30 PM, Michael Niedermayer wrote:
> On Tue, Feb 20, 2018 at 10:17:02AM -0300, James Almer wrote:
>> On 2/20/2018 9:21 AM, wm4 wrote:
>>> On Tue, 20 Feb 2018 08:47:51 -0300
>>> James Almer  wrote:
>>>
> It has fully achieved its objectives. There's no more visible global
> mutable state, and the actual global mutable state has been reduced to
> less than 5 codec entries.  

 It's true that after the deprecation period they will effectively be the
 only ones still mutable, but shouldn't the objective be to cover them all?
>>>
>>> That would be nice. But this has been discussed before. No kind of
>>> different registration API could fix this issue either, unless we start
>>> mallocing AVCodec structs and require the user to free them, or
>>> something equally absurd. The proper solution for this specific issue
>>> would be making a new API that somehow replaces AVCodec.pix_fmts.
>>>
>
> Why are we discussing this _again_?  

 Because a drawback has been found, namely that link time optimization
 using static libraries can't remove "non registered" modules anymore,
 and now depends fully on what's enabled at configure time.
 Ideally, a better registration based API that follows what i described
 above should be designed with care.
>>>
>>> Oh yeah, bikeshed attack by Michael. As it was said a few thousand times
>>> already, public API users could NOT use the registration stuff to
>>> register only specific components at runtime. So they have to use the
>>> register_all variants, which pull in _all_ components even with static
>>> linking.
>>
>> Oh, i assumed it was possible to use avcodec_register() on a manual
>> basis in a proper API usage scenario, but i see now that's not the case.
> 
> of course its possible to use avcodec_register() on a manual basis in a 
> proper API usage scenario, why would it not be ?
> 
> why do you think this function exists or was written ?
> 
> is it the ff_* symbols you are thinking of ?

Yes. You can't register individual AVCodecs using avcodec_register()
without those symbols, and in a normal API usage scenario, be it with
the old or the new iterate one, they are not available.

> This is a problem for an existing API it is not a problem for a new API as
> we can change the symbols if they are intended to be used for individual
> component registration.> The whole discussion is about designing a new API. 
> So any limitation of
> an existing API can be changed.

Hence me also being a proponent of a different, better registration
based API.
I think you misunderstood what i tried to say in the email you replied
to. You reported a drawback of this new API by giving the example of the
fuzzer not being able to discard unused codec symbols since all are
unconditionally referenced now. I assumed that the fuzzer was using the
API properly all this time, but turns out it's not, digging the
internals instead to register single codecs. This therefore can't be
considered a change in behavior compared to the current/old registration
based API.

Which brings me to the next part below.

> 
> There also should be no need to call register_all in the existing API,
> and there cannot be such a problem in a new design because it would be
> a new design you wouldnt design it to "not work".
> 
> 
>>
>> Nevermind then, my argument was focused on preventing losing some link
>> time optimization for static libraries assuming proper API usage.
>>
>>>
>>> And that can't be made with dynamic linking either. If you statically
>>> link anyway, you probably control everything, and you can configure this
>>> stuff at compile time.
>>>
>>> Then I guess there's this very special case where a fuzzer statically
>>> links to libavcodec, and registers only a few components (technically
>>> violating the API and by guessing the component symbol name), and
>>> without calling the register_all functions. This would make the
>>> resulting executable much smaller, which is apparently important
>>> because Google (who runs the fuzzers for their oss-fuzz project) is too
>>> poor (?) to host all the statically linked fuzzers, _or_ the whitelist
>>> stuff is not enough to trick the fuzzer into not trying to fuzz the
>>> wrong code. In addition, it's apparently infeasible to just build
>>> every fuzzer with a separate libavcodec. (Not sure about the details, it
>>> was something like this.)
>>>
>>> Those requirements are really quite nebulous. I don't know why we even
>>> should care - surely whoever does this will find a solution that works
>>> for them. For example they could apply a small patch that makes the
>>> codec_list[] symbol non-static non-const, which would allow them to
>>> overwrite it (i.e. deleting unneeded entries). It's a really simple
>>> solution that took me 5 minutes to come up with.
>>
>> Something like this is probably the best solution for the fuzzer issue, yes.
> 
> This basically says one should fork ffmpeg 

Re: [FFmpeg-devel] FFmpeg 3.5 / 4.0

[Reto Kromer]

Reto Kromer wrote:

>I suggest as well to move the 2.8 branch from the Releases to
>the Old Releases.

I just noticed that the day before yesterday 2.8.14 has been
released, therefore please ignore my suggestion. Thank you!

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

Re: [FFmpeg-devel] [PATCH 0/3] Finish new iteration APIs

[Rostislav Pehlivanov]

On 20 February 2018 at 16:30, Michael Niedermayer 
wrote:

> On Tue, Feb 20, 2018 at 10:17:02AM -0300, James Almer wrote:
> > On 2/20/2018 9:21 AM, wm4 wrote:
> > > On Tue, 20 Feb 2018 08:47:51 -0300
> > > James Almer  wrote:
> > >
> > >>> It has fully achieved its objectives. There's no more visible global
> > >>> mutable state, and the actual global mutable state has been reduced
> to
> > >>> less than 5 codec entries.
> > >>
> > >> It's true that after the deprecation period they will effectively be
> the
> > >> only ones still mutable, but shouldn't the objective be to cover them
> all?
> > >
> > > That would be nice. But this has been discussed before. No kind of
> > > different registration API could fix this issue either, unless we start
> > > mallocing AVCodec structs and require the user to free them, or
> > > something equally absurd. The proper solution for this specific issue
> > > would be making a new API that somehow replaces AVCodec.pix_fmts.
> > >
> > >>>
> > >>> Why are we discussing this _again_?
> > >>
> > >> Because a drawback has been found, namely that link time optimization
> > >> using static libraries can't remove "non registered" modules anymore,
> > >> and now depends fully on what's enabled at configure time.
> > >> Ideally, a better registration based API that follows what i described
> > >> above should be designed with care.
> > >
> > > Oh yeah, bikeshed attack by Michael. As it was said a few thousand
> times
> > > already, public API users could NOT use the registration stuff to
> > > register only specific components at runtime. So they have to use the
> > > register_all variants, which pull in _all_ components even with static
> > > linking.
> >
> > Oh, i assumed it was possible to use avcodec_register() on a manual
> > basis in a proper API usage scenario, but i see now that's not the case.
>
> of course its possible to use avcodec_register() on a manual basis in a
> proper API usage scenario, why would it not be ?
>
> why do you think this function exists or was written ?
>
> is it the ff_* symbols you are thinking of ?
> This is a problem for an existing API it is not a problem for a new API as
> we can change the symbols if they are intended to be used for individual
> component registration.
> The whole discussion is about designing a new API. So any limitation of
> an existing API can be changed.
>
> There also should be no need to call register_all in the existing API,
> and there cannot be such a problem in a new design because it would be
> a new design you wouldnt design it to "not work".
>
>
> >
> > Nevermind then, my argument was focused on preventing losing some link
> > time optimization for static libraries assuming proper API usage.
> >
> > >
> > > And that can't be made with dynamic linking either. If you statically
> > > link anyway, you probably control everything, and you can configure
> this
> > > stuff at compile time.
> > >
> > > Then I guess there's this very special case where a fuzzer statically
> > > links to libavcodec, and registers only a few components (technically
> > > violating the API and by guessing the component symbol name), and
> > > without calling the register_all functions. This would make the
> > > resulting executable much smaller, which is apparently important
> > > because Google (who runs the fuzzers for their oss-fuzz project) is too
> > > poor (?) to host all the statically linked fuzzers, _or_ the whitelist
> > > stuff is not enough to trick the fuzzer into not trying to fuzz the
> > > wrong code. In addition, it's apparently infeasible to just build
> > > every fuzzer with a separate libavcodec. (Not sure about the details,
> it
> > > was something like this.)
> > >
> > > Those requirements are really quite nebulous. I don't know why we even
> > > should care - surely whoever does this will find a solution that works
> > > for them. For example they could apply a small patch that makes the
> > > codec_list[] symbol non-static non-const, which would allow them to
> > > overwrite it (i.e. deleting unneeded entries). It's a really simple
> > > solution that took me 5 minutes to come up with.
> >
> > Something like this is probably the best solution for the fuzzer issue,
> yes.
>
> This basically says one should fork ffmpeg if one has problems with the
> new API
>
> Thats a very chilling response to be honest in a discussion about that APIs
> design. More so as this is at a time we still can change the API.
>
> and anyone who wants to only register a subset of components (due to
> security)
> has to either link to a seperate binary (which is  disallowed in some
> major distributions which mandate shared libs without exception IIRC so
> that
> sounds great but simple isnt possible)
> or just not use FFmpeg or fork it or use a fork or just forget about only
> registering a subset.
>

You bring up the security argument but I don't see anything here which
would compromise it. _All_ the 

[FFmpeg-devel] [PATCH 2/2] Implement dynamic loading of NewTek NDI library

[Maksym Veremeyenko]

Hi

attached patch implement dynamic loading of NewTek library and drop 
dependencies from NewTek SDK (if previous patch with including headers 
applied)


please review/comment/apply

--
Maksym Veremeyenko

From 8c0337878bdb8a1ccbc56ede42686e2a4d8e882e Mon Sep 17 00:00:00 2001
From: Maksym Veremeyenko 
Date: Tue, 20 Feb 2018 17:16:46 +0200
Subject: [PATCH 2/2] Implement dynamic loading of NewTek NDI library

---
 configure  |   8 +--
 libavdevice/Makefile   |   4 +-
 libavdevice/libndi_newtek_common.c | 105 +
 libavdevice/libndi_newtek_common.h |   4 +-
 libavdevice/libndi_newtek_dec.c|  32 ++-
 libavdevice/libndi_newtek_enc.c|  16 --
 6 files changed, 144 insertions(+), 25 deletions(-)
 create mode 100644 libavdevice/libndi_newtek_common.c

diff --git a/configure b/configure
index 013308c..4782c77 100755
--- a/configure
+++ b/configure
@@ -1569,7 +1569,6 @@ EXTERNAL_LIBRARY_GPL_LIST="
 
 EXTERNAL_LIBRARY_NONFREE_LIST="
 decklink
-libndi_newtek
 libfdk_aac
 openssl
 libtls
@@ -1648,6 +1647,7 @@ EXTERNAL_LIBRARY_LIST="
 mediacodec
 openal
 opengl
+libndi_newtek
 "
 
 HWACCEL_AUTODETECT_LIBRARY_LIST="
@@ -3093,10 +3093,11 @@ decklink_indev_deps="decklink threads"
 decklink_indev_extralibs="-lstdc++"
 decklink_outdev_deps="decklink threads"
 decklink_outdev_extralibs="-lstdc++"
+libndi_newtek_deps_any="libdl LoadLibrary"
 libndi_newtek_indev_deps="libndi_newtek"
-libndi_newtek_indev_extralibs="-lndi"
+libndi_newtek_indev_extralibs=""
 libndi_newtek_outdev_deps="libndi_newtek"
-libndi_newtek_outdev_extralibs="-lndi"
+libndi_newtek_outdev_extralibs=""
 dshow_indev_deps="IBaseFilter"
 dshow_indev_extralibs="-lpsapi -lole32 -lstrmiids -luuid -loleaut32 -lshlwapi"
 fbdev_indev_deps="linux_fb_h"
@@ -5866,7 +5867,6 @@ enabled cuda_sdk  && require cuda_sdk cuda.h 
cuCtxCreate -lcuda
 enabled chromaprint   && require chromaprint chromaprint.h 
chromaprint_get_version -lchromaprint
 enabled decklink  && { require_header DeckLinkAPI.h &&
{ check_cpp_condition DeckLinkAPIVersion.h 
"BLACKMAGIC_DECKLINK_API_VERSION >= 0x0a060100" || die "ERROR: Decklink API 
version must be >= 10.6.1."; } }
-enabled libndi_newtek && require_header Processing.NDI.Lib.h
 enabled frei0r&& require_header frei0r.h
 enabled gmp   && require gmp gmp.h mpz_export -lgmp
 enabled gnutls&& require_pkg_config gnutls gnutls gnutls/gnutls.h 
gnutls_global_init
diff --git a/libavdevice/Makefile b/libavdevice/Makefile
index 8228d62..2d3322e 100644
--- a/libavdevice/Makefile
+++ b/libavdevice/Makefile
@@ -19,8 +19,8 @@ OBJS-$(CONFIG_BKTR_INDEV)+= bktr.o
 OBJS-$(CONFIG_CACA_OUTDEV)   += caca.o
 OBJS-$(CONFIG_DECKLINK_OUTDEV)   += decklink_enc.o decklink_enc_c.o 
decklink_common.o
 OBJS-$(CONFIG_DECKLINK_INDEV)+= decklink_dec.o decklink_dec_c.o 
decklink_common.o
-OBJS-$(CONFIG_LIBNDI_NEWTEK_OUTDEV)  += libndi_newtek_enc.o
-OBJS-$(CONFIG_LIBNDI_NEWTEK_INDEV)   += libndi_newtek_dec.o
+OBJS-$(CONFIG_LIBNDI_NEWTEK_OUTDEV)  += libndi_newtek_enc.o 
libndi_newtek_common.o
+OBJS-$(CONFIG_LIBNDI_NEWTEK_INDEV)   += libndi_newtek_dec.o 
libndi_newtek_common.o
 OBJS-$(CONFIG_DSHOW_INDEV)   += dshow_crossbar.o dshow.o 
dshow_enummediatypes.o \
 dshow_enumpins.o dshow_filter.o \
 dshow_pin.o dshow_common.o
diff --git a/libavdevice/libndi_newtek_common.c 
b/libavdevice/libndi_newtek_common.c
new file mode 100644
index 000..5202993
--- /dev/null
+++ b/libavdevice/libndi_newtek_common.c
@@ -0,0 +1,105 @@
+/*
+ * NewTek NDI common code
+ * Copyright (c) 2018 Maksym Veremeyenko
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include "libavformat/avformat.h"
+#include "libavformat/internal.h"
+#include "libavutil/opt.h"
+#include "libavutil/imgutils.h"
+
+#ifdef _WIN32
+#include 
+#else
+#include 
+#endif
+
+#include "libndi_newtek_common.h"
+
+#define NDI_LIB_LOAD_ERROR_TEXT "\nPlease re-install the NewTek NDI Runtimes 
from " NDILIB_REDIST_URL " to use 

[FFmpeg-devel] [PATCH 1/2] Add NewTek NDI headers

[Maksym Veremeyenko]

Hi

attached patch add a NewTek NDI headers to source tree.

these headers is under MIT license.

please apply.

--
Maksym Veremeyenko

From 1f0ac55ce4da973f8def3ab24a70381007382cb8 Mon Sep 17 00:00:00 2001
From: Maksym Veremeyenko 
Date: Tue, 20 Feb 2018 17:14:46 +0200
Subject: [PATCH 1/2] Add NewTek NDI headers

---
 compat/libndi_newtek/Processing.NDI.DynamicLoad.h  | 128 +++
 compat/libndi_newtek/Processing.NDI.Find.h |  74 ++
 .../libndi_newtek/Processing.NDI.Lib.cplusplus.h   |  94 
 compat/libndi_newtek/Processing.NDI.Lib.h  | 129 +++
 compat/libndi_newtek/Processing.NDI.Recv.ex.h  | 148 
 compat/libndi_newtek/Processing.NDI.Recv.h | 214 ++
 compat/libndi_newtek/Processing.NDI.Routing.h  |  59 +
 compat/libndi_newtek/Processing.NDI.Send.h | 126 +++
 compat/libndi_newtek/Processing.NDI.compat.h   |  39 
 compat/libndi_newtek/Processing.NDI.deprecated.h   | 213 ++
 compat/libndi_newtek/Processing.NDI.structs.h  | 247 +
 compat/libndi_newtek/Processing.NDI.utilities.h| 108 +
 12 files changed, 1579 insertions(+)
 create mode 100644 compat/libndi_newtek/Processing.NDI.DynamicLoad.h
 create mode 100644 compat/libndi_newtek/Processing.NDI.Find.h
 create mode 100644 compat/libndi_newtek/Processing.NDI.Lib.cplusplus.h
 create mode 100644 compat/libndi_newtek/Processing.NDI.Lib.h
 create mode 100644 compat/libndi_newtek/Processing.NDI.Recv.ex.h
 create mode 100644 compat/libndi_newtek/Processing.NDI.Recv.h
 create mode 100644 compat/libndi_newtek/Processing.NDI.Routing.h
 create mode 100644 compat/libndi_newtek/Processing.NDI.Send.h
 create mode 100644 compat/libndi_newtek/Processing.NDI.compat.h
 create mode 100644 compat/libndi_newtek/Processing.NDI.deprecated.h
 create mode 100644 compat/libndi_newtek/Processing.NDI.structs.h
 create mode 100644 compat/libndi_newtek/Processing.NDI.utilities.h

diff --git a/compat/libndi_newtek/Processing.NDI.DynamicLoad.h 
b/compat/libndi_newtek/Processing.NDI.DynamicLoad.h
new file mode 100644
index 000..6ec390b
--- /dev/null
+++ b/compat/libndi_newtek/Processing.NDI.DynamicLoad.h
@@ -0,0 +1,128 @@
+#pragma once
+
+// NOTE : The following MIT license applies to this file ONLY and not to the 
SDK as a whole. Please review the SDK documentation 
+// for the description of the full license terms, which are also provided in 
the file "NDI License Agreement.pdf" within the SDK or 
+// online at http://new.tk/ndisdk_license/. Your use of any part of this SDK 
is acknowledgment that you agree to the SDK license 
+// terms. THe full NDI SDK may be downloaded at https://www.newtek.com/ndi/sdk/
+//
+//***
+// 
+// Copyright(c) 2014-2017 NewTek, inc
+// 
+// Permission is hereby granted, free of charge, to any person obtaining a 
copy of this software and associated documentation 
+// files(the "Software"), to deal in the Software without restriction, 
including without limitation the rights to use, copy, modify, 
+// merge, publish, distribute, sublicense, and / or sell copies of the 
Software, and to permit persons to whom the Software is 
+// furnished to do so, subject to the following conditions :
+//
+// The above copyright notice and this permission notice shall be included in 
all copies or substantial portions of the Software.
+// 
+// THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR 
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF 
+// MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.IN NO 
EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE 
+// FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF 
CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION 
+// WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
+//
+//***
+
+//
+typedef struct NDIlib_v3
+{  // V1.5
+   bool(*NDIlib_initialize)(void);
+   void(*NDIlib_destroy)(void);
+   const char* (*NDIlib_version)(void);
+   bool(*NDIlib_is_supported_CPU)(void);
+   PROCESSINGNDILIB_DEPRECATED 
NDIlib_find_instance_t(*NDIlib_find_create)(const NDIlib_find_create_t* 
p_create_settings);
+   NDIlib_find_instance_t(*NDIlib_find_create_v2)(const 
NDIlib_find_create_t* p_create_settings);
+   void(*NDIlib_find_destroy)(NDIlib_find_instance_t p_instance);
+   const NDIlib_source_t* 
(*NDIlib_find_get_sources)(NDIlib_find_instance_t p_instance, uint32_t* 
p_no_sources, uint32_t timeout_in_ms);
+   

Re: [FFmpeg-devel] [PATCH 0/3] Finish new iteration APIs

[Michael Niedermayer]

On Tue, Feb 20, 2018 at 10:17:02AM -0300, James Almer wrote:
> On 2/20/2018 9:21 AM, wm4 wrote:
> > On Tue, 20 Feb 2018 08:47:51 -0300
> > James Almer  wrote:
> > 
> >>> It has fully achieved its objectives. There's no more visible global
> >>> mutable state, and the actual global mutable state has been reduced to
> >>> less than 5 codec entries.  
> >>
> >> It's true that after the deprecation period they will effectively be the
> >> only ones still mutable, but shouldn't the objective be to cover them all?
> > 
> > That would be nice. But this has been discussed before. No kind of
> > different registration API could fix this issue either, unless we start
> > mallocing AVCodec structs and require the user to free them, or
> > something equally absurd. The proper solution for this specific issue
> > would be making a new API that somehow replaces AVCodec.pix_fmts.
> > 
> >>>
> >>> Why are we discussing this _again_?  
> >>
> >> Because a drawback has been found, namely that link time optimization
> >> using static libraries can't remove "non registered" modules anymore,
> >> and now depends fully on what's enabled at configure time.
> >> Ideally, a better registration based API that follows what i described
> >> above should be designed with care.
> > 
> > Oh yeah, bikeshed attack by Michael. As it was said a few thousand times
> > already, public API users could NOT use the registration stuff to
> > register only specific components at runtime. So they have to use the
> > register_all variants, which pull in _all_ components even with static
> > linking.
> 
> Oh, i assumed it was possible to use avcodec_register() on a manual
> basis in a proper API usage scenario, but i see now that's not the case.

of course its possible to use avcodec_register() on a manual basis in a 
proper API usage scenario, why would it not be ?

why do you think this function exists or was written ?

is it the ff_* symbols you are thinking of ?
This is a problem for an existing API it is not a problem for a new API as
we can change the symbols if they are intended to be used for individual
component registration.
The whole discussion is about designing a new API. So any limitation of
an existing API can be changed.

There also should be no need to call register_all in the existing API,
and there cannot be such a problem in a new design because it would be
a new design you wouldnt design it to "not work".


> 
> Nevermind then, my argument was focused on preventing losing some link
> time optimization for static libraries assuming proper API usage.
> 
> > 
> > And that can't be made with dynamic linking either. If you statically
> > link anyway, you probably control everything, and you can configure this
> > stuff at compile time.
> > 
> > Then I guess there's this very special case where a fuzzer statically
> > links to libavcodec, and registers only a few components (technically
> > violating the API and by guessing the component symbol name), and
> > without calling the register_all functions. This would make the
> > resulting executable much smaller, which is apparently important
> > because Google (who runs the fuzzers for their oss-fuzz project) is too
> > poor (?) to host all the statically linked fuzzers, _or_ the whitelist
> > stuff is not enough to trick the fuzzer into not trying to fuzz the
> > wrong code. In addition, it's apparently infeasible to just build
> > every fuzzer with a separate libavcodec. (Not sure about the details, it
> > was something like this.)
> > 
> > Those requirements are really quite nebulous. I don't know why we even
> > should care - surely whoever does this will find a solution that works
> > for them. For example they could apply a small patch that makes the
> > codec_list[] symbol non-static non-const, which would allow them to
> > overwrite it (i.e. deleting unneeded entries). It's a really simple
> > solution that took me 5 minutes to come up with.
> 
> Something like this is probably the best solution for the fuzzer issue, yes.

This basically says one should fork ffmpeg if one has problems with the new API

Thats a very chilling response to be honest in a discussion about that APIs
design. More so as this is at a time we still can change the API.

and anyone who wants to only register a subset of components (due to security)
has to either link to a seperate binary (which is  disallowed in some 
major distributions which mandate shared libs without exception IIRC so that
sounds great but simple isnt possible)
or just not use FFmpeg or fork it or use a fork or just forget about only
registering a subset.

IMO, an API that allows registering subsets of components would be wiser
for FFmpeg.

Of course we can go with a API that doesnt allow subset registeration but
then later we need to add an API to seperatly register user componentgs 
(plugins),
so 2 APIs and our fuzzer needs to patch that API, and browsers which may only 
want to register a subset of codecs & formats 

[FFmpeg-devel] [PATCH 2/2] avformat/mpegenc - reject unsupported audio streams

[Gyan Doshi]

From f0aabc7b9f959dc94084fb6d9b644104fc203566 Mon Sep 17 00:00:00 2001
From: Gyan Doshi 
Date: Tue, 20 Feb 2018 20:42:21 +0530
Subject: [PATCH 2/2] avformat/mpegenc - reject unsupported audio streams

Only MP2, MP3, PCM S16BE, AC3 and DTS audio codecs
are supported by the muxer.
---
 libavformat/mpegenc.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/libavformat/mpegenc.c b/libavformat/mpegenc.c
index 4c6fa67fb8..59e3f8c83f 100644
--- a/libavformat/mpegenc.c
+++ b/libavformat/mpegenc.c
@@ -392,6 +392,10 @@ static av_cold int mpeg_mux_init(AVFormatContext *ctx)
 stream->lpcm_header[1] = (st->codecpar->channels - 1) | (j << 
4);
 stream->lpcm_header[2] = 0x80;
 stream->lpcm_align = st->codecpar->channels * 2;
+} else if (st->codecpar->codec_id != AV_CODEC_ID_MP2 &&
+   st->codecpar->codec_id != AV_CODEC_ID_MP3) {
+   av_log(ctx, AV_LOG_ERROR, "Unsupported audio codec. 
Must be one of mp2, mp3, pcm_s16be, ac3 or dts.\n");
+   goto fail;
 } else {
 stream->id = mpa_id++;
 }
-- 
2.12.2.windows.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH 1/2] avformat/mpegenc - log error msgs for unsupported LPCM streams

[Gyan Doshi]

From 5f5cc12ff449fecfe668ec4537b8f2bb16d896d7 Mon Sep 17 00:00:00 2001
From: Gyan Doshi 
Date: Tue, 20 Feb 2018 20:31:28 +0530
Subject: [PATCH 1/2] avformat/mpegenc - log error msgs for unsupported LPCM
 streams

The MPEG-PS muxer only accepts PCM streams having up to 8 channels
and the following sampling rates: 32/44.1/48/96 kHz.
---
 libavformat/mpegenc.c | 15 ---
 1 file changed, 12 insertions(+), 3 deletions(-)

diff --git a/libavformat/mpegenc.c b/libavformat/mpegenc.c
index c84dc52eb9..4c6fa67fb8 100644
--- a/libavformat/mpegenc.c
+++ b/libavformat/mpegenc.c
@@ -375,10 +375,19 @@ static av_cold int mpeg_mux_init(AVFormatContext *ctx)
 if (lpcm_freq_tab[j] == st->codecpar->sample_rate)
 break;
 }
-if (j == 4)
+if (j == 4) {
+int sr;
+av_log(ctx, AV_LOG_ERROR, "Invalid sampling rate for PCM 
stream.\n");
+av_log(ctx, AV_LOG_INFO, "Allowed sampling rates:");
+for (sr = 0; sr < 4; sr++)
+ av_log(ctx, AV_LOG_INFO, " %d", lpcm_freq_tab[sr]);
+av_log(ctx, AV_LOG_INFO, "\n");
 goto fail;
-if (st->codecpar->channels > 8)
-return -1;
+}
+if (st->codecpar->channels > 8) {
+av_log(ctx, AV_LOG_ERROR, "At most 8 channels allowed for 
LPCM streams.\n");
+goto fail;
+}
 stream->lpcm_header[0] = 0x0c;
 stream->lpcm_header[1] = (st->codecpar->channels - 1) | (j << 
4);
 stream->lpcm_header[2] = 0x80;
-- 
2.12.2.windows.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/3] avformat/movenc: addition of flag to fragment at every frame

[Michael Niedermayer]

On Mon, Feb 19, 2018 at 11:25:09AM +0530, vdi...@akamai.com wrote:
> From: Vishwanath Dixit 
> 
> ---
>  libavformat/movenc.c | 10 +++---
>  libavformat/movenc.h |  1 +
>  2 files changed, 8 insertions(+), 3 deletions(-)

will apply

thx

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

Modern terrorism, a quick summary: Need oil, start war with country that
has oil, kill hundread thousand in war. Let country fall into chaos,
be surprised about raise of fundamantalists. Drop more bombs, kill more
people, be surprised about them taking revenge and drop even more bombs
and strip your own citizens of their rights and freedoms. to be continued


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

Re: [FFmpeg-devel] [PATCH 1/3] avcodec/aacdec_templat: Fix integer overflow in apply_ltp()

[Michael Niedermayer]

On Sun, Feb 18, 2018 at 11:07:20PM +0100, Michael Niedermayer wrote:
> Fixes: signed integer overflow: -1625276744 + -1041893960 cannot be 
> represented in type 'int'
> Fixes: 5948/clusterfuzz-testcase-minimized-5791479856365568
> 
> Found-by: continuous fuzzing process 
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by: Michael Niedermayer 
> ---
>  libavcodec/aacdec_template.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

will apply patchset

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

I have never wished to cater to the crowd; for what I know they do not
approve, and what they approve I do not know. -- Epicurus


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

Re: [FFmpeg-devel] [PATCH 2/2] avcodec/jpeg2000dwt: Fix integer overflows in sr_1d53()

[Michael Niedermayer]

On Sun, Feb 18, 2018 at 12:34:11AM +0100, Michael Niedermayer wrote:
> Fixes: 5918/clusterfuzz-testcase-minimized-5120505435652096
> 
> Found-by: continuous fuzzing process 
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by: Michael Niedermayer 
> ---
>  libavcodec/jpeg2000dwt.c | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)

will apply

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

No great genius has ever existed without some touch of madness. -- Aristotle


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

Re: [FFmpeg-devel] [PATCH 1/2] avcodec/diracdec: Use int64 in global mv to prevent overflow

[Michael Niedermayer]

On Sun, Feb 18, 2018 at 12:34:10AM +0100, Michael Niedermayer wrote:
> Fixes: runtime error: signed integer overflow: 361 * -6295541 cannot be 
> represented in type 'int'
> Fixes: 5911/clusterfuzz-testcase-minimized-6450382197751808
> 
> Found-by: continuous fuzzing process 
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by: Michael Niedermayer 
> ---
>  libavcodec/diracdec.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)

will apply

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

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


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

Re: [FFmpeg-devel] [PATCH 1/3] avcodec/dxtory: Remove code that corrupts dimensions

[Michael Niedermayer]

On Sat, Feb 17, 2018 at 10:25:10PM +0100, Michael Niedermayer wrote:
> Fixes: Timeout
> Fixes: 5796/clusterfuzz-testcase-minimized-5206729085157376
> 
> Does someone have a valid sample that triggers this path ?
> 
> Found-by: continuous fuzzing process 
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by: Michael Niedermayer 
> ---
>  libavcodec/dxtory.c | 6 +-
>  1 file changed, 1 insertion(+), 5 deletions(-)

will apply

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

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


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

Re: [FFmpeg-devel] [PATCH 0/3] Finish new iteration APIs

[James Almer]

On 2/20/2018 9:21 AM, wm4 wrote:
> On Tue, 20 Feb 2018 08:47:51 -0300
> James Almer  wrote:
> 
>>> It has fully achieved its objectives. There's no more visible global
>>> mutable state, and the actual global mutable state has been reduced to
>>> less than 5 codec entries.  
>>
>> It's true that after the deprecation period they will effectively be the
>> only ones still mutable, but shouldn't the objective be to cover them all?
> 
> That would be nice. But this has been discussed before. No kind of
> different registration API could fix this issue either, unless we start
> mallocing AVCodec structs and require the user to free them, or
> something equally absurd. The proper solution for this specific issue
> would be making a new API that somehow replaces AVCodec.pix_fmts.
> 
>>>
>>> Why are we discussing this _again_?  
>>
>> Because a drawback has been found, namely that link time optimization
>> using static libraries can't remove "non registered" modules anymore,
>> and now depends fully on what's enabled at configure time.
>> Ideally, a better registration based API that follows what i described
>> above should be designed with care.
> 
> Oh yeah, bikeshed attack by Michael. As it was said a few thousand times
> already, public API users could NOT use the registration stuff to
> register only specific components at runtime. So they have to use the
> register_all variants, which pull in _all_ components even with static
> linking.

Oh, i assumed it was possible to use avcodec_register() on a manual
basis in a proper API usage scenario, but i see now that's not the case.

Nevermind then, my argument was focused on preventing losing some link
time optimization for static libraries assuming proper API usage.

> 
> And that can't be made with dynamic linking either. If you statically
> link anyway, you probably control everything, and you can configure this
> stuff at compile time.
> 
> Then I guess there's this very special case where a fuzzer statically
> links to libavcodec, and registers only a few components (technically
> violating the API and by guessing the component symbol name), and
> without calling the register_all functions. This would make the
> resulting executable much smaller, which is apparently important
> because Google (who runs the fuzzers for their oss-fuzz project) is too
> poor (?) to host all the statically linked fuzzers, _or_ the whitelist
> stuff is not enough to trick the fuzzer into not trying to fuzz the
> wrong code. In addition, it's apparently infeasible to just build
> every fuzzer with a separate libavcodec. (Not sure about the details, it
> was something like this.)
> 
> Those requirements are really quite nebulous. I don't know why we even
> should care - surely whoever does this will find a solution that works
> for them. For example they could apply a small patch that makes the
> codec_list[] symbol non-static non-const, which would allow them to
> overwrite it (i.e. deleting unneeded entries). It's a really simple
> solution that took me 5 minutes to come up with.

Something like this is probably the best solution for the fuzzer issue, yes.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 0/3] Finish new iteration APIs

[wm4]

On Tue, 20 Feb 2018 08:47:51 -0300
James Almer  wrote:

> > It has fully achieved its objectives. There's no more visible global
> > mutable state, and the actual global mutable state has been reduced to
> > less than 5 codec entries.  
> 
> It's true that after the deprecation period they will effectively be the
> only ones still mutable, but shouldn't the objective be to cover them all?

That would be nice. But this has been discussed before. No kind of
different registration API could fix this issue either, unless we start
mallocing AVCodec structs and require the user to free them, or
something equally absurd. The proper solution for this specific issue
would be making a new API that somehow replaces AVCodec.pix_fmts.

> > 
> > Why are we discussing this _again_?  
> 
> Because a drawback has been found, namely that link time optimization
> using static libraries can't remove "non registered" modules anymore,
> and now depends fully on what's enabled at configure time.
> Ideally, a better registration based API that follows what i described
> above should be designed with care.

Oh yeah, bikeshed attack by Michael. As it was said a few thousand times
already, public API users could NOT use the registration stuff to
register only specific components at runtime. So they have to use the
register_all variants, which pull in _all_ components even with static
linking.

And that can't be made with dynamic linking either. If you statically
link anyway, you probably control everything, and you can configure this
stuff at compile time.

Then I guess there's this very special case where a fuzzer statically
links to libavcodec, and registers only a few components (technically
violating the API and by guessing the component symbol name), and
without calling the register_all functions. This would make the
resulting executable much smaller, which is apparently important
because Google (who runs the fuzzers for their oss-fuzz project) is too
poor (?) to host all the statically linked fuzzers, _or_ the whitelist
stuff is not enough to trick the fuzzer into not trying to fuzz the
wrong code. In addition, it's apparently infeasible to just build
every fuzzer with a separate libavcodec. (Not sure about the details, it
was something like this.)

Those requirements are really quite nebulous. I don't know why we even
should care - surely whoever does this will find a solution that works
for them. For example they could apply a small patch that makes the
codec_list[] symbol non-static non-const, which would allow them to
overwrite it (i.e. deleting unneeded entries). It's a really simple
solution that took me 5 minutes to come up with.

The security argument is absurd, because you'd just disable them at
compile time, and if you really want to restrict components at compile
time, there's this whitelist stuff for codecs and a few other things.

I feel like I've written this post 3 trillion times, and Michael never
read any of them.

> >   
> >> Whatever is done, in any case, should be decided fast. The current new
> >> API is in the tree and should be removed without delay if we decide to
> >> not use it in the end, even if a proper replacement is not written in
> >> the short term.  
> > 
> > What needs to be done is testing and applying these patches.  
> 
> What makes me uneasy is that if this API remains is place, introducing a
> new better one would be annoying for downstream users if it's added too
> close to the end of the old API's deprecation period, be it before or
> after. Having to migrate a second time in a short time frame is undesirable.
> 
> In any case, just my two cents. Don't take this as a blocker for this
> set, but as a request to consider better alternatives in the short or
> long term.

Like what? What color is it going to be?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 0/3] Finish new iteration APIs

[James Almer]

On 2/20/2018 3:24 AM, wm4 wrote:
> On Mon, 19 Feb 2018 23:30:24 -0300
> James Almer  wrote:
> 
>> On 2/19/2018 11:16 PM, Michael Niedermayer wrote:
>>> On Mon, Feb 19, 2018 at 09:57:35PM +0100, Hendrik Leppkes wrote:  
 On Mon, Feb 19, 2018 at 8:30 PM, Michael Niedermayer
  wrote:  
> On Sun, Feb 18, 2018 at 05:58:16PM +, Josh de Kock wrote:  
>> This should be the last of the major API changes. I'm not entirely
>> sure if I missed anything.  
>
> Moving from a register based system where a user app can register
> any subset to a system which registers all via an array will
> increase the size of statically linked binaries for users only
> using a subset.
>  

 User apps did not have the ability to register a subset. How would
 they do that? They can't access the internals (ie. the ff_ references
 to those components)  
>>>
>>> I think you are mistaken here.
>>>
>>> What you are thinking of here, i think is, that ff_* symbols are not
>>> accessable to user apps. This is true with shared libs but the issue
>>> above is primarely an issue with static linking. There the ff_* symbols
>>> are available.
>>>
>>> But much more important, we are designing a new API here, it doesnt matter
>>> all that much what was possible, what matters is that it IS possible
>>> and its IMHO not a obscure use case to want to only "register" parts that 
>>> are
>>> actually needed. Every security concious application that deals with
>>> some standarized input from the net, like a browser, would IMHO want to
>>> limit the parts that are enabled by as many and as hard ways as possible.
>>>
>>>   
 That was only something some internal tools used, and you can probably
 find different options for dealing with those.  
>>>
>>> I can imagine some ways to hack around it, for the fuzzer yes, but a
>>> clean way though proper public API (no ff_*, no #ifdefs around the array)
>>> would seem better
>>>
>>> So, yeah, i would prefer if a new API would allow registering subsets.
>>>
>>> Without this and if the fuzzer runs out of diskspace someone will probably
>>> need to hack around the new API so the arrays with all the pointers to
>>> every part arent linked in. I may be missing some solution but this
>>> sounds like a bunch of ugly code ...  
>>
>> Afaik, the objective of this new API was to make the modules const and
>> not mutable during init/registration by the requirement of setting the
>> *next pointer.
>> Admittedly, by keeping the init_static feature that can also set fields
>> like pix_fmt or change reported capabilities, the benefits from this new
>> API are more or less nullified.
> 
> That doesn't even affect filters. The pix_fmt thing affects only less
> than 5 codecs.
> 
>> So i agree with you that, seeing the drawbacks this new API introduced
>> without having actually achieved its objective, a different, better one
>> that allows "registration", the modules to be const while setting at
>> least some subset of capabilities based on the runtime environment
>> (things like enabled pix_fmts, codec capabilities and such) should be
>> written instead.
> 
> It has fully achieved its objectives. There's no more visible global
> mutable state, and the actual global mutable state has been reduced to
> less than 5 codec entries.

It's true that after the deprecation period they will effectively be the
only ones still mutable, but shouldn't the objective be to cover them all?

> 
> Why are we discussing this _again_?

Because a drawback has been found, namely that link time optimization
using static libraries can't remove "non registered" modules anymore,
and now depends fully on what's enabled at configure time.
Ideally, a better registration based API that follows what i described
above should be designed with care.

> 
>> Whatever is done, in any case, should be decided fast. The current new
>> API is in the tree and should be removed without delay if we decide to
>> not use it in the end, even if a proper replacement is not written in
>> the short term.
> 
> What needs to be done is testing and applying these patches.

What makes me uneasy is that if this API remains is place, introducing a
new better one would be annoying for downstream users if it's added too
close to the end of the old API's deprecation period, be it before or
after. Having to migrate a second time in a short time frame is undesirable.

In any case, just my two cents. Don't take this as a blocker for this
set, but as a request to consider better alternatives in the short or
long term.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] segment: Create missing directories

[Ricardo Constantino]

On 20 February 2018 at 11:17, Georgi Chorbadzhiyski  wrote:

> The attached patch allows segment muxer to be used for file archiving by
> allowing it to automatically create the output directories. For example the
> following should work as expected:
>
> ffmpeg
>   ...input_params...
>   -f segment \
>  -segment_atclocktime 1 \
>  -segment_time 5 \
>  -write_empty_segments 1 \
>  -segment_format_options movflags=+faststart \
>  -strftime 1 output_directory/mychannel/%Y/
> %m/%d/%H/%M/mychannel-%s-%Y%m%d-%H%M%S.mp4
>
> The patch is against ffmpeg-3.3.6
>
>
Patches should be made for git master, not old releases.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] segment: Create missing directories

[Georgi Chorbadzhiyski]

The attached patch allows segment muxer to be used for file archiving by
allowing it to automatically create the output directories. For example the
following should work as expected:

ffmpeg
  ...input_params...
  -f segment \
 -segment_atclocktime 1 \
 -segment_time 5 \
 -write_empty_segments 1 \
 -segment_format_options movflags=+faststart \
 -strftime 1 
output_directory/mychannel/%Y/%m/%d/%H/%M/mychannel-%s-%Y%m%d-%H%M%S.mp4

The patch is against ffmpeg-3.3.6

-- 
Georgi Chorbadzhiyski | http://georgi.unixsol.org/ | http://github.com/gfto/
From d3ba01f86900f3eae2bc4308a62d8c7c43c145c6 Mon Sep 17 00:00:00 2001
From: Georgi Chorbadzhiyski 
Date: Sun, 18 Feb 2018 18:10:33 +0200
Subject: [PATCH] segment: Create missing directories

---
 libavformat/segment.c | 54 +++
 1 file changed, 54 insertions(+)

diff --git a/libavformat/segment.c b/libavformat/segment.c
index 8ec3653..2d90ef2 100644
--- a/libavformat/segment.c
+++ b/libavformat/segment.c
@@ -28,6 +28,7 @@
 
 #include 
 #include 
+#include 
 
 #include "avformat.h"
 #include "avio_internal.h"
@@ -226,6 +227,49 @@ static int set_segment_filename(AVFormatContext *s)
 return 0;
 }
 
+/* Note: This modifies *dir */
+static int create_dir(char *dir, mode_t mode) {
+int ret = 0;
+unsigned int i, dlen;
+/* Shortcut, there are no deep directories */
+if (strchr(dir, '/') == NULL)
+return mkdir(dir, mode);
+dlen = strlen(dir);
+/* Skip first char (it can be /) */
+for (i = 1; i < dlen; i++) {
+if (dir[i] != '/')
+continue;
+dir[i] = '\0';
+ret = mkdir(dir, mode);
+dir[i] = '/';
+if (ret < 0 && errno != EEXIST)
+goto OUT;
+}
+ret = mkdir(dir, mode);
+OUT:
+return ret;
+}
+
+static int segment_create_directory(AVFormatContext *oc, char *filename) {
+char *dir, *fname;
+/* Do nothing when the filename is URL */
+if (strstr(filename, "://") != NULL)
+return 0;
+fname = av_strdup(filename);
+if (!fname)
+return AVERROR(ENOMEM);
+dir = (char *)av_dirname(fname);
+if (access(dir, W_OK) != F_OK)
+av_log(oc, AV_LOG_INFO, "Create directory %s\n", dir);
+if (create_dir(dir, 0777) == -1 && errno != EEXIST) {
+av_log(oc, AV_LOG_ERROR, "Could not create directory %s\n", dir);
+av_free(fname);
+return AVERROR(errno);
+}
+av_free(fname);
+return 0;
+}
+
 static int segment_start(AVFormatContext *s, int write_header)
 {
 SegmentContext *seg = s->priv_data;
@@ -247,6 +291,9 @@ static int segment_start(AVFormatContext *s, int 
write_header)
 if ((err = set_segment_filename(s)) < 0)
 return err;
 
+if ((err = segment_create_directory(s, oc->filename)) < 0)
+return err;
+
 if ((err = s->io_open(s, >pb, oc->filename, AVIO_FLAG_WRITE, NULL)) < 
0) {
 av_log(s, AV_LOG_ERROR, "Failed to open segment '%s'\n", oc->filename);
 return err;
@@ -277,6 +324,10 @@ static int segment_list_open(AVFormatContext *s)
 int ret;
 
 snprintf(seg->temp_list_filename, sizeof(seg->temp_list_filename), 
seg->use_rename ? "%s.tmp" : "%s", seg->list);
+
+if ((ret = segment_create_directory(s, seg->temp_list_filename)) < 0)
+return ret;
+
 ret = s->io_open(s, >list_pb, seg->temp_list_filename, 
AVIO_FLAG_WRITE, NULL);
 if (ret < 0) {
 av_log(s, AV_LOG_ERROR, "Failed to open segment list '%s'\n", 
seg->list);
@@ -746,6 +797,9 @@ static int seg_init(AVFormatContext *s)
 oc = seg->avf;
 
 if (seg->write_header_trailer) {
+if ((ret = segment_create_directory(s, seg->header_filename ? 
seg->header_filename : oc->filename)) < 0)
+return ret;
+
 if ((ret = s->io_open(s, >pb,
   seg->header_filename ? seg->header_filename : 
oc->filename,
   AVIO_FLAG_WRITE, NULL)) < 0) {
-- 
2.9.0

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

[FFmpeg-devel] [PATCH] doc/filters: add links to ffmpeg-utils and ffmpeg documentation

[Tobias Rapp]

Signed-off-by: Tobias Rapp 
---
 doc/filters.texi | 48 ++--
 1 file changed, 26 insertions(+), 22 deletions(-)

diff --git a/doc/filters.texi b/doc/filters.texi
index bd93e0a..0f0ec10 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -1611,7 +1611,7 @@ The filter accepts the syntax
 [@var{sample_rate}:]@var{resampler_options}, where @var{sample_rate}
 expresses a sample rate and @var{resampler_options} is a list of
 @var{key}=@var{value} pairs, separated by ":". See the
-@ref{Resampler Options,,the "Resampler Options" section in the
+@ref{Resampler Options,,"Resampler Options" section in the
 ffmpeg-resampler(1) manual,ffmpeg-resampler}
 for the complete list of supported options.
 
@@ -7449,7 +7449,7 @@ the input width and height. It defaults to 0.
 
 @item color, c
 Specify the color of the box to write. For the general syntax of this option,
-check the "Color" section in the ffmpeg-utils manual. If the special
+check the @ref{color syntax,,"Color" section in the ffmpeg-utils 
manual,ffmpeg-utils}. If the special
 value @code{invert} is used, the box edge color is the same as the
 video with inverted luma.
 
@@ -7552,7 +7552,7 @@ framed. Default to 0.
 
 @item color, c
 Specify the color of the grid. For the general syntax of this option,
-check the "Color" section in the ffmpeg-utils manual. If the special
+check the @ref{color syntax,,"Color" section in the ffmpeg-utils 
manual,ffmpeg-utils}. If the special
 value @code{invert} is used, the grid color is the same as the
 video with inverted luma.
 
@@ -7648,7 +7648,7 @@ The default value of @var{boxborderw} is 0.
 
 @item boxcolor
 The color to be used for drawing box around text. For the syntax of this
-option, check the "Color" section in the ffmpeg-utils manual.
+option, check the @ref{color syntax,,"Color" section in the ffmpeg-utils 
manual,ffmpeg-utils}.
 
 The default value of @var{boxcolor} is "white".
 
@@ -7662,7 +7662,7 @@ The default value of @var{borderw} is 0.
 
 @item bordercolor
 Set the color to be used for drawing border around text. For the syntax of this
-option, check the "Color" section in the ffmpeg-utils manual.
+option, check the @ref{color syntax,,"Color" section in the ffmpeg-utils 
manual,ffmpeg-utils}.
 
 The default value of @var{bordercolor} is "black".
 
@@ -7683,7 +7683,7 @@ If true, check and fix text coords to avoid clipping.
 
 @item fontcolor
 The color to be used for drawing fonts. For the syntax of this option, check
-the "Color" section in the ffmpeg-utils manual.
+the @ref{color syntax,,"Color" section in the ffmpeg-utils 
manual,ffmpeg-utils}.
 
 The default value of @var{fontcolor} is "black".
 
@@ -7746,7 +7746,8 @@ libfreetype flags.
 
 @item shadowcolor
 The color to be used for drawing a shadow behind the drawn text. For the
-syntax of this option, check the "Color" section in the ffmpeg-utils manual.
+syntax of this option, check the @ref{color syntax,,"Color" section in the
+ffmpeg-utils manual,ffmpeg-utils}.
 
 The default value of @var{shadowcolor} is "black".
 
@@ -9322,8 +9323,9 @@ A '|'-separated list of parameters to pass to the frei0r 
effect.
 A frei0r effect parameter can be a boolean (its value is either
 "y" or "n"), a double, a color (specified as
 @var{R}/@var{G}/@var{B}, where @var{R}, @var{G}, and @var{B} are floating point
-numbers between 0.0 and 1.0, inclusive) or by a color description specified in 
the "Color"
-section in the ffmpeg-utils manual), a position (specified as @var{X}/@var{Y}, 
where
+numbers between 0.0 and 1.0, inclusive) or by a color description specified in 
the
+@ref{color syntax,,"Color" section in the ffmpeg-utils manual,ffmpeg-utils}),
+a position (specified as @var{X}/@var{Y}, where
 @var{X} and @var{Y} are floating point numbers) and/or a string.
 
 The number and types of parameters depend on the loaded effect. If an
@@ -11881,7 +11883,8 @@ so the input image is centered on the padded area.
 
 @item color
 Specify the color of the padded area. For the syntax of this option,
-check the "Color" section in the ffmpeg-utils manual.
+check the @ref{color syntax,,"Color" section in the ffmpeg-utils
+manual,ffmpeg-utils}.
 
 The default value of @var{color} is "black".
 
@@ -13273,8 +13276,9 @@ it. Default value is 1.
 
 @item fillcolor, c
 Set the color used to fill the output area not covered by the rotated
-image. For the general syntax of this option, check the "Color" section in the
-ffmpeg-utils manual. If the special value "none" is selected then no
+image. For the general syntax of this option, check the
+@ref{color syntax,,"Color" section in the ffmpeg-utils manual,ffmpeg-utils}.
+If the special value "none" is selected then no
 background is printed (useful for example if the background is never shown).
 
 Default value is "black".
@@ -15143,8 +15147,8 @@ refer to the pad video filter.
 
 @item color
 Specify the color of the unused area. For the syntax of this option, check the

Re: [FFmpeg-devel] [PATCH] Add android_capture indev

[Felix Matouschek]

I rebased the patch on the current master, it does apply again.

Tested it - still works.

Felix

Am 19.02.2018 20:39, schrieb Michael Niedermayer:

On Mon, Feb 19, 2018 at 08:39:56AM +0100, Felix Matouschek wrote:

Hello Michael,

do you think the patch could be merged in its current state?
It is functional, maybe I can do the cosmetic changes later.
I was a bit busy the last weeks.

Would be nice if it could get into the 3.5 / 4.0 release.


not sure if there are issues remaining but it doesnt apply
anymore

Applying: avdevice: add android_camera indev
Using index info to reconstruct a base tree...
M   Changelog
M   MAINTAINERS
M   configure
M   doc/indevs.texi
M   libavdevice/alldevices.c
M   libavdevice/version.h
Falling back to patching base and 3-way merge...
Auto-merging libavdevice/alldevices.c
CONFLICT (content): Merge conflict in libavdevice/alldevices.c
Auto-merging doc/indevs.texi
Auto-merging configure
Auto-merging MAINTAINERS
Auto-merging Changelog
CONFLICT (content): Merge conflict in Changelog
error: Failed to merge in the changes.
Patch failed at 0001 avdevice: add android_camera indev
The copy of the patch that failed is found in: .git/rebase-apply/patch
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".


[...]
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-develFrom 3fd6cca01f175412ee3cb2c4e435694ed3cf2bb0 Mon Sep 17 00:00:00 2001
From: Felix Matouschek 
Date: Tue, 20 Feb 2018 09:41:46 +0100
Subject: [PATCH] avdevice: add android_camera indev
To: ffmpeg-devel@ffmpeg.org

This commit adds an indev for Android devices on API level 24+ which
uses the Android NDK Camera2 API to capture video from builtin cameras

Signed-off-by: Felix Matouschek 
---
 Changelog|   1 +
 MAINTAINERS  |   1 +
 configure|   6 +
 doc/indevs.texi  |  40 ++
 libavdevice/Makefile |   1 +
 libavdevice/alldevices.c |   1 +
 libavdevice/android_camera.c | 871 +++
 libavdevice/version.h|   2 +-
 8 files changed, 922 insertions(+), 1 deletion(-)
 create mode 100644 libavdevice/android_camera.c

diff --git a/Changelog b/Changelog
index 2acdbbea30..56dedd1aea 100644
--- a/Changelog
+++ b/Changelog
@@ -39,6 +39,7 @@ version :
 - Removed the ffmenc and ffmdec muxer and demuxer
 - VideoToolbox HEVC encoder and hwaccel
 - VAAPI-accelerated ProcAmp (color balance), denoise and sharpness filters
+- Add android_camera indev
 
 
 version 3.4:
diff --git a/MAINTAINERS b/MAINTAINERS
index b691bd56ec..bf1299bdbf 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -281,6 +281,7 @@ libavdevice
 
 
   avfoundation.mThilo Borgmann
+  android_camera.c  Felix Matouschek
   decklink* Marton Balint
   dshow.c   Roger Pack (CC rogerdp...@gmail.com)
   fbdev_enc.c   Lukasz Marek
diff --git a/configure b/configure
index 013308cfa4..fa5c530abe 100755
--- a/configure
+++ b/configure
@@ -3081,6 +3081,8 @@ xmv_demuxer_select="riffdec"
 xwma_demuxer_select="riffdec"
 
 # indevs / outdevs
+android_camera_indev_deps="android camera2ndk mediandk pthreads"
+android_camera_indev_extralibs="-landroid -lcamera2ndk -lmediandk"
 alsa_indev_deps="alsa"
 alsa_outdev_deps="alsa"
 avfoundation_indev_deps="avfoundation corevideo coremedia pthreads"
@@ -5756,6 +5758,10 @@ check_lib shell32  "windows.h shellapi.h" CommandLineToArgvW   -lshell32
 check_lib wincrypt "windows.h wincrypt.h" CryptGenRandom   -ladvapi32
 check_lib psapi"windows.h psapi.h"GetProcessMemoryInfo -lpsapi
 
+check_lib android android/native_window.h ANativeWindow_acquire -landroid
+check_lib mediandk "stdint.h media/NdkImage.h" AImage_delete -lmediandk
+check_lib camera2ndk "stdbool.h stdint.h camera/NdkCameraManager.h" ACameraManager_create -lcamera2ndk
+
 enabled appkit   && check_apple_framework AppKit
 enabled audiotoolbox && check_apple_framework AudioToolbox
 enabled avfoundation && check_apple_framework AVFoundation
diff --git a/doc/indevs.texi b/doc/indevs.texi
index 0bc8e6a9b1..6951940a93 100644
--- a/doc/indevs.texi
+++ b/doc/indevs.texi
@@ -63,6 +63,46 @@ Set the number of channels. Default is 2.
 
 @end table
 
+@section android_camera
+
+Android camera input device.
+
+This input devices uses the Android Camera2 NDK API which is
+available on devices with API level 24+. The availability of
+android_camera is autodetected during configuration.
+
+This device allows capturing from all cameras on an Android device,
+which are integrated into the Camera2 NDK API.
+
+The available cameras are enumerated internally and can be