[FFmpeg-devel] [PATCH] avfilter/swaprect: correct assignment of VAR_POS

2020-01-15 Thread Gyan Doshi
Revert regression introduced in 6af050d7d0
---
 libavfilter/vf_swaprect.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavfilter/vf_swaprect.c b/libavfilter/vf_swaprect.c
index f1fab1e36d..cf9c298f2f 100644
--- a/libavfilter/vf_swaprect.c
+++ b/libavfilter/vf_swaprect.c
@@ -99,7 +99,7 @@ static int filter_frame(AVFilterLink *inlink, AVFrame *in)
 var_values[VAR_DAR] = var_values[VAR_A] * var_values[VAR_SAR];
 var_values[VAR_N]   = inlink->frame_count_out;
 var_values[VAR_T]   = in->pts == AV_NOPTS_VALUE ? NAN : in->pts * 
av_q2d(inlink->time_base);
-var_values[VAR_POS] = in->pkt_pos ? NAN : in->pkt_pos;
+var_values[VAR_POS] = in->pkt_pos == -1 ? NAN : in->pkt_pos;
 
 ret = av_expr_parse_and_eval(&dw, s->w,
  var_names, &var_values[0],
-- 
2.24.1

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

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

Re: [FFmpeg-devel] [PATCH] avfilter/swaprect: correct assignment of VAR_POS

2020-01-15 Thread Paul B Mahol
LGTM

On 1/15/20, Gyan Doshi  wrote:
> Revert regression introduced in 6af050d7d0
> ---
>  libavfilter/vf_swaprect.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavfilter/vf_swaprect.c b/libavfilter/vf_swaprect.c
> index f1fab1e36d..cf9c298f2f 100644
> --- a/libavfilter/vf_swaprect.c
> +++ b/libavfilter/vf_swaprect.c
> @@ -99,7 +99,7 @@ static int filter_frame(AVFilterLink *inlink, AVFrame *in)
>  var_values[VAR_DAR] = var_values[VAR_A] * var_values[VAR_SAR];
>  var_values[VAR_N]   = inlink->frame_count_out;
>  var_values[VAR_T]   = in->pts == AV_NOPTS_VALUE ? NAN : in->pts *
> av_q2d(inlink->time_base);
> -var_values[VAR_POS] = in->pkt_pos ? NAN : in->pkt_pos;
> +var_values[VAR_POS] = in->pkt_pos == -1 ? NAN : in->pkt_pos;
>
>  ret = av_expr_parse_and_eval(&dw, s->w,
>   var_names, &var_values[0],
> --
> 2.24.1
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [PATCH] avfilter/swaprect: correct assignment of VAR_POS

2020-01-15 Thread Gyan



On 15-01-2020 02:18 pm, Paul B Mahol wrote:

LGTM


Pushed to 0777b197c57eebb4e2367932fa44021577ab5237

Thanks,
Gyan



On 1/15/20, Gyan Doshi  wrote:

Revert regression introduced in 6af050d7d0
---
  libavfilter/vf_swaprect.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavfilter/vf_swaprect.c b/libavfilter/vf_swaprect.c
index f1fab1e36d..cf9c298f2f 100644
--- a/libavfilter/vf_swaprect.c
+++ b/libavfilter/vf_swaprect.c
@@ -99,7 +99,7 @@ static int filter_frame(AVFilterLink *inlink, AVFrame *in)
  var_values[VAR_DAR] = var_values[VAR_A] * var_values[VAR_SAR];
  var_values[VAR_N]   = inlink->frame_count_out;
  var_values[VAR_T]   = in->pts == AV_NOPTS_VALUE ? NAN : in->pts *
av_q2d(inlink->time_base);
-var_values[VAR_POS] = in->pkt_pos ? NAN : in->pkt_pos;
+var_values[VAR_POS] = in->pkt_pos == -1 ? NAN : in->pkt_pos;

  ret = av_expr_parse_and_eval(&dw, s->w,
   var_names, &var_values[0],
--
2.24.1

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

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

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

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


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

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

[FFmpeg-devel] [PATCH v2] HEVC: Export motion vectors to frame side data.

2020-01-15 Thread Asaf Kave
---
 libavcodec/hevc_refs.c |  15 
 libavcodec/hevcdec.c   | 179 -
 libavcodec/hevcdec.h   |  13 +++
 3 files changed, 206 insertions(+), 1 deletion(-)

diff --git a/libavcodec/hevc_refs.c b/libavcodec/hevc_refs.c
index 7870a72fd6..20f028fa73 100644
--- a/libavcodec/hevc_refs.c
+++ b/libavcodec/hevc_refs.c
@@ -42,6 +42,9 @@ void ff_hevc_unref_frame(HEVCContext *s, HEVCFrame *frame, 
int flags)
 av_buffer_unref(&frame->tab_mvf_buf);
 frame->tab_mvf = NULL;
 
+av_buffer_unref(&frame->cuh_buf);
+frame->cuh = NULL;
+
 av_buffer_unref(&frame->rpl_buf);
 av_buffer_unref(&frame->rpl_tab_buf);
 frame->rpl_tab= NULL;
@@ -101,11 +104,17 @@ static HEVCFrame *alloc_frame(HEVCContext *s)
 goto fail;
 frame->tab_mvf = (MvField *)frame->tab_mvf_buf->data;
 
+frame->cuh_buf = av_buffer_pool_get(s->cuh_pool);
+if (!frame->cuh_buf)
+goto fail;
+frame->cuh = (CodingUnitHelper *)frame->cuh_buf->data;
+
 frame->rpl_tab_buf = av_buffer_pool_get(s->rpl_tab_pool);
 if (!frame->rpl_tab_buf)
 goto fail;
 frame->rpl_tab   = (RefPicListTab **)frame->rpl_tab_buf->data;
 frame->ctb_count = s->ps.sps->ctb_width * s->ps.sps->ctb_height;
+frame->cu_count = 0;
 for (j = 0; j < frame->ctb_count; j++)
 frame->rpl_tab[j] = (RefPicListTab *)frame->rpl_buf->data;
 
@@ -161,6 +170,10 @@ int ff_hevc_set_new_ref(HEVCContext *s, AVFrame **frame, 
int poc)
 else
 ref->flags = HEVC_FRAME_FLAG_SHORT_REF;
 
+if (s->avctx->flags2 & AV_CODEC_FLAG2_EXPORT_MVS) {
+ref->flags |= HEVC_FRAME_FLAG_MV;
+}
+
 ref->poc  = poc;
 ref->sequence = s->seq_decode;
 ref->frame->crop_left   = s->ps.sps->output_window.left_offset;
@@ -216,6 +229,8 @@ int ff_hevc_output_frame(HEVCContext *s, AVFrame *out, int 
flush)
 if (ret < 0)
 return ret;
 
+s->output_frame_poc = frame->poc;
+
 av_log(s->avctx, AV_LOG_DEBUG,
"Output frame with POC %d.\n", frame->poc);
 return 1;
diff --git a/libavcodec/hevcdec.c b/libavcodec/hevcdec.c
index 19b0cd815d..367745c6ee 100644
--- a/libavcodec/hevcdec.c
+++ b/libavcodec/hevcdec.c
@@ -32,6 +32,7 @@
 #include "libavutil/opt.h"
 #include "libavutil/pixdesc.h"
 #include "libavutil/stereo3d.h"
+#include "libavutil/motion_vector.h"
 
 #include "bswapdsp.h"
 #include "bytestream.h"
@@ -80,6 +81,7 @@ static void pic_arrays_free(HEVCContext *s)
 av_freep(&s->sh.offset);
 
 av_buffer_pool_uninit(&s->tab_mvf_pool);
+av_buffer_pool_uninit(&s->cuh_pool);
 av_buffer_pool_uninit(&s->rpl_tab_pool);
 }
 
@@ -128,9 +130,11 @@ static int pic_arrays_init(HEVCContext *s, const HEVCSPS 
*sps)
 
 s->tab_mvf_pool = av_buffer_pool_init(min_pu_size * sizeof(MvField),
   av_buffer_allocz);
+s->cuh_pool = av_buffer_pool_init(min_pu_size * sizeof(CodingUnitHelper),
+  av_buffer_allocz);
 s->rpl_tab_pool = av_buffer_pool_init(ctb_count * sizeof(RefPicListTab),
   av_buffer_allocz);
-if (!s->tab_mvf_pool || !s->rpl_tab_pool)
+if (!s->tab_mvf_pool || !s->rpl_tab_pool || !s->cuh_pool)
 goto fail;
 
 return 0;
@@ -1806,6 +1810,7 @@ static void hls_prediction_unit(HEVCContext *s, int x0, 
int y0,
 int min_pu_width = s->ps.sps->min_pu_width;
 
 MvField *tab_mvf = s->ref->tab_mvf;
+CodingUnitHelper *cuh = s->ref->cuh;
 RefPicList  *refPicList = s->ref->refPicList;
 HEVCFrame *ref0 = NULL, *ref1 = NULL;
 uint8_t *dst0 = POS(0, x0, y0);
@@ -1843,6 +1848,10 @@ static void hls_prediction_unit(HEVCContext *s, int x0, 
int y0,
 for (i = 0; i < nPbW >> s->ps.sps->log2_min_pu_size; i++)
 tab_mvf[(y_pu + j) * min_pu_width + x_pu + i] = current_mv;
 
+cuh[s->ref->cu_count].cu = lc->cu;
+cuh[s->ref->cu_count].log2_cu_size = log2_cb_size;
+s->ref->cu_count++;
+
 if (current_mv.pred_flag & PF_L0) {
 ref0 = refPicList[0].ref[current_mv.ref_idx[0]];
 if (!ref0)
@@ -3192,6 +3201,163 @@ static int hevc_decode_extradata(HEVCContext *s, 
uint8_t *buf, int length, int f
 return 0;
 }
 
+static int set_mv(AVMotionVector *mv, int puW, int puH,
+  int dst_x, int dst_y,
+  int motion_x, int motion_y, int motion_scale,
+  int direction)
+{
+mv->w = puW;
+mv->h = puH;
+mv->motion_x = motion_x;
+mv->motion_y = motion_y;
+mv->motion_scale = motion_scale;
+mv->dst_x = dst_x;
+mv->dst_y = dst_y;
+mv->src_x = dst_x + motion_x / motion_scale;
+mv->src_y = dst_y + motion_y / motion_scale;
+mv->source = direction ? 1 : -1;
+mv->flags = 0;
+
+return 1;
+}
+
+static int add_mv(HEVCContext *s, AVMotionVector *mvs, MvField c

[FFmpeg-devel] [PATCH v2 0/8] avformat: Use s337m subdemux inside wav

2020-01-15 Thread Nicolas Gaullier
Many things have been reviewed. Updates :

patch 2 : tomas : updated copyright, moved s337m_read_packet to static
patch 3 : tomas : revised 3 cases checking of container_word_bits vs word_bits
patch 4 : carl : removed av_log during probing
fix 2nd sample check
(robustness) requires 3 samples instead of 2, checks container s337 word 
alignment
patch 5 : tomas : merged with "fix 337m last packet parsing"
carl : removed the AVOption

I will still have 2 more patchs to do :
 - a second test asked by Tomas
 - a global AVOption to disable all codecs autodetection mechanism as discussed 
with Carl Eugen

If possible, I would like to continue this review, but when time will come to 
apply,
I would like to postpone it a little bit to wait for the global AVOption, this 
is to make
sure that users will be able to disable the wav s337m probing if they need to.

Thank you all

Nicolas Gaullier (8):
  avformat/s337m: Use base AVClass for av_log usage
  avformat/s337m: Split read_packet/get_packet
  avformat/s337m: Consider container bit resolution
  avformat/s337m: New ff_s337m_probe()
  avformat/wavdec: s337m support
  avformat/wavdec.c: Reindent after last commit
  avformat/wavdec: fix s337m/spdif probing beyond data_end
  avformat/wavdec: Test s337m

 libavformat/s337m.c  | 82 +++-
 libavformat/s337m.h  | 54 ++
 libavformat/wavdec.c | 39 +
 tests/Makefile   |  1 +
 tests/fate/audio.mak |  5 
 5 files changed, 155 insertions(+), 26 deletions(-)
 create mode 100644 libavformat/s337m.h

-- 
2.14.1.windows.1

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

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

[FFmpeg-devel] [PATCH v2 8/8] avformat/wavdec: Test s337m

2020-01-15 Thread Nicolas Gaullier
Test s337m probing in wav container.
Test dolby_e decoding for 24 bits with program config '5.1+2'
---
 tests/Makefile   | 1 +
 tests/fate/audio.mak | 5 +
 2 files changed, 6 insertions(+)

diff --git a/tests/Makefile b/tests/Makefile
index e5f41008d4..65cccac312 100644
--- a/tests/Makefile
+++ b/tests/Makefile
@@ -75,6 +75,7 @@ ENCDEC2 = $(call ALLYES, $(firstword $(1))_ENCODER $(lastword 
$(1))_DECODER  \
  $(firstword $(3))_MUXER   $(lastword $(3))_DEMUXER)
 
 DEMDEC  = $(call ALLYES, $(1)_DEMUXER $(2:%=%_DECODER))
+DEMDEMDEC  = $(call ALLYES, $(1)_DEMUXER $(2)_DEMUXER $(3:%=%_DECODER))
 ENCMUX  = $(call ALLYES, $(1:%=%_ENCODER) $(2)_MUXER)
 
 DEMMUX  = $(call ALLYES, $(1)_DEMUXER $(2)_MUXER)
diff --git a/tests/fate/audio.mak b/tests/fate/audio.mak
index c41958ea2d..2110b3c674 100644
--- a/tests/fate/audio.mak
+++ b/tests/fate/audio.mak
@@ -24,6 +24,11 @@ fate-dolby-e: CMD = pcm -i $(TARGET_SAMPLES)/dolby_e/16-11
 fate-dolby-e: CMP = oneoff
 fate-dolby-e: REF = $(SAMPLES)/dolby_e/16-11.pcm
 
+FATE_SAMPLES_AUDIO-$(call DEMDEMDEC, WAV, S337M, DOLBY_E) += fate-dolby-e-wav
+fate-dolby-e-wav: CMD = pcm -i $(TARGET_SAMPLES)/dolby_e/512.wav
+fate-dolby-e-wav: CMP = oneoff
+fate-dolby-e-wav: REF = $(SAMPLES)/dolby_e/512.wav.pcm
+
 FATE_SAMPLES_AUDIO-$(call DEMDEC, DSS, DSS_SP) += fate-dss-lp fate-dss-sp
 fate-dss-lp: CMD = framecrc -i $(TARGET_SAMPLES)/dss/lp.dss -frames 30
 fate-dss-sp: CMD = framecrc -i $(TARGET_SAMPLES)/dss/sp.dss -frames 30
-- 
2.14.1.windows.1

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

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

[FFmpeg-devel] [PATCH v2 7/8] avformat/wavdec: fix s337m/spdif probing beyond data_end

2020-01-15 Thread Nicolas Gaullier
---
 libavformat/wavdec.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavformat/wavdec.c b/libavformat/wavdec.c
index 3571733817..d8a27c79cf 100644
--- a/libavformat/wavdec.c
+++ b/libavformat/wavdec.c
@@ -77,7 +77,7 @@ static void set_spdif_s337m(AVFormatContext *s, 
WAVDemuxContext *wav)
 ret = AVERROR(ENOMEM);
 } else {
 int64_t pos = avio_tell(s->pb);
-len = ret = avio_read(s->pb, buf, len);
+len = ret = avio_read(s->pb, buf, FFMIN(len, wav->data_end - 
pos));
 if (len >= 0) {
 ret = ff_spdif_probe(buf, len, &codec);
 if (ret > AVPROBE_SCORE_EXTENSION) {
-- 
2.14.1.windows.1

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

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

[FFmpeg-devel] [PATCH v2 5/8] avformat/wavdec: s337m support

2020-01-15 Thread Nicolas Gaullier
Add s337m probing/reading similarly to spdif.
---
 libavformat/wavdec.c | 23 +++
 1 file changed, 19 insertions(+), 4 deletions(-)

diff --git a/libavformat/wavdec.c b/libavformat/wavdec.c
index 575c667452..d030ed9f9d 100644
--- a/libavformat/wavdec.c
+++ b/libavformat/wavdec.c
@@ -41,6 +41,7 @@
 #include "riff.h"
 #include "w64.h"
 #include "spdif.h"
+#include "s337m.h"
 
 typedef struct WAVDemuxContext {
 const AVClass *class;
@@ -55,15 +56,17 @@ typedef struct WAVDemuxContext {
 int audio_eof;
 int ignore_length;
 int spdif;
+int s337m;
 int smv_cur_pt;
 int smv_given_first;
 int unaligned; // e.g. if an odd number of bytes ID3 tag was prepended
 int rifx; // RIFX: integer byte order for parameters is big endian
 } WAVDemuxContext;
 
-static void set_spdif(AVFormatContext *s, WAVDemuxContext *wav)
+static void set_spdif_s337m(AVFormatContext *s, WAVDemuxContext *wav)
 {
-if (CONFIG_SPDIF_DEMUXER && s->streams[0]->codecpar->codec_tag == 1) {
+AVCodecParameters *par = s->streams[0]->codecpar;
+if ((CONFIG_SPDIF_DEMUXER || CONFIG_S337M_DEMUXER) && par->codec_tag == 1) 
{
 enum AVCodecID codec;
 int len = 1<<16;
 int ret = ffio_ensure_seekback(s->pb, len);
@@ -80,6 +83,12 @@ static void set_spdif(AVFormatContext *s, WAVDemuxContext 
*wav)
 if (ret > AVPROBE_SCORE_EXTENSION) {
 s->streams[0]->codecpar->codec_id = codec;
 wav->spdif = 1;
+} else if ((par->codec_id == AV_CODEC_ID_PCM_S16LE || 
par->codec_id == AV_CODEC_ID_PCM_S24LE) && par->channels == 2) {
+ret = ff_s337m_probe(buf, len, &codec, 
par->bits_per_coded_sample);
+if (ret > AVPROBE_SCORE_EXTENSION) {
+s->streams[0]->codecpar->codec_id = codec;
+wav->s337m = 1;
+}
 }
 }
 avio_seek(s->pb, pos, SEEK_SET);
@@ -596,7 +605,7 @@ break_loop:
 ff_metadata_conv_ctx(s, NULL, wav_metadata_conv);
 ff_metadata_conv_ctx(s, NULL, ff_riff_info_conv);
 
-set_spdif(s, wav);
+set_spdif_s337m(s, wav);
 
 return 0;
 }
@@ -700,6 +709,10 @@ smv_out:
 wav->data_end = avio_tell(s->pb) + left;
 }
 
+if (CONFIG_S337M_DEMUXER && wav->s337m == 1) {
+size = FFMIN(S337M_MAX_OFFSET, left);
+ret  = ff_s337m_get_packet(s->pb, pkt, size, NULL, s, 
st->codecpar->bits_per_coded_sample);
+} else {
 size = MAX_SIZE;
 if (st->codecpar->block_align > 1) {
 if (size < st->codecpar->block_align)
@@ -708,6 +721,8 @@ smv_out:
 }
 size = FFMIN(size, left);
 ret  = av_get_packet(s->pb, pkt, size);
+}
+
 if (ret < 0)
 return ret;
 pkt->stream_index = 0;
@@ -895,7 +910,7 @@ static int w64_read_header(AVFormatContext *s)
 
 avio_seek(pb, data_ofs, SEEK_SET);
 
-set_spdif(s, wav);
+set_spdif_s337m(s, wav);
 
 return 0;
 }
-- 
2.14.1.windows.1

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

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

[FFmpeg-devel] [PATCH v2 1/8] avformat/s337m: Use base AVClass for av_log usage

2020-01-15 Thread Nicolas Gaullier
s337m_get_offset_and_codec does not make use of
AVFormatContext: AVClass is enough for logging.
Will facilitate further use from outside
---
 libavformat/s337m.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/libavformat/s337m.c b/libavformat/s337m.c
index 48ab66a6da..8956afb23f 100644
--- a/libavformat/s337m.c
+++ b/libavformat/s337m.c
@@ -31,7 +31,7 @@
 #define IS_24LE_MARKER(state)   ((state & 0x) == MARKER_24LE)
 #define IS_LE_MARKER(state) (IS_16LE_MARKER(state) || 
IS_20LE_MARKER(state) || IS_24LE_MARKER(state))
 
-static int s337m_get_offset_and_codec(AVFormatContext *s,
+static int s337m_get_offset_and_codec(void *avc,
   uint64_t state,
   int data_type, int data_size,
   int *offset, enum AVCodecID *codec)
@@ -50,8 +50,8 @@ static int s337m_get_offset_and_codec(AVFormatContext *s,
 }
 
 if ((data_type & 0x1F) != 0x1C) {
-if (s)
-avpriv_report_missing_feature(s, "Data type %#x in SMPTE 337M", 
data_type & 0x1F);
+if (avc)
+avpriv_report_missing_feature(avc, "Data type %#x in SMPTE 337M", 
data_type & 0x1F);
 return AVERROR_PATCHWELCOME;
 }
 
@@ -72,8 +72,8 @@ static int s337m_get_offset_and_codec(AVFormatContext *s,
 *offset = 1601;
 break;
 default:
-if (s)
-avpriv_report_missing_feature(s, "Dolby E data size %d in SMPTE 
337M", data_size);
+if (avc)
+avpriv_report_missing_feature(avc, "Dolby E data size %d in SMPTE 
337M", data_size);
 return AVERROR_PATCHWELCOME;
 }
 
-- 
2.14.1.windows.1

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

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

[FFmpeg-devel] [PATCH v2 2/8] avformat/s337m: Split read_packet/get_packet

2020-01-15 Thread Nicolas Gaullier
Prepare use of s337m_get_packet from outside.
---
 libavformat/s337m.c | 26 --
 libavformat/s337m.h | 37 +
 2 files changed, 57 insertions(+), 6 deletions(-)
 create mode 100644 libavformat/s337m.h

diff --git a/libavformat/s337m.c b/libavformat/s337m.c
index 8956afb23f..9776cf1bf1 100644
--- a/libavformat/s337m.c
+++ b/libavformat/s337m.c
@@ -21,6 +21,7 @@
 #include "libavutil/intreadwrite.h"
 #include "avformat.h"
 #include "spdif.h"
+#include "s337m.h"
 
 #define MARKER_16LE 0x72F81F4E
 #define MARKER_20LE 0x20876FF0E154
@@ -141,18 +142,20 @@ static void bswap_buf24(uint8_t *data, int size)
 FFSWAP(uint8_t, data[0], data[2]);
 }
 
-static int s337m_read_packet(AVFormatContext *s, AVPacket *pkt)
+int ff_s337m_get_packet(AVIOContext *pb, AVPacket *pkt, int size, enum 
AVCodecID *codec, void *avc)
 {
-AVIOContext *pb = s->pb;
 uint64_t state = 0;
 int ret, data_type, data_size, offset;
-enum AVCodecID codec;
-int64_t pos;
+int64_t pos, orig_pos = avio_tell(pb);
 
 while (!IS_LE_MARKER(state)) {
 state = (state << 8) | avio_r8(pb);
 if (avio_feof(pb))
 return AVERROR_EOF;
+if (avio_tell(pb) - orig_pos + 6 >= size) {
+av_log(avc, AV_LOG_ERROR, "s337m : sync bytes not found at packet 
pos=0x%"PRIx64" size=%d\n", orig_pos, size);
+return AVERROR_INVALIDDATA;
+}
 }
 
 if (IS_16LE_MARKER(state)) {
@@ -165,10 +168,10 @@ static int s337m_read_packet(AVFormatContext *s, AVPacket 
*pkt)
 
 pos = avio_tell(pb);
 
-if ((ret = s337m_get_offset_and_codec(s, state, data_type, data_size, 
&offset, &codec)) < 0)
+if ((ret = s337m_get_offset_and_codec(avc, state, data_type, data_size, 
&offset, codec)) < 0)
 return ret;
 
-if ((ret = av_new_packet(pkt, offset)) < 0)
+if (ret = av_new_packet(pkt, FFMIN(offset, size - (pos - orig_pos))) < 0)
 return ret;
 
 pkt->pos = pos;
@@ -183,6 +186,17 @@ static int s337m_read_packet(AVFormatContext *s, AVPacket 
*pkt)
 else
 bswap_buf24(pkt->data, pkt->size);
 
+return 0;
+}
+
+static int s337m_read_packet(AVFormatContext *s, AVPacket *pkt)
+{
+enum AVCodecID codec;
+int ret;
+
+if ((ret = ff_s337m_get_packet(s->pb, pkt, avio_size(s->pb), &codec, s)) < 
0)
+return ret;
+
 if (!s->nb_streams) {
 AVStream *st = avformat_new_stream(s, NULL);
 if (!st) {
diff --git a/libavformat/s337m.h b/libavformat/s337m.h
new file mode 100644
index 00..f7bd0c16f6
--- /dev/null
+++ b/libavformat/s337m.h
@@ -0,0 +1,37 @@
+/*
+ * SMPTE ST 337 common header
+ *
+ * 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
+ */
+
+#ifndef AVFORMAT_S337M_H
+#define AVFORMAT_S337M_H
+
+/**
+ * Read s337m packets in a PCM_S16LE/S24LE stereo stream
+ * Returns the first inner packet found
+ * Note that it does not require a clean guard band
+ * @param pb Associated IO context
+ * @param pkt On success, returns a DOLBY E packet
+ * @param size Maximum IO read size available for reading at current position
+ * @param codec Returns AV_CODEC_ID_DOLBY_E
+ * @param avc For av_log
+ * @return = 0 on success (an error is raised if no s337m was found)
+ */
+int ff_s337m_get_packet(AVIOContext *pb, AVPacket *pkt, int size, enum 
AVCodecID *codec, void *avc);
+
+#endif /* AVFORMAT_S337M_H */
-- 
2.14.1.windows.1

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

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

[FFmpeg-devel] [PATCH v2 3/8] avformat/s337m: Consider container bit resolution

2020-01-15 Thread Nicolas Gaullier
Prepare the support of s337m in muxers other than raw (ex: wav).
For example, this forbids reading 16 bits DolbyE stream from a 24 bit wav file.
---
 libavformat/s337m.c | 20 ++--
 libavformat/s337m.h |  3 ++-
 2 files changed, 16 insertions(+), 7 deletions(-)

diff --git a/libavformat/s337m.c b/libavformat/s337m.c
index 9776cf1bf1..f162f86762 100644
--- a/libavformat/s337m.c
+++ b/libavformat/s337m.c
@@ -34,7 +34,7 @@
 
 static int s337m_get_offset_and_codec(void *avc,
   uint64_t state,
-  int data_type, int data_size,
+  int data_type, int data_size, int 
container_word_bits,
   int *offset, enum AVCodecID *codec)
 {
 int word_bits;
@@ -55,6 +55,11 @@ static int s337m_get_offset_and_codec(void *avc,
 avpriv_report_missing_feature(avc, "Data type %#x in SMPTE 337M", 
data_type & 0x1F);
 return AVERROR_PATCHWELCOME;
 }
+if (container_word_bits && !(container_word_bits == 16 && word_bits == 16) 
&& !(container_word_bits == 24 && word_bits == 20) && !(container_word_bits == 
24 && word_bits == 24)) {
+if (avc)
+av_log(avc, AV_LOG_ERROR, "s337m: Container is %d bits vs. stream 
is %d bits\n", container_word_bits, word_bits);
+return AVERROR_INVALIDDATA;
+}
 
 if (codec)
 *codec = AV_CODEC_ID_DOLBY_E;
@@ -104,7 +109,7 @@ static int s337m_probe(const AVProbeData *p)
 data_size = AV_RL24(buf + 3);
 }
 
-if (s337m_get_offset_and_codec(NULL, state, data_type, data_size, 
&offset, NULL))
+if (s337m_get_offset_and_codec(NULL, state, data_type, data_size, 0, 
&offset, NULL))
 continue;
 
 i = IS_16LE_MARKER(state) ? 0 : IS_20LE_MARKER(state) ? 1 : 2;
@@ -142,13 +147,16 @@ static void bswap_buf24(uint8_t *data, int size)
 FFSWAP(uint8_t, data[0], data[2]);
 }
 
-int ff_s337m_get_packet(AVIOContext *pb, AVPacket *pkt, int size, enum 
AVCodecID *codec, void *avc)
+int ff_s337m_get_packet(AVIOContext *pb, AVPacket *pkt, int size, enum 
AVCodecID *codec, void *avc, int container_word_bits)
 {
 uint64_t state = 0;
 int ret, data_type, data_size, offset;
 int64_t pos, orig_pos = avio_tell(pb);
 
-while (!IS_LE_MARKER(state)) {
+if (container_word_bits && container_word_bits != 16 && 
container_word_bits != 24)
+return AVERROR_INVALIDDATA;
+while ((container_word_bits == 24 || !IS_16LE_MARKER(state))
+&& (container_word_bits == 16 || !IS_20LE_MARKER(state) && 
!IS_24LE_MARKER(state))) {
 state = (state << 8) | avio_r8(pb);
 if (avio_feof(pb))
 return AVERROR_EOF;
@@ -168,7 +176,7 @@ int ff_s337m_get_packet(AVIOContext *pb, AVPacket *pkt, int 
size, enum AVCodecID
 
 pos = avio_tell(pb);
 
-if ((ret = s337m_get_offset_and_codec(avc, state, data_type, data_size, 
&offset, codec)) < 0)
+if ((ret = s337m_get_offset_and_codec(avc, state, data_type, data_size, 
container_word_bits, &offset, codec)) < 0)
 return ret;
 
 if (ret = av_new_packet(pkt, FFMIN(offset, size - (pos - orig_pos))) < 0)
@@ -194,7 +202,7 @@ static int s337m_read_packet(AVFormatContext *s, AVPacket 
*pkt)
 enum AVCodecID codec;
 int ret;
 
-if ((ret = ff_s337m_get_packet(s->pb, pkt, avio_size(s->pb), &codec, s)) < 
0)
+if ((ret = ff_s337m_get_packet(s->pb, pkt, avio_size(s->pb), &codec, s, 
0)) < 0)
 return ret;
 
 if (!s->nb_streams) {
diff --git a/libavformat/s337m.h b/libavformat/s337m.h
index f7bd0c16f6..af2c4c85a3 100644
--- a/libavformat/s337m.h
+++ b/libavformat/s337m.h
@@ -30,8 +30,9 @@
  * @param size Maximum IO read size available for reading at current position
  * @param codec Returns AV_CODEC_ID_DOLBY_E
  * @param avc For av_log
+ * @param container_word_bits 16,24, or 0 for autodetect
  * @return = 0 on success (an error is raised if no s337m was found)
  */
-int ff_s337m_get_packet(AVIOContext *pb, AVPacket *pkt, int size, enum 
AVCodecID *codec, void *avc);
+int ff_s337m_get_packet(AVIOContext *pb, AVPacket *pkt, int size, enum 
AVCodecID *codec, void *avc, int container_word_bits);
 
 #endif /* AVFORMAT_S337M_H */
-- 
2.14.1.windows.1

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

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

[FFmpeg-devel] [PATCH v2 6/8] avformat/wavdec.c: Reindent after last commit

2020-01-15 Thread Nicolas Gaullier
---
 libavformat/wavdec.c | 16 
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/libavformat/wavdec.c b/libavformat/wavdec.c
index d030ed9f9d..3571733817 100644
--- a/libavformat/wavdec.c
+++ b/libavformat/wavdec.c
@@ -713,14 +713,14 @@ smv_out:
 size = FFMIN(S337M_MAX_OFFSET, left);
 ret  = ff_s337m_get_packet(s->pb, pkt, size, NULL, s, 
st->codecpar->bits_per_coded_sample);
 } else {
-size = MAX_SIZE;
-if (st->codecpar->block_align > 1) {
-if (size < st->codecpar->block_align)
-size = st->codecpar->block_align;
-size = (size / st->codecpar->block_align) * st->codecpar->block_align;
-}
-size = FFMIN(size, left);
-ret  = av_get_packet(s->pb, pkt, size);
+size = MAX_SIZE;
+if (st->codecpar->block_align > 1) {
+if (size < st->codecpar->block_align)
+size = st->codecpar->block_align;
+size = (size / st->codecpar->block_align) * 
st->codecpar->block_align;
+}
+size = FFMIN(size, left);
+ret  = av_get_packet(s->pb, pkt, size);
 }
 
 if (ret < 0)
-- 
2.14.1.windows.1

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

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

[FFmpeg-devel] [PATCH v2 4/8] avformat/s337m: New ff_s337m_probe()

2020-01-15 Thread Nicolas Gaullier
Similar to ff_spdif_probe() with just an additional checking of
the bit resolution of the container as it may be 16 or 24 for s337m.
---
 libavformat/s337m.c | 32 
 libavformat/s337m.h | 16 
 2 files changed, 48 insertions(+)

diff --git a/libavformat/s337m.c b/libavformat/s337m.c
index f162f86762..129bee16bc 100644
--- a/libavformat/s337m.c
+++ b/libavformat/s337m.c
@@ -133,6 +133,38 @@ static int s337m_probe(const AVProbeData *p)
 return 0;
 }
 
+int ff_s337m_probe(const uint8_t *buf, int size, enum AVCodecID *codec, int 
container_word_bits)
+{
+int pos = 0;
+int consecutive_codes = 0;
+
+if ( size < S337M_MIN_OFFSET)
+return 0;
+size = FFMIN(3 * S337M_MAX_OFFSET, size);
+if (container_word_bits != 16 && container_word_bits != 24)
+return AVERROR_INVALIDDATA;
+
+do {
+uint64_t state;
+int data_type, data_size, offset;
+while (pos < size - 12 && !buf[pos]) {
+pos++;
+}
+if (pos >= size - 12 || pos < S337M_PROBE_GUARDBAND_MIN_BYTES || pos % 
(container_word_bits == 16 ? 4 : 6))
+return 0;
+state = container_word_bits == 16 ? AV_RB32(buf + pos) : AV_RB48(buf + 
pos);
+if (!IS_LE_MARKER(state))
+return 0;
+data_type = container_word_bits == 16 ? AV_RL16(buf + pos + 4) : 
AV_RL24(buf + pos + 6);
+data_size = container_word_bits == 16 ? AV_RL16(buf + pos + 6) : 
AV_RL24(buf + pos + 9);
+if (s337m_get_offset_and_codec(NULL, state, data_type, data_size, 
container_word_bits, &offset, codec))
+return 0;
+pos = ++consecutive_codes * (offset + 4*(container_word_bits == 16 ? 4 
: 6));
+} while (consecutive_codes < 3);
+
+return AVPROBE_SCORE_MAX;
+}
+
 static int s337m_read_header(AVFormatContext *s)
 {
 s->ctx_flags |= AVFMTCTX_NOHEADER;
diff --git a/libavformat/s337m.h b/libavformat/s337m.h
index af2c4c85a3..94e79dce5d 100644
--- a/libavformat/s337m.h
+++ b/libavformat/s337m.h
@@ -21,6 +21,22 @@
 #ifndef AVFORMAT_S337M_H
 #define AVFORMAT_S337M_H
 
+#define S337M_MIN_OFFSET 1601*4
+#define S337M_MAX_OFFSET 2002*6
+
+#define S337M_PROBE_GUARDBAND_MIN_BYTES 0
+
+/**
+ * Detect s337m packets in a PCM_S16LE/S24LE stereo stream
+ * Requires 3 samples with enough (S337M_PROBE_GUARDBAND_MIN_BYTES) and clean 
(set to zero) guard band
+ * @param p_buf Buffer
+ * @param size Buffer size
+ * @param codec Returns AV_CODEC_ID_DOLBY_E upon successful probing
+ * @param container_word_bits 16 or 24
+ * @return = AVPROBE_SCORE
+ */
+int ff_s337m_probe(const uint8_t *p_buf, int size, enum AVCodecID *codec, int 
container_word_bits);
+
 /**
  * Read s337m packets in a PCM_S16LE/S24LE stereo stream
  * Returns the first inner packet found
-- 
2.14.1.windows.1

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

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

Re: [FFmpeg-devel] [PATCH 1/2] avcodec/wmalosslessdec: move channel check up

2020-01-15 Thread Michael Niedermayer
On Wed, Jan 15, 2020 at 02:33:28AM +0100, Andreas Rheinhardt wrote:
> On Wed, Jan 15, 2020 at 1:25 AM Michael Niedermayer 
> wrote:
> 
> > Fixes: out of array access
> > Fixes: 2nd part of
> > 18429/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_WMALOSSLESS_fuzzer-6210814364614656
> >
> > Found-by: continuous fuzzing process
> > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> > Signed-off-by
> > :
> > Michael Niedermayer 
> > ---
> >  libavcodec/wmalosslessdec.c | 20 ++--
> >  1 file changed, 10 insertions(+), 10 deletions(-)
> >
> > diff --git a/libavcodec/wmalosslessdec.c b/libavcodec/wmalosslessdec.c
> > index d2f9d4a70f..2b97c2a848 100644
> > --- a/libavcodec/wmalosslessdec.c
> > +++ b/libavcodec/wmalosslessdec.c
> > @@ -189,6 +189,16 @@ static av_cold int decode_init(AVCodecContext *avctx)
> >  return AVERROR(EINVAL);
> >  }
> >
> > +if (avctx->channels < 0) {
> > +av_log(avctx, AV_LOG_ERROR, "invalid number of channels %d\n",
> > +   avctx->channels);
> > +return AVERROR_INVALIDDATA;
> > +} else if (avctx->channels > WMALL_MAX_CHANNELS) {
> > +avpriv_request_sample(avctx,
> > +  "More than %d channels",
> > WMALL_MAX_CHANNELS);
> >
> 
> This looks like it could benefit from AV_STRINGIFY. LGTM apart from that.

will apply with a AV_STRINGIFY patch

thanks

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

Frequently ignored answer#1 FFmpeg bugs should be sent to our bugtracker. User
questions about the command line tools should be sent to the ffmpeg-user ML.
And questions about how to use libav* should be sent to the libav-user ML.


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

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

Re: [FFmpeg-devel] [PATCH v2 5/8] avformat/wavdec: s337m support

2020-01-15 Thread Carl Eugen Hoyos
Am Mi., 15. Jan. 2020 um 11:57 Uhr schrieb Nicolas Gaullier
:
>
> Add s337m probing/reading similarly to spdif.
> ---
>  libavformat/wavdec.c | 23 +++
>  1 file changed, 19 insertions(+), 4 deletions(-)
>
> diff --git a/libavformat/wavdec.c b/libavformat/wavdec.c
> index 575c667452..d030ed9f9d 100644
> --- a/libavformat/wavdec.c
> +++ b/libavformat/wavdec.c
> @@ -41,6 +41,7 @@
>  #include "riff.h"
>  #include "w64.h"
>  #include "spdif.h"
> +#include "s337m.h"
>
>  typedef struct WAVDemuxContext {
>  const AVClass *class;
> @@ -55,15 +56,17 @@ typedef struct WAVDemuxContext {
>  int audio_eof;
>  int ignore_length;
>  int spdif;
> +int s337m;
>  int smv_cur_pt;
>  int smv_given_first;
>  int unaligned; // e.g. if an odd number of bytes ID3 tag was prepended
>  int rifx; // RIFX: integer byte order for parameters is big endian
>  } WAVDemuxContext;
>
> -static void set_spdif(AVFormatContext *s, WAVDemuxContext *wav)
> +static void set_spdif_s337m(AVFormatContext *s, WAVDemuxContext *wav)
>  {
> -if (CONFIG_SPDIF_DEMUXER && s->streams[0]->codecpar->codec_tag == 1) {
> +AVCodecParameters *par = s->streams[0]->codecpar;
> +if ((CONFIG_SPDIF_DEMUXER || CONFIG_S337M_DEMUXER) && par->codec_tag == 
> 1) {

Did you test this with both "--disable-everything
--enable-demuxer=spdif" and "--disable-everything
--enable-demuxer=s337m"?
Neither should fail compilation.

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

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

Re: [FFmpeg-devel] [PATCH v2 7/8] avformat/wavdec: fix s337m/spdif probing beyond data_end

2020-01-15 Thread Carl Eugen Hoyos
Am Mi., 15. Jan. 2020 um 11:56 Uhr schrieb Nicolas Gaullier
:
>
> ---
>  libavformat/wavdec.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavformat/wavdec.c b/libavformat/wavdec.c
> index 3571733817..d8a27c79cf 100644
> --- a/libavformat/wavdec.c
> +++ b/libavformat/wavdec.c
> @@ -77,7 +77,7 @@ static void set_spdif_s337m(AVFormatContext *s, 
> WAVDemuxContext *wav)
>  ret = AVERROR(ENOMEM);
>  } else {
>  int64_t pos = avio_tell(s->pb);
> -len = ret = avio_read(s->pb, buf, len);
> +len = ret = avio_read(s->pb, buf, FFMIN(len, wav->data_end - 
> pos));

Sorry if this was already answered:
What exactly does this fix? Is it possible that avio_read() overreads without
this check?

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

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

[FFmpeg-devel] [PATCH]ffmpeg: Do not exit if alleged error was only worth a debug information

2020-01-15 Thread Carl Eugen Hoyos
Hi!

Attached patch fixes hard-to-understand behaviour of ffmpeg for some
mp4 input files, a hard exit following a debug message.

Please comment, Carl Eugen
From b4b6d426fadacef4b1e912e8be6d06520093a955 Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos 
Date: Wed, 15 Jan 2020 14:48:02 +0100
Subject: [PATCH] ffmpeg: Do not exit if alleged error was only worth a debug
 information.

Reported-by: Forum user NewPlaza
---
 fftools/ffmpeg.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
index 6bcd7b94d2..c5be7fdfb6 100644
--- a/fftools/ffmpeg.c
+++ b/fftools/ffmpeg.c
@@ -783,7 +783,7 @@ static void write_packet(OutputFile *of, AVPacket *pkt, OutputStream *ost, int u
 av_log(s, loglevel, "Non-monotonous DTS in output stream "
"%d:%d; previous: %"PRId64", current: %"PRId64"; ",
ost->file_index, ost->st->index, ost->last_mux_dts, pkt->dts);
-if (exit_on_error) {
+if (exit_on_error && loglevel > AV_LOG_DEBUG) {
 av_log(NULL, AV_LOG_FATAL, "aborting.\n");
 exit_program(1);
 }
-- 
2.23.0

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

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

Re: [FFmpeg-devel] [PATCH v2 7/8] avformat/wavdec: fix s337m/spdif probing beyond data_end

2020-01-15 Thread Gaullier Nicolas
>>
>> ---
>>  libavformat/wavdec.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/libavformat/wavdec.c b/libavformat/wavdec.c index 
>> 3571733817..d8a27c79cf 100644
>> --- a/libavformat/wavdec.c
>> +++ b/libavformat/wavdec.c
>> @@ -77,7 +77,7 @@ static void set_spdif_s337m(AVFormatContext *s, 
>> WAVDemuxContext *wav)
>>  ret = AVERROR(ENOMEM);
>>  } else {
>>  int64_t pos = avio_tell(s->pb);
>> -len = ret = avio_read(s->pb, buf, len);
>> +len = ret = avio_read(s->pb, buf, FFMIN(len, 
>> + wav->data_end - pos));
>
>Sorry if this was already answered:
>What exactly does this fix? Is it possible that avio_read() overreads without 
>this check?
>
>Carl Eugen

There is no severe low level avio overread risk, but there is a risk to read 
bytes that are not audio data in case audio data is followed by other data (a 
RIFF chunk that would come just after the audio data RIFF chunk).

Here is a sample a build : http://0x0.st/zhiO.wav This sample is detected as 
ac3 whereas the sync codes are beyond the data chunk, in a 'junk' (I called it 
this way) chunk that is not supposed to be read (ex: the duration can be 
cross-checked with sox or audacity for example).
But again, this is obviously very improbable "in the nature" as they are three 
conditions :
- the wav file must be short enough (for the probe to seek in the end of the 
file)
- the audio data chunk must be followed by another chunk with misc data 
(usually those are considered "header metadata" and stand before it)
- the misc data chunk must emulate the sync codes

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

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

Re: [FFmpeg-devel] [PATCH v2 7/8] avformat/wavdec: fix s337m/spdif probing beyond data_end

2020-01-15 Thread Carl Eugen Hoyos
Am Mi., 15. Jan. 2020 um 16:07 Uhr schrieb Gaullier Nicolas
:
>
> >>
> >> ---
> >>  libavformat/wavdec.c | 2 +-
> >>  1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/libavformat/wavdec.c b/libavformat/wavdec.c index
> >> 3571733817..d8a27c79cf 100644
> >> --- a/libavformat/wavdec.c
> >> +++ b/libavformat/wavdec.c
> >> @@ -77,7 +77,7 @@ static void set_spdif_s337m(AVFormatContext *s, 
> >> WAVDemuxContext *wav)
> >>  ret = AVERROR(ENOMEM);
> >>  } else {
> >>  int64_t pos = avio_tell(s->pb);
> >> -len = ret = avio_read(s->pb, buf, len);
> >> +len = ret = avio_read(s->pb, buf, FFMIN(len,
> >> + wav->data_end - pos));
> >
> >Sorry if this was already answered:
> >What exactly does this fix? Is it possible that avio_read() overreads 
> >without this check?
> >
> >Carl Eugen
>
> There is no severe low level avio overread risk, but there is a risk to read 
> bytes that are not audio data in case audio data is followed by other data (a 
> RIFF chunk that would come just after the audio data RIFF chunk).
>
> Here is a sample a build : http://0x0.st/zhiO.wav This sample is detected as 
> ac3 whereas the sync codes are beyond the data chunk, in a 'junk' (I called 
> it this way) chunk that is not supposed to be read (ex: the duration can be 
> cross-checked with sox or audacity for example).
> But again, this is obviously very improbable "in the nature" as they are 
> three conditions :
> - the wav file must be short enough (for the probe to seek in the end of the 
> file)
> - the audio data chunk must be followed by another chunk with misc data 
> (usually those are considered "header metadata" and stand before it)
> - the misc data chunk must emulate the sync codes

Thank you for the explanation.

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

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

[FFmpeg-devel] [PATCH] avfilter/pad: improve error check for w and h

2020-01-15 Thread Gyan Doshi
Target dimensions have to cover entire input.
---
 libavfilter/vf_pad.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/libavfilter/vf_pad.c b/libavfilter/vf_pad.c
index 186d3f028d..e86292eaa2 100644
--- a/libavfilter/vf_pad.c
+++ b/libavfilter/vf_pad.c
@@ -178,14 +178,14 @@ static int config_input(AVFilterLink *inlink)
 if (s->y < 0 || s->y + inlink->h > s->h)
 s->y = var_values[VAR_Y] = (s->h - inlink->h) / 2;
 
+s->w= ff_draw_round_to_sub(&s->draw, 0, -1, s->w);
+s->h= ff_draw_round_to_sub(&s->draw, 1, -1, s->h);
 /* sanity check params */
-if (s->w < 0 || s->h < 0) {
-av_log(ctx, AV_LOG_ERROR, "Negative values are not acceptable.\n");
+if (s->w < inlink->w || s->h < inlink->h) {
+av_log(ctx, AV_LOG_ERROR, "Padded dimensions cannot be smaller than 
input dimensions.\n");
 return AVERROR(EINVAL);
 }
 
-s->w= ff_draw_round_to_sub(&s->draw, 0, -1, s->w);
-s->h= ff_draw_round_to_sub(&s->draw, 1, -1, s->h);
 s->x= ff_draw_round_to_sub(&s->draw, 0, -1, s->x);
 s->y= ff_draw_round_to_sub(&s->draw, 1, -1, s->y);
 s->in_w = ff_draw_round_to_sub(&s->draw, 0, -1, inlink->w);
-- 
2.24.1

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

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

Re: [FFmpeg-devel] [PATCH]ffmpeg: Do not exit if alleged error was only worth a debug information

2020-01-15 Thread Marton Balint



On Wed, 15 Jan 2020, Carl Eugen Hoyos wrote:


Hi!

Attached patch fixes hard-to-understand behaviour of ffmpeg for some
mp4 input files, a hard exit following a debug message.


I don't think such an mp4 file is strictly valid, therefore the behavior 
of the program should remain the same, it should exit.


It might make more sense to force an AV_LOG_ERROR level for the message if 
exit_on_error is set.


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

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

[FFmpeg-devel] [PATCH] lavf/libsrt: nonblock enabling correction

2020-01-15 Thread Anthony Delannoy
As written in https://github.com/Haivision/srt/blob/v1.4.1/docs/API.md,
the nonblock mode is activated if SRTO_SNDSYN and SRTO_RCVSYN, for
sending and receiving respectively, are set to 0.
---
 libavformat/libsrt.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/libavformat/libsrt.c b/libavformat/libsrt.c
index 16975b6d94..60b1dd8e9c 100644
--- a/libavformat/libsrt.c
+++ b/libavformat/libsrt.c
@@ -152,12 +152,12 @@ static int libsrt_neterrno(URLContext *h)
 return AVERROR_UNKNOWN;
 }
 
-static int libsrt_socket_nonblock(int socket, int enable)
+static int libsrt_socket_nonblock(int socket, int disable)
 {
-int ret = srt_setsockopt(socket, 0, SRTO_SNDSYN, &enable, sizeof(enable));
+int ret = srt_setsockopt(socket, 0, SRTO_SNDSYN, &disable, 
sizeof(disable));
 if (ret < 0)
 return ret;
-return srt_setsockopt(socket, 0, SRTO_RCVSYN, &enable, sizeof(enable));
+return srt_setsockopt(socket, 0, SRTO_RCVSYN, &disable, sizeof(disable));
 }
 
 static int libsrt_network_wait_fd(URLContext *h, int eid, int fd, int write)
@@ -235,7 +235,7 @@ static int libsrt_listen(int eid, int fd, const struct 
sockaddr *addr, socklen_t
 ret = srt_accept(fd, NULL, NULL);
 if (ret < 0)
 return libsrt_neterrno(h);
-if (libsrt_socket_nonblock(ret, 1) < 0)
+if (libsrt_socket_nonblock(ret, 0) < 0)
 av_log(h, AV_LOG_DEBUG, "libsrt_socket_nonblock failed\n");
 
 return ret;
@@ -245,7 +245,7 @@ static int libsrt_listen_connect(int eid, int fd, const 
struct sockaddr *addr, s
 {
 int ret;
 
-if (libsrt_socket_nonblock(fd, 1) < 0)
+if (libsrt_socket_nonblock(fd, 0) < 0)
 av_log(h, AV_LOG_DEBUG, "ff_socket_nonblock failed\n");
 
 while ((ret = srt_connect(fd, addr, addrlen))) {
-- 
2.24.1

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

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

Re: [FFmpeg-devel] [PATCH v2 5/8] avformat/wavdec: s337m support

2020-01-15 Thread Gaullier Nicolas
>> Add s337m probing/reading similarly to spdif.
>> ---
>>  libavformat/wavdec.c | 23 +++
>>  1 file changed, 19 insertions(+), 4 deletions(-)
>>
>> diff --git a/libavformat/wavdec.c b/libavformat/wavdec.c index 
>> 575c667452..d030ed9f9d 100644
>> --- a/libavformat/wavdec.c
>> +++ b/libavformat/wavdec.c
>> @@ -41,6 +41,7 @@
>>  #include "riff.h"
>>  #include "w64.h"
>>  #include "spdif.h"
>> +#include "s337m.h"
>>
>>  typedef struct WAVDemuxContext {
>>  const AVClass *class;
>> @@ -55,15 +56,17 @@ typedef struct WAVDemuxContext {
>>  int audio_eof;
>>  int ignore_length;
>>  int spdif;
>> +int s337m;
>>  int smv_cur_pt;
>>  int smv_given_first;
>>  int unaligned; // e.g. if an odd number of bytes ID3 tag was prepended
>>  int rifx; // RIFX: integer byte order for parameters is big 
>> endian  } WAVDemuxContext;
>>
>> -static void set_spdif(AVFormatContext *s, WAVDemuxContext *wav)
>> +static void set_spdif_s337m(AVFormatContext *s, WAVDemuxContext *wav)
>>  {
>> -if (CONFIG_SPDIF_DEMUXER && s->streams[0]->codecpar->codec_tag == 1) {
>> +AVCodecParameters *par = s->streams[0]->codecpar;
>> +if ((CONFIG_SPDIF_DEMUXER || CONFIG_S337M_DEMUXER) && 
>> + par->codec_tag == 1) {
>
>Did you test this with both "--disable-everything --enable-demuxer=spdif" and 
>"--disable-everything --enable-demuxer=s337m"?
>Neither should fail compilation.
>
>Carl Eugen

I just have tested both, and compilation is ok.

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

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

Re: [FFmpeg-devel] [PATCH v2 5/8] avformat/wavdec: s337m support

2020-01-15 Thread Carl Eugen Hoyos
Am Mi., 15. Jan. 2020 um 19:16 Uhr schrieb Gaullier Nicolas
:
>
> >> Add s337m probing/reading similarly to spdif.
> >> ---
> >>  libavformat/wavdec.c | 23 +++
> >>  1 file changed, 19 insertions(+), 4 deletions(-)
> >>
> >> diff --git a/libavformat/wavdec.c b/libavformat/wavdec.c index
> >> 575c667452..d030ed9f9d 100644
> >> --- a/libavformat/wavdec.c
> >> +++ b/libavformat/wavdec.c
> >> @@ -41,6 +41,7 @@
> >>  #include "riff.h"
> >>  #include "w64.h"
> >>  #include "spdif.h"
> >> +#include "s337m.h"
> >>
> >>  typedef struct WAVDemuxContext {
> >>  const AVClass *class;
> >> @@ -55,15 +56,17 @@ typedef struct WAVDemuxContext {
> >>  int audio_eof;
> >>  int ignore_length;
> >>  int spdif;
> >> +int s337m;
> >>  int smv_cur_pt;
> >>  int smv_given_first;
> >>  int unaligned; // e.g. if an odd number of bytes ID3 tag was prepended
> >>  int rifx; // RIFX: integer byte order for parameters is big
> >> endian  } WAVDemuxContext;
> >>
> >> -static void set_spdif(AVFormatContext *s, WAVDemuxContext *wav)
> >> +static void set_spdif_s337m(AVFormatContext *s, WAVDemuxContext *wav)
> >>  {
> >> -if (CONFIG_SPDIF_DEMUXER && s->streams[0]->codecpar->codec_tag == 1) {
> >> +AVCodecParameters *par = s->streams[0]->codecpar;
> >> +if ((CONFIG_SPDIF_DEMUXER || CONFIG_S337M_DEMUXER) &&
> >> + par->codec_tag == 1) {
> >
> >Did you test this with both "--disable-everything --enable-demuxer=spdif" 
> >and "--disable-everything --enable-demuxer=s337m"?
> >Neither should fail compilation.
> >
> >Carl Eugen
>
> I just have tested both, and compilation is ok.

Sorry, this should have been "--disable-everything
--enable-demuxer=wav,spdif" and "--disable-everything
--enable-demuxer=wav,s337m".

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

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

Re: [FFmpeg-devel] [PATCH 2/9] swscale: Add swscale input support for Y210LE

2020-01-15 Thread Carl Eugen Hoyos
Am Mi., 15. Jan. 2020 um 07:59 Uhr schrieb Linjie Fu :
>
> Add swscale input support for Y210LE, output support and fate
> test could be added later if there is requirement for software
> CSC to this packed format.

Please confirm that this works as expected on big-endian hardware.

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

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

Re: [FFmpeg-devel] [PATCH] lavf/libsrt: nonblock enabling correction

2020-01-15 Thread Marton Balint



On Wed, 15 Jan 2020, Anthony Delannoy wrote:


As written in https://github.com/Haivision/srt/blob/v1.4.1/docs/API.md,
the nonblock mode is activated if SRTO_SNDSYN and SRTO_RCVSYN, for
sending and receiving respectively, are set to 0.
---
libavformat/libsrt.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/libavformat/libsrt.c b/libavformat/libsrt.c
index 16975b6d94..60b1dd8e9c 100644
--- a/libavformat/libsrt.c
+++ b/libavformat/libsrt.c
@@ -152,12 +152,12 @@ static int libsrt_neterrno(URLContext *h)
return AVERROR_UNKNOWN;
}

-static int libsrt_socket_nonblock(int socket, int enable)
+static int libsrt_socket_nonblock(int socket, int disable)


So if you want to enable nonblocking mode you'd have to call 
libsrt_socket_nonblock(socket, 0). That is just ugly.


I suggest you either
- rename the function to libsrt_socket_block()
or
- keep the function declaration as is and do the negation inside the 
function and add a comment that it is intentional.


Regards,
Marton


{
-int ret = srt_setsockopt(socket, 0, SRTO_SNDSYN, &enable, sizeof(enable));
+int ret = srt_setsockopt(socket, 0, SRTO_SNDSYN, &disable, 
sizeof(disable));
if (ret < 0)
return ret;
-return srt_setsockopt(socket, 0, SRTO_RCVSYN, &enable, sizeof(enable));
+return srt_setsockopt(socket, 0, SRTO_RCVSYN, &disable, sizeof(disable));
}

static int libsrt_network_wait_fd(URLContext *h, int eid, int fd, int write)
@@ -235,7 +235,7 @@ static int libsrt_listen(int eid, int fd, const struct 
sockaddr *addr, socklen_t
ret = srt_accept(fd, NULL, NULL);
if (ret < 0)
return libsrt_neterrno(h);
-if (libsrt_socket_nonblock(ret, 1) < 0)
+if (libsrt_socket_nonblock(ret, 0) < 0)
av_log(h, AV_LOG_DEBUG, "libsrt_socket_nonblock failed\n");

return ret;
@@ -245,7 +245,7 @@ static int libsrt_listen_connect(int eid, int fd, const 
struct sockaddr *addr, s
{
int ret;

-if (libsrt_socket_nonblock(fd, 1) < 0)
+if (libsrt_socket_nonblock(fd, 0) < 0)
av_log(h, AV_LOG_DEBUG, "ff_socket_nonblock failed\n");

while ((ret = srt_connect(fd, addr, addrlen))) {
--
2.24.1

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

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

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

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

Re: [FFmpeg-devel] [PATCHv2 8/8] avformat/img2enc: add support for specifying protocol options

2020-01-15 Thread Marton Balint



On Thu, 9 Jan 2020, Michael Niedermayer wrote:


On Wed, Jan 01, 2020 at 08:10:06PM +0100, Marton Balint wrote:



On Tue, 31 Dec 2019, Michael Niedermayer wrote:


On Tue, Dec 31, 2019 at 12:37:02PM +0100, Nicolas George wrote:

Marton Balint (12019-12-28):

v2: simplified example

Signed-off-by: Marton Balint 
---
doc/muxers.texi   | 11 +++
libavformat/img2enc.c | 13 -
2 files changed, 23 insertions(+), 1 deletion(-)


image2 is not the only demuxer that opens new streams. I think a generic
solution would be preferable.


i also had a slightly ungood feeling about the patch but didnt
had time to think more about it. a more generic solution like with
child AVClasses or something would be interresting but as said i didnt
had time to think about this ...


It looks like a big can of worms.

In the AVFMT_NOFILE case there is no IO context, so options can only be
passed using avformat_write_header/avformat_init_output.

There is no way to determine which options the protocols will use without
actually opening an IO context (protocol options are passed to the url_open
method of each protocol), so we have to store all remaining options passed
to avformat_write_header/avformat_init_output for possible nested IO use.

In the normal case (non AVFMT_NOFILE) muxers can use nested contexts too, so
avio_open should also store the original options, all of them, because the
nested contexts might use different protocols. This alone is problematic,
because avio_open should return the unrecognized options...

Also it might make sense to specify different IO options for nested contexts
than main contexts (or different options for some of the nested contexts)

IMHO being able to specify the nested options separately is a clean
solution, admittedly less user friendly, but I don't see how this can work
automagically without some major redesign.


ok, yes i agree it would need a too major redesign.


Ok, I will apply in a few days if I receive no further comments.

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

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

Re: [FFmpeg-devel] [PATCH 01/13] avformat/mux: Move packet references

2020-01-15 Thread Andreas Rheinhardt
On Tue, Oct 8, 2019 at 12:42 PM Andreas Rheinhardt <
andreas.rheinha...@gmail.com> wrote:

> Andreas Rheinhardt:
> > Andreas Rheinhardt:
> >> In the common case that the input packet was already refcounted,
> >> ff_interleave_add_packet would allocate a new AVPacketList, use
> >> av_packet_ref to create a new reference to the buffer for the
> >> AVPacketList's packet, interleave the packet and finally unreference
> >> the original input packet.
> >> This commit changes this: It uses av_packet_move_ref to transfer
> >> the packet to its destination. In case the input packet is refcounted,
> >> this saves an allocation and a free (of an AVBufferRef); if not, the
> >> packet is made refcounted before moving it. When the input packet has
> >> side data, one saves even more than one allocation+free.
> >>
> >> Furthermore, when the packet is in reality an uncoded frame, a hacky
> >> ad-hoc variant of av_packet_move_ref has been employed. Not any more.
> >>
> >> Signed-off-by: Andreas Rheinhardt 
> >> ---
> >>  libavformat/mux.c | 11 ---
> >>  1 file changed, 4 insertions(+), 7 deletions(-)
> >>
> >> diff --git a/libavformat/mux.c b/libavformat/mux.c
> >> index 8ab5ea8c2b..ac370fb24d 100644
> >> --- a/libavformat/mux.c
> >> +++ b/libavformat/mux.c
> >> @@ -930,17 +930,16 @@ int ff_interleave_add_packet(AVFormatContext *s,
> AVPacket *pkt,
> >>  if ((pkt->flags & AV_PKT_FLAG_UNCODED_FRAME)) {
> >>  av_assert0(pkt->size == UNCODED_FRAME_PACKET_SIZE);
> >>  av_assert0(((AVFrame *)pkt->data)->buf);
> >> -this_pktl->pkt = *pkt;
> >> -pkt->buf = NULL;
> >> -pkt->side_data = NULL;
> >> -pkt->side_data_elems = 0;
> >>  } else {
> >> -if ((ret = av_packet_ref(&this_pktl->pkt, pkt)) < 0) {
> >> +if ((ret = av_packet_make_refcounted(pkt)) < 0) {
> >>  av_free(this_pktl);
> >>  return ret;
> >>  }
> >>  }
> >>
> >> +av_packet_move_ref(&this_pktl->pkt, pkt);
> >> +pkt = &this_pktl->pkt;
> >> +
> >>  if (s->streams[pkt->stream_index]->last_in_packet_buffer) {
> >>  next_point = &(st->last_in_packet_buffer->next);
> >>  } else {
> >> @@ -989,8 +988,6 @@ next_non_null:
> >>  s->streams[pkt->stream_index]->last_in_packet_buffer =
> >>  *next_point  = this_pktl;
> >>
> >> -av_packet_unref(pkt);
> >> -
> >>  return 0;
> >>  }
> >>
> >>
> > Ping for this patch and the remaining unmerged patches in this
> > patchset (patches 1, 2, 4, 5, 7-13).
> >
> > - Andreas
> >
> Another ping.
>
> - Andreas
>

Another ping.

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

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

[FFmpeg-devel] [PATCH] avcodec/mvha: Check remaining bits in VLC decode loop

2020-01-15 Thread Michael Niedermayer
Fixes: timeout (252sec -> 170msec)
Fixes: 
20023/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_MVHA_fuzzer-5681192565473280

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

diff --git a/libavcodec/mvha.c b/libavcodec/mvha.c
index afe5e511f2..47706e338b 100644
--- a/libavcodec/mvha.c
+++ b/libavcodec/mvha.c
@@ -233,6 +233,8 @@ static int decode_frame(AVCodecContext *avctx,
 
 dst = frame->data[p] + (avctx->height - 1) * frame->linesize[p];
 for (int y = 0; y < avctx->height; y++) {
+if (get_bits_left(gb) < width)
+return AVERROR_INVALIDDATA;
 for (int x = 0; x < width; x++) {
 int v = get_vlc2(gb, s->vlc.table, s->vlc.bits, 3);
 
-- 
2.24.0

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

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

[FFmpeg-devel] [PATCH 2/4] avformat/udp: properly use return value of pthread_cond_timedwait

2020-01-15 Thread Marton Balint
Signed-off-by: Marton Balint 
---
 libavformat/udp.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/libavformat/udp.c b/libavformat/udp.c
index e42a069b24..c92fcc49a1 100644
--- a/libavformat/udp.c
+++ b/libavformat/udp.c
@@ -978,9 +978,10 @@ static int udp_read(URLContext *h, uint8_t *buf, int size)
 int64_t t = av_gettime() + 10;
 struct timespec tv = { .tv_sec  =  t / 100,
.tv_nsec = (t % 100) * 1000 };
-if (pthread_cond_timedwait(&s->cond, &s->mutex, &tv) < 0) {
+int err = pthread_cond_timedwait(&s->cond, &s->mutex, &tv);
+if (err) {
 pthread_mutex_unlock(&s->mutex);
-return AVERROR(errno == ETIMEDOUT ? EAGAIN : errno);
+return AVERROR(err == ETIMEDOUT ? EAGAIN : err);
 }
 nonblock = 1;
 }
-- 
2.16.4

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

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

[FFmpeg-devel] [PATCH 3/4] avformat/udp: increase the default buffer size of a receiving socket to 384K

2020-01-15 Thread Marton Balint
It is a common mistake that people only increase fifo_size when they experience
drops, unfortunately this does not help for higher bitrate (> 100 Mbps) streams
when the reader thread simply might not receive the packets in time (especially
under high CPU load) if the default 64 KB of kernel buffer size is used.

New default is determined so that common linux systems can set this buffer size
without tuning kernel parameters.

Signed-off-by: Marton Balint 
---
 doc/protocols.texi | 2 +-
 libavformat/udp.c  | 3 ++-
 2 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/doc/protocols.texi b/doc/protocols.texi
index d2935fc666..5e8c97d164 100644
--- a/doc/protocols.texi
+++ b/doc/protocols.texi
@@ -1653,7 +1653,7 @@ The list of supported options follows.
 @item buffer_size=@var{size}
 Set the UDP maximum socket buffer size in bytes. This is used to set either
 the receive or send buffer size, depending on what the socket is used for.
-Default is 64KB.  See also @var{fifo_size}.
+Default is 32 KB for output, 384 KB for input.  See also @var{fifo_size}.
 
 @item bitrate=@var{bitrate}
 If set to nonzero, the output will have the specified constant bitrate if the
diff --git a/libavformat/udp.c b/libavformat/udp.c
index c92fcc49a1..11af9b2500 100644
--- a/libavformat/udp.c
+++ b/libavformat/udp.c
@@ -71,6 +71,7 @@
 #endif
 
 #define UDP_TX_BUF_SIZE 32768
+#define UDP_RX_BUF_SIZE 393216
 #define UDP_MAX_PKT_SIZE 65536
 #define UDP_HEADER_SIZE 8
 
@@ -636,7 +637,7 @@ static int udp_open(URLContext *h, const char *uri, int 
flags)
 
 is_output = !(flags & AVIO_FLAG_READ);
 if (s->buffer_size < 0)
-s->buffer_size = is_output ? UDP_TX_BUF_SIZE : UDP_MAX_PKT_SIZE;
+s->buffer_size = is_output ? UDP_TX_BUF_SIZE : UDP_RX_BUF_SIZE;
 
 if (s->sources) {
 if (ff_ip_parse_sources(h, s->sources, &s->filters) < 0)
-- 
2.16.4

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

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

[FFmpeg-devel] [PATCH 1/4] avformat/udp: add newline after warning

2020-01-15 Thread Marton Balint
Signed-off-by: Marton Balint 
---
 libavformat/udp.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavformat/udp.c b/libavformat/udp.c
index f4ec148a2f..e42a069b24 100644
--- a/libavformat/udp.c
+++ b/libavformat/udp.c
@@ -861,7 +861,7 @@ static int udp_open(URLContext *h, const char *uri, int 
flags)
 } else {
 av_log(h, AV_LOG_DEBUG, "end receive buffer size reported is 
%d\n", tmp);
 if(tmp < s->buffer_size)
-av_log(h, AV_LOG_WARNING, "attempted to set receive buffer to 
size %d but it only ended up set as %d", s->buffer_size, tmp);
+av_log(h, AV_LOG_WARNING, "attempted to set receive buffer to 
size %d but it only ended up set as %d\n", s->buffer_size, tmp);
 }
 
 /* make the socket non-blocking */
-- 
2.16.4

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

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

[FFmpeg-devel] [PATCH 4/4] avformat/udp: do not use thread cancellation when receiving data

2020-01-15 Thread Marton Balint
It is not supported by every threading implementation, and the only thing we
gain with it is an immediate shutdown of receiving packets on close and
avoiding the poll call before reading the data.

I don't think it is a big issue if it takes 0.1 sec of delay to close an udp
stream. Back when this was introduced the delay was 1 sec, which was indeed
noticable.

And anybody who needs performance sensitive UDP should not use the fifo buffer
in the first place, because the kernel can buffer the data much more
effectively.

Signed-off-by: Marton Balint 
---
 libavformat/udp.c | 57 +--
 1 file changed, 26 insertions(+), 31 deletions(-)

diff --git a/libavformat/udp.c b/libavformat/udp.c
index 11af9b2500..75fa8c5e31 100644
--- a/libavformat/udp.c
+++ b/libavformat/udp.c
@@ -61,8 +61,8 @@
 #define IPPROTO_UDPLITE  136
 #endif
 
-#if HAVE_PTHREAD_CANCEL
-#include 
+#if HAVE_THREADS
+#include "libavutil/thread.h"
 #endif
 
 #ifndef IPV6_ADD_MEMBERSHIP
@@ -98,7 +98,7 @@ typedef struct UDPContext {
 int64_t bitrate; /* number of bits to send per second */
 int64_t burst_bits;
 int close_req;
-#if HAVE_PTHREAD_CANCEL
+#if HAVE_THREADS
 pthread_t circular_buffer_thread;
 pthread_mutex_t mutex;
 pthread_cond_t cond;
@@ -454,32 +454,34 @@ static int udp_get_file_handle(URLContext *h)
 return s->udp_fd;
 }
 
-#if HAVE_PTHREAD_CANCEL
-static void *circular_buffer_task_rx( void *_URLContext)
+#if HAVE_THREADS
+static void *circular_buffer_task_rx(void *_URLContext)
 {
 URLContext *h = _URLContext;
 UDPContext *s = h->priv_data;
-int old_cancelstate;
 
-pthread_setcancelstate(PTHREAD_CANCEL_DISABLE, &old_cancelstate);
 pthread_mutex_lock(&s->mutex);
 if (ff_socket_nonblock(s->udp_fd, 0) < 0) {
 av_log(h, AV_LOG_ERROR, "Failed to set blocking mode");
 s->circular_buffer_error = AVERROR(EIO);
 goto end;
 }
-while(1) {
-int len;
+while (!s->close_req) {
+int ret, len;
 struct sockaddr_storage addr;
 socklen_t addr_len = sizeof(addr);
 
 pthread_mutex_unlock(&s->mutex);
-/* Blocking operations are always cancellation points;
-   see "General Information" / "Thread Cancelation Overview"
-   in Single Unix. */
-pthread_setcancelstate(PTHREAD_CANCEL_ENABLE, &old_cancelstate);
+ret = ff_network_wait_fd(s->udp_fd, 0);
+if (ret < 0) {
+pthread_mutex_lock(&s->mutex);
+if (ret != AVERROR(EAGAIN) && ret != AVERROR(EINTR)) {
+s->circular_buffer_error = ret;
+goto end;
+}
+continue;
+}
 len = recvfrom(s->udp_fd, s->tmp+4, sizeof(s->tmp)-4, 0, (struct 
sockaddr *)&addr, &addr_len);
-pthread_setcancelstate(PTHREAD_CANCEL_DISABLE, &old_cancelstate);
 pthread_mutex_lock(&s->mutex);
 if (len < 0) {
 if (ff_neterrno() != AVERROR(EAGAIN) && ff_neterrno() != 
AVERROR(EINTR)) {
@@ -520,14 +522,12 @@ static void *circular_buffer_task_tx( void *_URLContext)
 {
 URLContext *h = _URLContext;
 UDPContext *s = h->priv_data;
-int old_cancelstate;
 int64_t target_timestamp = av_gettime_relative();
 int64_t start_timestamp = av_gettime_relative();
 int64_t sent_bits = 0;
 int64_t burst_interval = s->bitrate ? (s->burst_bits * 100 / 
s->bitrate) : 0;
 int64_t max_delay = s->bitrate ?  ((int64_t)h->max_packet_size * 8 * 
100 / s->bitrate + 1) : 0;
 
-pthread_setcancelstate(PTHREAD_CANCEL_DISABLE, &old_cancelstate);
 pthread_mutex_lock(&s->mutex);
 
 if (ff_socket_nonblock(s->udp_fd, 0) < 0) {
@@ -562,7 +562,6 @@ static void *circular_buffer_task_tx( void *_URLContext)
 av_fifo_generic_read(s->fifo, s->tmp, len, NULL);
 
 pthread_mutex_unlock(&s->mutex);
-pthread_setcancelstate(PTHREAD_CANCEL_ENABLE, &old_cancelstate);
 
 if (s->bitrate) {
 timestamp = av_gettime_relative();
@@ -608,7 +607,6 @@ static void *circular_buffer_task_tx( void *_URLContext)
 }
 }
 
-pthread_setcancelstate(PTHREAD_CANCEL_DISABLE, &old_cancelstate);
 pthread_mutex_lock(&s->mutex);
 }
 
@@ -667,7 +665,7 @@ static int udp_open(URLContext *h, const char *uri, int 
flags)
 /* assume if no digits were found it is a request to enable it */
 if (buf == endptr)
 s->overrun_nonfatal = 1;
-if (!HAVE_PTHREAD_CANCEL)
+if (!HAVE_THREADS)
 av_log(h, AV_LOG_WARNING,
"'overrun_nonfatal' option was set but it is not 
supported "
"on this build (pthread support is required)\n");
@@ -695,14 +693,14 @@ static int udp_open(URLContext *h, const char *uri, int 
flags)
 }
 if (av_find_info_tag(buf, sizeof(buf), "fifo_size", p)) {
 s->circu

Re: [FFmpeg-devel] [PATCH v4 1/1] avdevice/gdigrab add use_captureblt option

2020-01-15 Thread fgodt


On 2020/1/15 上午3:01, Calvin Walton wrote:

On Sat, 2020-01-11 at 17:18 +0800, fgodt...@hotmail.com wrote:

From: FgoDt 

Add use_captureblt option for disable or use CAPTUREBLT flag, when
useing the bitblt function with CAPTUREBLT may caused the Windows
mouse cursor flicker. most time we don't need this flag to capture
window
I tested on Windows 10 works fine

I have a suggestion for improving the documentation, see below.

Can you please test for me: If you use use_captureblt=0 and
draw_mouse=0 is the mouse cursor visible or not in the recorded video?

The mouse cursor not in video

+@item use_captureblt
+gdigrab use CAPTUREBLT flag to capture window or desktop by default,
which may make Windows mouse cursor flickering.
+If not capture layered window you can set value @code{0} disable
CAPTUREBLT flag, to fix Windows cursor flickering.
+Default value is @code{1}
+
+Note the value @code{1} is essential to capture layered  window

@item use_captureblt

By default, this is set to @code{1}, which means that gdigrab will use
the CAPTUREBLT flag when grabbing images of a window. With this flag
set, gdigrab will capture the entire contents of a window even if it is
covered by other windows on the screen.

If this option is set to @code{0}, the image captured will match what
you see on the screen: the contents of any windows covering the
selected window will be visible in the capture.

Depending on your Windows version and graphics settings, you may see
the mouse cursor flicker on your screen while capturing with this
option set to @code{1}. If that happens, you can disable CAPTUREBLT by
setting this option to @code{0}.

Thanks for you suggestion, but there is issue, without the CAPTUREBLT 
flag not change any thing for normal window in captured video, the worke 
same like use CAPTUREBLT flag. So the can capture window even if it is 
covered.


fgodt

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

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

Re: [FFmpeg-devel] [PATCH v4 1/1] avdevice/gdigrab add use_captureblt option

2020-01-15 Thread fgodt


On 2020/1/14 上午7:24, Carl Eugen Hoyos wrote:

Am Mo., 13. Jan. 2020 um 17:10 Uhr schrieb Derek Buitenhuis
:

On 11/01/2020 09:18, fgodt...@hotmail.com wrote:

From: FgoDt 

Add use_captureblt option for disable or use CAPTUREBLT flag, when useing the 
bitblt function with CAPTUREBLT may caused the Windows mouse cursor flicker. 
most time we don't need this flag to capture window
I tested on Windows 10 works fine

Signed-off-by: fgodt 
---
  doc/indevs.texi   |  7 +++
  libavdevice/gdigrab.c | 10 +-
  2 files changed, 16 insertions(+), 1 deletion(-)

Does it make sense to name this something like 'capature_layered_windows'?

Using the name of the flag is a bit unintuitive from a user perspective.

Not sure if "capture_layered_windows" is more intuitive than using the name
of an os flag but ...

Agree with it

Same for the description.

Shouldn't the description explain that this option helps against mouse
cursor flicker?
I think explain is necessary, most people don't know this flag will make 
mouse flicker. If user find mouse cursor flicker they will find solution 
on doc


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

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

[FFmpeg-devel] [PATCH] avutil/avcodec: expanded on channel configurations for spatial audio

2020-01-15 Thread Dylan Marcus
---
 Changelog  |  1 +
 libavcodec/aacenc.h| 16 
 libavutil/channel_layout.c |  8 ++
 libavutil/channel_layout.h | 64 ++
 4 files changed, 61 insertions(+), 28 deletions(-)

diff --git a/Changelog b/Changelog
index 2ccd2645fc..08918e95da 100644
--- a/Changelog
+++ b/Changelog
@@ -30,6 +30,7 @@ version :
 - MPEG-H 3D Audio support in mp4
 - thistogram filter
 - freezeframes filter
+- Support for Mach1 Spatial audio channel configurations
 
 
 version 4.2:
diff --git a/libavcodec/aacenc.h b/libavcodec/aacenc.h
index 5a015ca92e..a0f99680ee 100644
--- a/libavcodec/aacenc.h
+++ b/libavcodec/aacenc.h
@@ -368,6 +368,22 @@ static const AACPCEInfo aac_pce_configs[] = {
 .config_map = { 10, TYPE_CPE, TYPE_SCE, TYPE_CPE, TYPE_SCE, TYPE_CPE, 
TYPE_CPE, TYPE_CPE, TYPE_SCE, TYPE_CPE, TYPE_SCE },
 .reorder_map = { 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15 
},
 },
+{
+.layout = AV_CH_LAYOUT_MACH1SPATIAL_8,
+.num_ele = { 4, 0, 4, 0 },
+.pairing = { { 0 }, { 0 }, { 0 } },
+.index = { { 0, 1, 4, 5 }, { 0 }, { 2, 3, 6, 7 } },
+.config_map = { 8, TYPE_SCE, TYPE_SCE, TYPE_SCE, TYPE_SCE, TYPE_SCE, 
TYPE_SCE, TYPE_SCE, TYPE_SCE },
+.reorder_map = { 0, 1, 2, 3, 4, 5, 6, 7 },
+},
+{
+.layout = AV_CH_LAYOUT_MACH1SPATIAL_8_ST,
+.num_ele = { 5, 0, 4, 0 },
+.pairing = { { 0, 1 }, { 0 }, { 0 } },
+.index = { {0, 1, 4, 5, 0 }, { 0 }, { 2, 3, 6, 7 } },
+.config_map = { 9, TYPE_SCE, TYPE_SCE, TYPE_SCE, TYPE_SCE, TYPE_SCE, 
TYPE_SCE, TYPE_SCE, TYPE_SCE, TYPE_CPE },
+.reorder_map = { 0, 1, 2, 3, 4, 5, 6, 7, 8, 9 },
+},
 };
 
 /**
diff --git a/libavutil/channel_layout.c b/libavutil/channel_layout.c
index 3bd5ee29b7..37119fd023 100644
--- a/libavutil/channel_layout.c
+++ b/libavutil/channel_layout.c
@@ -62,6 +62,12 @@ static const struct channel_name channel_names[] = {
 [33] = { "SDL",   "surround direct left"  },
 [34] = { "SDR",   "surround direct right" },
 [35] = { "LFE2",  "low frequency 2"   },
+[36] = { "BFL",   "bottom front left" },
+[37] = { "BFR",   "bottom front right"},
+[38] = { "BBL",   "bottom back left"  },
+[39] = { "BBR",   "bottom back right" },
+[40] = { "STL",   "spatial stereo left"   },
+[41] = { "STR",   "spatial stereo right"  },
 };
 
 static const char *get_channel_name(int channel_id)
@@ -104,6 +110,8 @@ static const struct {
 { "octagonal",   8,  AV_CH_LAYOUT_OCTAGONAL },
 { "hexadecagonal", 16, AV_CH_LAYOUT_HEXADECAGONAL },
 { "downmix", 2,  AV_CH_LAYOUT_STEREO_DOWNMIX, },
+{ "mach1spatial-8", 8, AV_CH_LAYOUT_MACH1SPATIAL_8 },
+{ "mach1spatial-8.2", 10, AV_CH_LAYOUT_MACH1SPATIAL_8_ST},
 };
 
 static uint64_t get_channel_layout_single(const char *name, int name_len)
diff --git a/libavutil/channel_layout.h b/libavutil/channel_layout.h
index 50bb8f03c5..5bb2415155 100644
--- a/libavutil/channel_layout.h
+++ b/libavutil/channel_layout.h
@@ -64,6 +64,10 @@
 #define AV_CH_TOP_BACK_LEFT  0x8000
 #define AV_CH_TOP_BACK_CENTER0x0001
 #define AV_CH_TOP_BACK_RIGHT 0x0002
+#define AV_CH_BOTTOM_FRONT_LEFT  0x0010ULL
+#define AV_CH_BOTTOM_FRONT_RIGHT 0x0020ULL
+#define AV_CH_BOTTOM_BACK_LEFT   0x0040ULL
+#define AV_CH_BOTTOM_BACK_RIGHT  0x0080ULL
 #define AV_CH_STEREO_LEFT0x2000  ///< Stereo downmix.
 #define AV_CH_STEREO_RIGHT   0x4000  ///< See AV_CH_STEREO_LEFT.
 #define AV_CH_WIDE_LEFT  0x8000ULL
@@ -71,6 +75,8 @@
 #define AV_CH_SURROUND_DIRECT_LEFT   0x0002ULL
 #define AV_CH_SURROUND_DIRECT_RIGHT  0x0004ULL
 #define AV_CH_LOW_FREQUENCY_20x0008ULL
+#define AV_CH_SPATIAL_STEREO_LEFT0x0100ULL  ///< Non diegetic 
stereo for spatial channel formats
+#define AV_CH_SPATIAL_STEREO_RIGHT   0x0200ULL  ///< See 
AV_CH_SPATIAL_STEREO_LEFT
 
 /** Channel mask value used for AVCodecContext.request_channel_layout
 to indicate that the user requests the channel order of the decoder output
@@ -82,34 +88,36 @@
  * @defgroup channel_mask_c Audio channel layouts
  * @{
  * */
-#define AV_CH_LAYOUT_MONO  (AV_CH_FRONT_CENTER)
-#define AV_CH_LAYOUT_STEREO(AV_CH_FRONT_LEFT|AV_CH_FRONT_RIGHT)
-#define AV_CH_LAYOUT_2POINT1   
(AV_CH_LAYOUT_STEREO|AV_CH_LOW_FREQUENCY)
-#define AV_CH_LAYOUT_2_1   (AV_CH_LAYOUT_STEREO|AV_CH_BACK_CENTER)
-#define AV_CH_LAYOUT_SURROUND  (AV_CH_LAYOUT_STEREO|AV_CH_FRONT_CENTER)
-#define AV_CH_LAYOUT_3POINT1   
(AV_CH_LAYOUT_SURROUND|AV_CH_LOW_FREQUENCY)
-#define AV_CH_LAYOUT_4POINT0   
(AV_CH_LAYOUT_SURROUND|AV_CH_BACK_CENTER)
-#define AV_CH_LAYOUT_4POINT1   
(AV_CH_LAYOUT_4POINT0|AV_

Re: [FFmpeg-devel] [PATCH v4] avcodec/libvpxenc: add VP9 temporal scalability encoding option

2020-01-15 Thread Wonkap Jang
HI,
My comments are in-line.

On Tue, Jan 14, 2020 at 8:55 PM James Zern 
wrote:

> On Tue, Jan 14, 2020 at 11:07 AM Wonkap Jang
>  wrote:
> >
> > This commit reuses the configuration options for VP8 that enables
> > temporal scalability for VP9. It also adds a way to enable three
> > preset temporal structures (refer to the documentation for more
> > detail) that can be used in offline encoding.
> > ---
> >  doc/encoders.texi  |  18 ++-
> >  libavcodec/libvpxenc.c | 252 +
> >  2 files changed, 244 insertions(+), 26 deletions(-)
> >
> > [...]
> > @@ -221,10 +229,20 @@ static av_cold void dump_enc_cfg(AVCodecContext
> *avctx,
> > width, "rc_overshoot_pct:",  cfg->rc_overshoot_pct);
> >  av_log(avctx, level, "temporal layering settings\n"
> > "  %*s%u\n", width, "ts_number_layers:",
> cfg->ts_number_layers);
> > -av_log(avctx, level,
> > -   "\n  %*s", width, "ts_target_bitrate:");
> > -for (i = 0; i < VPX_TS_MAX_LAYERS; i++)
> > -av_log(avctx, level, "%u ", cfg->ts_target_bitrate[i]);
> > +if (avctx->codec_id == AV_CODEC_ID_VP8) {
> > +av_log(avctx, level,
> > +"\n  %*s", width, "ts_target_bitrate:");
>
> align this with the '(' here and below.
>
[WJ] Not sure why this was sent this way, as the lines were on the same
line in the commit. Maybe lint code running?
I will make the change to get around that.

>
> > +for (i = 0; i < VPX_TS_MAX_LAYERS; i++)
> > +av_log(avctx, level, "%u ", cfg->ts_target_bitrate[i]);
> > +}
> > +#if (VPX_ENCODER_ABI_VERSION >= 12) && CONFIG_LIBVPX_VP9_ENCODER
> > +if (avctx->codec_id == AV_CODEC_ID_VP9) {
> > +av_log(avctx, level,
> > +"\n  %*s", width, "layer_target_bitrate:");
>
> trailing whitespace
>
[WJ] Will do.

>
> > +for (i = 0; i < VPX_TS_MAX_LAYERS; i++)
> > +av_log(avctx, level, "%u ", cfg->layer_target_bitrate[i]);
> > +}
> > +#endif
> >  av_log(avctx, level, "\n");
> >  av_log(avctx, level,
> > "\n  %*s", width, "ts_rate_decimator:");
> > @@ -346,6 +364,8 @@ static av_cold int vpx_free(AVCodecContext *avctx)
> >  }
> >  #endif
> >
> > +av_freep(&ctx->ts_layer_flags);
> > +
> >  vpx_codec_destroy(&ctx->encoder);
> >  if (ctx->is_alpha) {
> >  vpx_codec_destroy(&ctx->encoder_alpha);
> > @@ -370,23 +390,153 @@ static void vp8_ts_parse_int_array(int *dest,
> char *value, size_t value_len, int
> >  }
> >  }
> >
> > -static int vp8_ts_param_parse(struct vpx_codec_enc_cfg *enccfg, char
> *key, char *value)
> > +static void set_temporal_layer_pattern(int layering_mode,
> > +   vpx_codec_enc_cfg_t *cfg,
> > +   int *layer_flags,
> > +   int *flag_periodicity)
> > +{
> > +switch (layering_mode) {
> > +case 2: {
> > +/**
> > + * 2-layers, 2-frame period.
> > + */
> > +int ids[2] = { 0, 1 };
> > +cfg->ts_periodicity = 2;
> > +*flag_periodicity = 2;
> > +cfg->ts_number_layers = 2;
> > +cfg->ts_rate_decimator[0] = 2;
> > +cfg->ts_rate_decimator[1] = 1;
> > +memcpy(cfg->ts_layer_id, ids, sizeof(ids));
> > +
> > +layer_flags[0] =
> > + VP8_EFLAG_NO_REF_GF | VP8_EFLAG_NO_REF_ARF |
> > + VP8_EFLAG_NO_UPD_GF | VP8_EFLAG_NO_UPD_ARF;
> > +layer_flags[1] =
> > +VP8_EFLAG_NO_UPD_ARF | VP8_EFLAG_NO_UPD_GF |
> > +VP8_EFLAG_NO_UPD_LAST |
> > +VP8_EFLAG_NO_REF_ARF | VP8_EFLAG_NO_REF_GF;
> > +break;
> > +}
> > +case 3: {
> > +/**
> > + * 3-layers structure with one reference frame.
> > + *  This works same as temporal_layering_mode 3.
> > + *
> > + * 3-layers, 4-frame period.
> > + */
> > +int ids[4] = { 0, 2, 1, 2 };
> > +cfg->ts_periodicity = 4;
> > +*flag_periodicity = 4;
> > +cfg->ts_number_layers = 3;
> > +cfg->ts_rate_decimator[0] = 4;
> > +cfg->ts_rate_decimator[1] = 2;
> > +cfg->ts_rate_decimator[2] = 1;
> > +memcpy(cfg->ts_layer_id, ids, sizeof(ids));
> > +
> > +/**
> > + * 0=L, 1=GF, 2=ARF,
>
> my point with the earlier comment was that you document 3 indices, but
> set 4. if [3] won't be used in this case then the assignment could be
> removed.
>
[WJ] the ids[] and layer_flags[] are indexed up to the frame# in
ts_periodicity..
so that goes from 0-3 (period of 4), whereas ts_rate_decimator[] is indexed
by the temporal layer id itself (ids[]) which goes from 0 to 2. Am I
missing something?


> > [...]
> > +
> > +static int vpx_ts_param_parse(VPxContext *ctx,
> > +  struct vpx_codec_enc_cfg *enccfg,
> > +  char *key, char *value,
> > +  const enum AVCodecID cod

[FFmpeg-devel] [PATCH v2] doc/v4l2_m2m: Add documentation

2020-01-15 Thread Andriy Gelman
From: Andriy Gelman 

Signed-off-by: Andriy Gelman 
---
 doc/decoders.texi | 27 +++
 doc/encoders.texi | 42 ++
 2 files changed, 69 insertions(+)

diff --git a/doc/decoders.texi b/doc/decoders.texi
index f18226b3504..7827a055408 100644
--- a/doc/decoders.texi
+++ b/doc/decoders.texi
@@ -86,6 +86,33 @@ AVS2-P2/IEEE1857.4 video decoder wrapper.
 
 This decoder allows libavcodec to decode AVS2 streams with davs2 library.
 
+@section v4l2m2m
+
+libavcodec supports a set of v4l2m2m wrappers for interfacing with
+hardware decoders. Depending on the hardware's capabilties the following 
decoders may be selected:
+h264, hevc, mpeg1, mpeg2, mpeg4, h263, vc1, vp8, and vp9.
+
+To use a specifix decoder append a  _v4l2m2m suffix. For example to select h264
+decoder use:
+@example
+ffmpeg -codec:v h264_v4l2m2m -i INPUT OUTPUT
+@end example
+
+The following options are supported:
+@table @option
+@item num_output_buffers
+Number of memory mapped buffers to store the input packets.
+This value is only a suggestion to the hardware device. The device will 
attempt to
+allocate the number of buffers, but the actual value may be smaller/larger and
+ultimately depends on the device. The default for the option is 16, minimum is
+6, and any large value (representable by an int) is accepted for the max.
+
+@item num_capture_buffers
+Number of memory mapped buffers to store the decompressed frames. The 
allocation
+description is the same as above. Default is 20, minimum is 20, and any large
+value (representable by an int) is accepted for the max.
+@end table
+
 @c man end VIDEO DECODERS
 
 @chapter Audio Decoders
diff --git a/doc/encoders.texi b/doc/encoders.texi
index 61e674cf968..a600e76b1b9 100644
--- a/doc/encoders.texi
+++ b/doc/encoders.texi
@@ -3117,6 +3117,48 @@ required to produce a stream usable with all decoders.
 
 @end table
 
+@section v4l2m2m
+
+libavcodec supports a set of v4l2m2m wrappers for interfacing with hardware 
encoders.
+Depending on the hardware's capabilities the following encoders may be 
selected:
+mpeg4, h263, h264, hevc, and vp8.
+
+To use a specific encoder append _v4l2m2m suffix. For example to select h264 
use:
+@example
+ffmpeg -i INPUT [-pix_fmt pixfmt] -codec:v h264_v4l2m2m OUTPUT
+@end example
+In some cases, it may be necessary to insert a pixel format conversion with
+@code{-pix_fmt}. This is required if the pixel format of the input does not
+match the format of the encoder. If there is a mismatch, libavcodec will
+exit and specify the required pixfmt to use.
+
+The following options are supported:
+@table @option
+@item num_output_buffers
+Number of memory mapped buffers to store the input frames.
+This value is only a suggestion to the hardware device. The device will 
attempt to
+allocate the number of buffers, but the actual value may be smaller/larger and
+ultimately depends on the device. The default for the option is 16, minimum is
+6, and any large value (representable by an int) is accepted for the max.
+
+@item num_capture_buffers
+Number of memory mapped buffers to store the compressed packets. The allocation
+description is the same as above. Default is 4, minimum is 4, and any large
+value (representable by an int) is accepted for the max.
+@end table
+
+Standard libavcodec options that can be set are:
+@itemize
+@item
+@option{g} / @option{gop_size}
+@item
+@option{qpel}
+@item
+@option{qmin}
+@item
+@option{qmax}
+@end itemize
+
 @section vc2
 
 SMPTE VC-2 (previously BBC Dirac Pro). This codec was primarily aimed at
-- 
2.24.1

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

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

[FFmpeg-devel] [PATCH 1/2] avformat/movenc, segafilmenc: Remove unnecessary avio_tell()

2020-01-15 Thread Andreas Rheinhardt
When the faststart option for the mov/mp4 muxer is used, the current
position (i.e. the size of the already written data pre-shifting) was
evaluated twice: First in an initialization and then again later,
overwriting the first value without having ever touched it. So remove
the initialization.

Also, the clone of this code in the Sega FILM muxer behaves the same and
has been treated the same.

Signed-off-by: Andreas Rheinhardt 
---
 libavformat/movenc.c  | 2 +-
 libavformat/segafilmenc.c | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/libavformat/movenc.c b/libavformat/movenc.c
index a2cfc59b89..282d14ab1a 100644
--- a/libavformat/movenc.c
+++ b/libavformat/movenc.c
@@ -6718,7 +6718,7 @@ static int shift_data(AVFormatContext *s)
 {
 int ret = 0, moov_size;
 MOVMuxContext *mov = s->priv_data;
-int64_t pos, pos_end = avio_tell(s->pb);
+int64_t pos, pos_end;
 uint8_t *buf, *read_buf[2];
 int read_buf_id = 0;
 int read_size[2];
diff --git a/libavformat/segafilmenc.c b/libavformat/segafilmenc.c
index 6b66c68328..93c482ef7d 100644
--- a/libavformat/segafilmenc.c
+++ b/libavformat/segafilmenc.c
@@ -209,7 +209,7 @@ static int film_init(AVFormatContext *format_context)
 static int shift_data(AVFormatContext *format_context, int64_t shift_size)
 {
 int ret = 0;
-int64_t pos, pos_end = avio_tell(format_context->pb);
+int64_t pos, pos_end;
 uint8_t *buf, *read_buf[2];
 int read_buf_id = 0;
 int read_size[2];
-- 
2.20.1

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

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

[FFmpeg-devel] [PATCH 2/2] avformat/flvenc: Avoid unnecessary seek

2020-01-15 Thread Andreas Rheinhardt
When shifting the already written data in order to write the keyframe
index, the flv muxer would first store the pre-shift size, then
calculate how big the index will be eventually, then perform some seeks
to update some size fields, then seek back to the end of the file to get
the new position, followed by a seek to the position where writing will
really start. Seeking back to the (already known) end position (that is
actually used to perform this seek) to get the end position is of course
unnecessary. It has been removed.

Signed-off-by: Andreas Rheinhardt 
---
 libavformat/flvenc.c | 7 ++-
 1 file changed, 2 insertions(+), 5 deletions(-)

diff --git a/libavformat/flvenc.c b/libavformat/flvenc.c
index 1aaf0333ca..5cf3ce8a1a 100644
--- a/libavformat/flvenc.c
+++ b/libavformat/flvenc.c
@@ -580,7 +580,7 @@ static int shift_data(AVFormatContext *s)
 int n = 0;
 int64_t metadata_size = 0;
 FLVContext *flv = s->priv_data;
-int64_t pos, pos_end = avio_tell(s->pb);
+int64_t pos, pos_end = avio_tell(s->pb); /* Save the pre-shift size. */
 uint8_t *buf, *read_buf[2];
 int read_buf_id = 0;
 int read_size[2];
@@ -608,7 +608,6 @@ static int shift_data(AVFormatContext *s)
 
 avio_seek(s->pb, flv->metadata_totalsize_pos, SEEK_SET);
 avio_wb32(s->pb, flv->metadata_totalsize + 11 + metadata_size);
-avio_seek(s->pb, pos_end, SEEK_SET);
 
 /* Shift the data: the AVIO context of the output can only be used for
  * writing, so we re-open the same output, but for reading. It also avoids
@@ -621,9 +620,7 @@ static int shift_data(AVFormatContext *s)
 goto end;
 }
 
-/* mark the end of the shift to up to the last data we wrote, and get ready
- * for writing */
-pos_end = avio_tell(s->pb);
+/* Get ready for writing. */
 avio_seek(s->pb, flv->keyframes_info_offset + metadata_size, SEEK_SET);
 
 /* start reading at where the keyframe index information will be placed */
-- 
2.20.1

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

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

Re: [FFmpeg-devel] [PATCH v2] doc/v4l2_m2m: Add documentation

2020-01-15 Thread Gyan



On 16-01-2020 09:44 am, Andriy Gelman wrote:

From: Andriy Gelman 

Signed-off-by: Andriy Gelman 
---
  doc/decoders.texi | 27 +++
  doc/encoders.texi | 42 ++
  2 files changed, 69 insertions(+)

diff --git a/doc/decoders.texi b/doc/decoders.texi
index f18226b3504..7827a055408 100644
--- a/doc/decoders.texi
+++ b/doc/decoders.texi
@@ -86,6 +86,33 @@ AVS2-P2/IEEE1857.4 video decoder wrapper.
  
  This decoder allows libavcodec to decode AVS2 streams with davs2 library.
  
+@section v4l2m2m

+
+libavcodec supports a set of v4l2m2m wrappers for interfacing with
+hardware decoders. Depending on the hardware's capabilties the following 
decoders may be selected:
+h264, hevc, mpeg1, mpeg2, mpeg4, h263, vc1, vp8, and vp9.


capabilties --> capabilities




+
+To use a specifix decoder append a  _v4l2m2m suffix. For example to select h264


specifix --> specific


+decoder use:
+@example
+ffmpeg -codec:v h264_v4l2m2m -i INPUT OUTPUT
+@end example
+
+The following options are supported:
+@table @option
+@item num_output_buffers
+Number of memory mapped buffers to store the input packets.
+This value is only a suggestion to the hardware device. The device will 
attempt to
+allocate the number of buffers, but the actual value may be smaller/larger and
+ultimately depends on the device. The default for the option is 16, minimum is
+6, and any large value (representable by an int) is accepted for the max.
+
+@item num_capture_buffers
+Number of memory mapped buffers to store the decompressed frames. The 
allocation
+description is the same as above. Default is 20, minimum is 20, and any large
+value (representable by an int) is accepted for the max.


Restate the description, don't reference another option entry, since in 
theory, more may be inserted or shuffled around.


For both options, what's the significance and tradeoff? Latency?


+@end table
+
  @c man end VIDEO DECODERS
  
  @chapter Audio Decoders

diff --git a/doc/encoders.texi b/doc/encoders.texi
index 61e674cf968..a600e76b1b9 100644
--- a/doc/encoders.texi
+++ b/doc/encoders.texi
@@ -3117,6 +3117,48 @@ required to produce a stream usable with all decoders.
  
  @end table
  
+@section v4l2m2m

+
+libavcodec supports a set of v4l2m2m wrappers for interfacing with hardware 
encoders.
+Depending on the hardware's capabilities the following encoders may be 
selected:
+mpeg4, h263, h264, hevc, and vp8.
+
+To use a specific encoder append _v4l2m2m suffix. For example to select h264 
use:
+@example
+ffmpeg -i INPUT [-pix_fmt pixfmt] -codec:v h264_v4l2m2m OUTPUT
+@end example
+In some cases, it may be necessary to insert a pixel format conversion with
+@code{-pix_fmt}. This is required if the pixel format of the input does not
+match the format of the encoder. If there is a mismatch, libavcodec will
+exit and specify the required pixfmt to use.
+
+The following options are supported:
+@table @option
+@item num_output_buffers
+Number of memory mapped buffers to store the input frames.
+This value is only a suggestion to the hardware device. The device will 
attempt to
+allocate the number of buffers, but the actual value may be smaller/larger and
+ultimately depends on the device. The default for the option is 16, minimum is
+6, and any large value (representable by an int) is accepted for the max.
+
+@item num_capture_buffers
+Number of memory mapped buffers to store the compressed packets. The allocation
+description is the same as above. Default is 4, minimum is 4, and any large
+value (representable by an int) is accepted for the max.


Restate the description, don't reference another option entry.

 Significance and tradeoff?


+@end table
+
+Standard libavcodec options that can be set are:
+@itemize
+@item
+@option{g} / @option{gop_size}
+@item
+@option{qpel}
+@item
+@option{qmin}
+@item
+@option{qmax}


Where in the code is the lavc qmin/qmax applied?

You may note that bitrate is also read.


+@end itemize
+
  @section vc2
  
  SMPTE VC-2 (previously BBC Dirac Pro). This codec was primarily aimed at


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

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

Re: [FFmpeg-devel] [PATCH 2/9] swscale: Add swscale input support for Y210LE

2020-01-15 Thread Fu, Linjie
> -Original Message-
> From: ffmpeg-devel  On Behalf Of
> Carl Eugen Hoyos
> Sent: Thursday, January 16, 2020 02:30
> To: FFmpeg development discussions and patches  de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH 2/9] swscale: Add swscale input support
> for Y210LE
> 
> Am Mi., 15. Jan. 2020 um 07:59 Uhr schrieb Linjie Fu :
> >
> > Add swscale input support for Y210LE, output support and fate
> > test could be added later if there is requirement for software
> > CSC to this packed format.
> 
> Please confirm that this works as expected on big-endian hardware.
> 
If I understood correctly,  the concern is whether it works for Y210 software 
scale
on big-endian hardware, and whether it would break fate.

For Y210 on big-endian hardware, it'll be defined as Y210BE in pixfmt.h:
#define AV_PIX_FMT_Y210   AV_PIX_FMT_NE(Y210BE,  Y210LE)

And in the query of format_entries[] in utils.c, AV_PIX_FMT_Y210BE is not
declared to have the capability to support Input or Output in swscale. 

So Y210 software scale is not going to be supported on big-endian hardware.

Hence this won't break fate on big-endian hardware for Y210 IMHO, because this 
patch
didn't declare it has the capability for either input or output support.

If there is something wrong with my understanding, please correct me.

Thanks.



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

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

Re: [FFmpeg-devel] [PATCH V7 1/2] libswscale/x86/yuv2rgb: Change inline assembly into nasm code

2020-01-15 Thread Fu, Ting


> -Original Message-
> From: ffmpeg-devel  On Behalf Of
> Michael Niedermayer
> Sent: Wednesday, January 15, 2020 05:55 AM
> To: FFmpeg development discussions and patches 
> Subject: Re: [FFmpeg-devel] [PATCH V7 1/2] libswscale/x86/yuv2rgb: Change
> inline assembly into nasm code
> 
> On Fri, Jan 10, 2020 at 01:38:15AM +0800, Ting Fu wrote:
> > Signed-off-by: Ting Fu 
> > ---
> > V7:
> > Fix compile issue when user configure with --disable-mmx.
> > Fix issue when running ./ffmpeg with --cpuflags mmx/ssse3.
> > Adjust the SIMD verify logic in libswscale/x86/yuv2rgb.c
> >
> >  libswscale/x86/Makefile   |   1 +
> >  libswscale/x86/swscale.c  |  16 +-
> >  libswscale/x86/yuv2rgb.c  |  66 ++---
> >  libswscale/x86/yuv2rgb_template.c | 467 ++
> >  libswscale/x86/yuv_2_rgb.asm  | 270 +
> >  5 files changed, 405 insertions(+), 415 deletions(-)  create mode
> > 100644 libswscale/x86/yuv_2_rgb.asm
> 
> The commit message seems a bit terse
> I think it should say if the sequence of instructions is unchanged and if it 
> was
> benchmaked. If its the same speed, when the code is run the commit message
> should say that too
> 
> the principle of this (inline -> nasm) is fine of course.
> 
> 
[...]
> > -static inline int RENAME(yuv420_rgb16)(SwsContext *c, const uint8_t *src[],
> > -   int srcStride[],
> > -   int srcSliceY, int srcSliceH,
> > -   uint8_t *dst[], int dstStride[])
> > +static int RENAME(yuv420_rgb16)(SwsContext *c, const uint8_t *src[],
> > +   int srcStride[],
> > +   int srcSliceY, int 
> > srcSliceH,
> > +   uint8_t *dst[], int
> > +dstStride[])
> 
> maybe the removial of inline should be a seperate patch also there is the
> question why these wraper functions exist These do change from a a "free thing
> in inline asm" to a call overhead with C->NASM
> 
Hi Michael,

The wrapper functions initiate some variables and contain one 'for cycle'. The 
variable initiation needs to access to the 'c->dstW', furthermore macro 
SWS_MAX_ FILTER_SIZE is needed. Which means extra work and much more NASM code.
If you still prefer to do all the things in assembly, I can change from 
'C->NASM' to 'call NASM function directly' in another further patch( for 
current patch easier to review).
Or in my opinion, the cost in C->NASM can be ignored, and the initiation work 
looks clearer in C, just let it be what it is now.
What do you think?

Thank you,
Ting Fu

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

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

Re: [FFmpeg-devel] [PATCH v6] avformat/mov: Memory optimization with QuickTime/MP4

2020-01-15 Thread Jörg Beckmann
Hi,

is there anything I can do to get this patch applied?

Cheers,
Jörg

> -Ursprüngliche Nachricht-
> Von: ffmpeg-devel  Im Auftrag von Jörg
> Beckmann
> Gesendet: Mittwoch, 8. Januar 2020 15:49
> An: FFmpeg development discussions and patches 
> Betreff: Re: [FFmpeg-devel] [PATCH v6] avformat/mov: Memory optimization with
> QuickTime/MP4
> 
> > -Ursprüngliche Nachricht-
> > Von: ffmpeg-devel  Im Auftrag von
> > Moritz Barsnick
> > Gesendet: Mittwoch, 8. Januar 2020 15:25
> > An: FFmpeg development discussions and patches
> > 
> > Betreff: [SCISYS Possible Spam] Re: [FFmpeg-devel] [PATCH v6]
> avformat/mov:
> > Memory optimization with QuickTime/MP4
> >
> > On Wed, Jan 08, 2020 at 13:26:35 +, Jörg Beckmann wrote:
> > > Invents a new option "discard_fragments" for the MP4/Quicktime/MOV
> decoder.
> >
> > Strictly speaking, it's a demuxer and not a decoder. ;-)
> >
> > > If this option is set to "on", old fragments are discarded as far as
> > > possible on each call to switch_root(). If set to "off", nothing
> > > changes at all. If set to "auto" (the default), this function is
> > > turned on for streams containing only audio.
> >
> > Since it's new option, and possibly even a behavioral change, I
> > suggest bumping libavformat's MICRO version with the same commit.
> >
> > > +{ "discard_fragments", "Discard fragments after they have been
> > > + read to
> > support live streams.", OFFSET(discard_fragments),
> > > +AV_OPT_TYPE_INT, { .i64 = MOV_DISCARD_AUTO },
> > MOV_DISCARD_AUTO, MOV_DISCARD_ON, FLAGS, "discard_fragments"},
> > > +{ "auto", "Switch on for audio only streams", 0,
> > > + AV_OPT_TYPE_CONST,
> > {.i64 = MOV_DISCARD_AUTO}, INT_MIN, INT_MAX, FLAGS,
> "discard_fragments"
> > },
> > > +{ "off",  "Switch off",   0, 
> > > AV_OPT_TYPE_CONST, {.i64 =
> > MOV_DISCARD_OFF},  INT_MIN, INT_MAX, FLAGS, "discard_fragments" },
> > > +{ "on",   "Switch on",0, 
> > > AV_OPT_TYPE_CONST, {.i64 =
> > MOV_DISCARD_ON},   INT_MIN, INT_MAX, FLAGS, "discard_fragments" },
> > >  { NULL },
> >
> > I would have suggest you add documentation to doc/demuxers.texi, but
> > since most of mov's options don't seem to be documented there...
> > *sigh*.
> 
> I'll write some documentation when the patch is applied eventually. I just 
> don't want
> to write it more than once. And this version of the patch changed the options 
> as
> suggested by Carl Eugen.
> 
> > Moritz
> 
> Jörg
> 
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org 
> with
> subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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