[FFmpeg-devel] [PATCH] avcodec/vp3: propagate error codes

2020-04-04 Thread Peter Ross
throughout vp3_decode_frame the error code was being captured (ret) but never 
returned.
---
 libavcodec/vp3.c | 22 +++---
 1 file changed, 11 insertions(+), 11 deletions(-)

diff --git a/libavcodec/vp3.c b/libavcodec/vp3.c
index d53dd87029..2ae54255c6 100644
--- a/libavcodec/vp3.c
+++ b/libavcodec/vp3.c
@@ -2741,7 +2741,7 @@ static int vp3_decode_frame(AVCodecContext *avctx,
 s->current_frame.f->pict_type = s->keyframe ? AV_PICTURE_TYPE_I
 : AV_PICTURE_TYPE_P;
 s->current_frame.f->key_frame = s->keyframe;
-if (ff_thread_get_buffer(avctx, >current_frame, AV_GET_BUFFER_FLAG_REF) 
< 0)
+if ((ret = ff_thread_get_buffer(avctx, >current_frame, 
AV_GET_BUFFER_FLAG_REF)) < 0)
 goto error;
 
 if (!s->edge_emu_buffer)
@@ -2793,8 +2793,8 @@ static int vp3_decode_frame(AVCodecContext *avctx,
"vp3: first frame not a keyframe\n");
 
 s->golden_frame.f->pict_type = AV_PICTURE_TYPE_I;
-if (ff_thread_get_buffer(avctx, >golden_frame,
- AV_GET_BUFFER_FLAG_REF) < 0)
+if ((ret = ff_thread_get_buffer(avctx, >golden_frame,
+ AV_GET_BUFFER_FLAG_REF)) < 0)
 goto error;
 ff_thread_release_buffer(avctx, >last_frame);
 if ((ret = ff_thread_ref_frame(>last_frame,
@@ -2808,39 +2808,39 @@ static int vp3_decode_frame(AVCodecContext *avctx,
 ff_thread_finish_setup(avctx);
 
 if (s->version < 2) {
-if (unpack_superblocks(s, )) {
+if ((ret = unpack_superblocks(s, )) < 0) {
 av_log(s->avctx, AV_LOG_ERROR, "error in unpack_superblocks\n");
 goto error;
 }
 #if CONFIG_VP4_DECODER
 } else {
-if (vp4_unpack_macroblocks(s, )) {
+if ((ret = vp4_unpack_macroblocks(s, )) < 0) {
 av_log(s->avctx, AV_LOG_ERROR, "error in 
vp4_unpack_macroblocks\n");
 goto error;
 }
 #endif
 }
-if (unpack_modes(s, )) {
+if ((ret = unpack_modes(s, )) < 0) {
 av_log(s->avctx, AV_LOG_ERROR, "error in unpack_modes\n");
 goto error;
 }
-if (unpack_vectors(s, )) {
+if (ret = unpack_vectors(s, )) {
 av_log(s->avctx, AV_LOG_ERROR, "error in unpack_vectors\n");
 goto error;
 }
-if (unpack_block_qpis(s, )) {
+if ((ret = unpack_block_qpis(s, )) < 0) {
 av_log(s->avctx, AV_LOG_ERROR, "error in unpack_block_qpis\n");
 goto error;
 }
 
 if (s->version < 2) {
-if (unpack_dct_coeffs(s, )) {
+if ((ret = unpack_dct_coeffs(s, )) < 0) {
 av_log(s->avctx, AV_LOG_ERROR, "error in unpack_dct_coeffs\n");
 goto error;
 }
 #if CONFIG_VP4_DECODER
 } else {
-if (vp4_unpack_dct_coeffs(s, )) {
+if ((ret = vp4_unpack_dct_coeffs(s, )) < 0) {
 av_log(s->avctx, AV_LOG_ERROR, "error in vp4_unpack_dct_coeffs\n");
 goto error;
 }
@@ -2892,7 +2892,7 @@ error:
 if (!HAVE_THREADS || !(s->avctx->active_thread_type & FF_THREAD_FRAME))
 av_frame_unref(s->current_frame.f);
 
-return -1;
+return ret;
 }
 
 static int read_huffman_tree(AVCodecContext *avctx, GetBitContext *gb)
-- 
2.20.1

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


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

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

[FFmpeg-devel] [PATCH v12] libavcodec/jpeg2000dec.c: Add support for PPT marker

2020-04-04 Thread gautamramk
From: Gautam Ramakrishnan 

This patch adds functional changes to support the
PPT marker. This patch fixes bug ticket #4610.
---
 libavcodec/jpeg2000dec.c | 88 +++-
 1 file changed, 77 insertions(+), 11 deletions(-)

diff --git a/libavcodec/jpeg2000dec.c b/libavcodec/jpeg2000dec.c
index 732d88e6fc..7033417c65 100644
--- a/libavcodec/jpeg2000dec.c
+++ b/libavcodec/jpeg2000dec.c
@@ -83,6 +83,10 @@ typedef struct Jpeg2000Tile {
 Jpeg2000QuantStyle  qntsty[4];
 Jpeg2000POC poc;
 Jpeg2000TileParttile_part[32];
+uint8_t has_ppt;// whether this tile has a ppt 
marker
+uint8_t *packed_headers;// contains packed headers. 
Used only along with PPT marker
+int packed_headers_size;// size in bytes of the packed 
headers
+GetByteContext  packed_headers_stream;  // byte context corresponding 
to packed headers
 uint16_t tp_idx;// Tile-part index
 int coord[2][2];// border coordinates {{x0, x1}, {y0, 
y1}}
 } Jpeg2000Tile;
@@ -855,6 +859,37 @@ static int get_plt(Jpeg2000DecoderContext *s, int n)
 return 0;
 }
 
+static int get_ppt(Jpeg2000DecoderContext *s, int n)
+{
+Jpeg2000Tile *tile;
+
+if (s->curtileno < 0)
+return AVERROR_INVALIDDATA;
+
+tile = >tile[s->curtileno];
+if (tile->tp_idx != 0) {
+av_log(s->avctx, AV_LOG_ERROR,
+   "PPT marker can occur only on first tile part of a tile.\n");
+return AVERROR_INVALIDDATA;
+}
+
+tile->has_ppt = 1;  // this tile has a ppt marker
+/*Zppt = */ bytestream2_get_byte(>g); // Zppt is skipped and not used
+if (!tile->packed_headers)
+tile->packed_headers = av_malloc(n - 3);
+else
+tile->packed_headers = av_realloc(tile->packed_headers,
+  tile->packed_headers_size + n - 3);
+if (!tile->packed_headers)
+return AVERROR(ENOMEM);
+memcpy(tile->packed_headers + tile->packed_headers_size,
+   s->g.buffer, n - 3);
+tile->packed_headers_size += n - 3;
+bytestream2_skip(>g, n - 3);
+
+return 0;
+}
+
 static int init_tile(Jpeg2000DecoderContext *s, int tileno)
 {
 int compno;
@@ -927,6 +962,19 @@ static int getlblockinc(Jpeg2000DecoderContext *s)
 return res;
 }
 
+static inline void select_stream(Jpeg2000DecoderContext *s, Jpeg2000Tile *tile,
+ int *tp_index)
+{
+s->g = tile->tile_part[*tp_index].tpg;
+if (bytestream2_get_bytes_left(>g) == 0 && s->bit_index == 8) {
+if (*tp_index < FF_ARRAY_ELEMS(tile->tile_part) - 1) {
+s->g = tile->tile_part[++(*tp_index)].tpg;
+}
+}
+if (bytestream2_peek_be32(>g) == JPEG2000_SOP_FIXED_BYTES)
+bytestream2_skip(>g, JPEG2000_SOP_BYTE_LENGTH);
+}
+
 static int jpeg2000_decode_packet(Jpeg2000DecoderContext *s, Jpeg2000Tile 
*tile, int *tp_index,
   Jpeg2000CodingStyle *codsty,
   Jpeg2000ResLevel *rlevel, int precno,
@@ -938,19 +986,15 @@ static int jpeg2000_decode_packet(Jpeg2000DecoderContext 
*s, Jpeg2000Tile *tile,
 if (layno < rlevel->band[0].prec[precno].decoded_layers)
 return 0;
 rlevel->band[0].prec[precno].decoded_layers = layno + 1;
-
-if (bytestream2_get_bytes_left(>g) == 0 && s->bit_index == 8) {
-if (*tp_index < FF_ARRAY_ELEMS(tile->tile_part) - 1) {
-s->g = tile->tile_part[++(*tp_index)].tpg;
-}
-}
-
-if (bytestream2_peek_be32(>g) == JPEG2000_SOP_FIXED_BYTES)
-bytestream2_skip(>g, JPEG2000_SOP_BYTE_LENGTH);
+// Select stream to read from
+if (tile->has_ppt)
+s->g = tile->packed_headers_stream;
+else
+select_stream(s, tile, tp_index);
 
 if (!(ret = get_bits(s, 1))) {
 jpeg2000_flush(s);
-return 0;
+goto skip_data;
 } else if (ret < 0)
 return ret;
 
@@ -1056,6 +1100,11 @@ static int jpeg2000_decode_packet(Jpeg2000DecoderContext 
*s, Jpeg2000Tile *tile,
 av_log(s->avctx, AV_LOG_ERROR, "EPH marker not found. instead 
%X\n", bytestream2_peek_be32(>g));
 }
 
+// Save state of stream
+if (tile->has_ppt) {
+tile->packed_headers_stream = s->g;
+select_stream(s, tile, tp_index);
+}
 for (bandno = 0; bandno < rlevel->nbands; bandno++) {
 Jpeg2000Band *band = rlevel->band + bandno;
 Jpeg2000Prec *prec = band->prec + precno;
@@ -1097,6 +1146,15 @@ static int jpeg2000_decode_packet(Jpeg2000DecoderContext 
*s, Jpeg2000Tile *tile,
 av_freep(>lengthinc);
 }
 }
+// Save state of stream
+tile->tile_part[*tp_index].tpg = s->g;
+return 0;
+
+skip_data:
+if (tile->has_ppt)
+tile->packed_headers_stream = s->g;
+else
+tile->tile_part[*tp_index].tpg = s->g;
 return 0;
 }
 
@@ -1929,6 +1987,11 @@ 

Re: [FFmpeg-devel] [PATCH]lavfi/telecine: Mark telecined frames as interlaced

2020-04-04 Thread Andriy Gelman
On Sun, 05. Apr 02:05, Carl Eugen Hoyos wrote:
> Am So., 5. Apr. 2020 um 01:02 Uhr schrieb Carl Eugen Hoyos 
> :
> >
> > Am Sa., 4. Apr. 2020 um 00:44 Uhr schrieb Carl Eugen Hoyos 
> > :
> > >
> > > Am Sa., 4. Apr. 2020 um 00:40 Uhr schrieb James Almer :
> > > >
> > > > On 4/3/2020 6:37 PM, Carl Eugen Hoyos wrote:
> > > > > Am Fr., 3. Apr. 2020 um 23:19 Uhr schrieb Carl Eugen Hoyos 
> > > > > :
> > > > >
> > > > >> Attached patch marks actually telecined frames as interlaced,
> > > > >> other frames as progressive.
> > > > >
> > > > > New patch with changes to fate attached.
> > > > >
> > > > > Please comment, Carl Eugen
> > > >
> > > > Those yadif tests look wrong. The patch shouldn't affect them.
> > >
> > > Clearly, thank you!
> > >
> > > New patch attached, it should now only change the telecined
> > > frames and leave the other frames as they are, the setfield
> > > filter can be used to force a progressive setting for them.
> >
> > New patch attached that also sets top_field_first
> 
> Which had the effect that fate is correct again, new patch attached.
> 

FYI
Currently patchwork does some filtering on the subject line to understand when
an attachment in a reply-to message is a new version of a patch. 

If you would like patchwork to treat the attachment as a new version, then
pls remove the "Re: " in the subject line of the reply message. This will create
a new entry for the patch.
Otherwise the reply is treated as part of the existing thread. 

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

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

Re: [FFmpeg-devel] [PATCH]lavfi/telecine: Mark telecined frames as interlaced

2020-04-04 Thread Carl Eugen Hoyos
Am So., 5. Apr. 2020 um 01:02 Uhr schrieb Carl Eugen Hoyos :
>
> Am Sa., 4. Apr. 2020 um 00:44 Uhr schrieb Carl Eugen Hoyos 
> :
> >
> > Am Sa., 4. Apr. 2020 um 00:40 Uhr schrieb James Almer :
> > >
> > > On 4/3/2020 6:37 PM, Carl Eugen Hoyos wrote:
> > > > Am Fr., 3. Apr. 2020 um 23:19 Uhr schrieb Carl Eugen Hoyos 
> > > > :
> > > >
> > > >> Attached patch marks actually telecined frames as interlaced,
> > > >> other frames as progressive.
> > > >
> > > > New patch with changes to fate attached.
> > > >
> > > > Please comment, Carl Eugen
> > >
> > > Those yadif tests look wrong. The patch shouldn't affect them.
> >
> > Clearly, thank you!
> >
> > New patch attached, it should now only change the telecined
> > frames and leave the other frames as they are, the setfield
> > filter can be used to force a progressive setting for them.
>
> New patch attached that also sets top_field_first

Which had the effect that fate is correct again, new patch attached.

Please comment, Carl Eugen
From cd2f7b4336c1d0b786ba613d525830ff152788a3 Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos 
Date: Sun, 5 Apr 2020 01:00:44 +0200
Subject: [PATCH] lavfi/telecine: Mark telecined frames as interlaced.

---
 libavfilter/vf_telecine.c|  8 
 tests/ref/fate/filter-pixfmts-fieldmatch | 10 +-
 tests/ref/fate/filter-pixfmts-pullup | 24 
 3 files changed, 25 insertions(+), 17 deletions(-)

diff --git a/libavfilter/vf_telecine.c b/libavfilter/vf_telecine.c
index 62599a7a3a..ff8151dfc9 100644
--- a/libavfilter/vf_telecine.c
+++ b/libavfilter/vf_telecine.c
@@ -207,6 +207,8 @@ static int filter_frame(AVFilterLink *inlink, AVFrame *inpicref)
 s->stride[i],
 (s->planeheight[i] - !s->first_field + 1) / 2);
 }
+s->frame[nout]->interlaced_frame = 1;
+s->frame[nout]->top_field_first  = !s->first_field;
 nout++;
 len--;
 s->occupied = 0;
@@ -220,6 +222,8 @@ static int filter_frame(AVFilterLink *inlink, AVFrame *inpicref)
 inpicref->data[i], inpicref->linesize[i],
 s->stride[i],
 s->planeheight[i]);
+s->frame[nout]->interlaced_frame = inpicref->interlaced_frame;
+s->frame[nout]->top_field_first  = inpicref->top_field_first;
 nout++;
 len -= 2;
 }
@@ -236,6 +240,8 @@ static int filter_frame(AVFilterLink *inlink, AVFrame *inpicref)
 
 for (i = 0; i < nout; i++) {
 AVFrame *frame = av_frame_clone(s->frame[i]);
+int interlaced = frame->interlaced_frame;
+int tff= frame->top_field_first;
 
 if (!frame) {
 av_frame_free();
@@ -243,6 +249,8 @@ static int filter_frame(AVFilterLink *inlink, AVFrame *inpicref)
 }
 
 av_frame_copy_props(frame, inpicref);
+frame->interlaced_frame = interlaced;
+frame->top_field_first  = tff;
 frame->pts = ((s->start_time == AV_NOPTS_VALUE) ? 0 : s->start_time) +
  av_rescale(outlink->frame_count_in, s->ts_unit.num,
 s->ts_unit.den);
-- 
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]lavc/amrwb: Output silence for frames marked as broken

2020-04-04 Thread Carl Eugen Hoyos
Hi!

Attached patch makes the output of the file in ticket #7113 very
similar to the reference decoder.

Please comment, Carl Eugen
From a10e9983e0724f736850b37d3732161a6cff2d6a Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos 
Date: Sun, 5 Apr 2020 01:59:21 +0200
Subject: [PATCH] lavc/amrwb: Output silence for frames marked as corrupt.

Fixes ticket #7113.
---
 libavcodec/amrwbdec.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/libavcodec/amrwbdec.c b/libavcodec/amrwbdec.c
index b488a5d3c7..00d22186b1 100644
--- a/libavcodec/amrwbdec.c
+++ b/libavcodec/amrwbdec.c
@@ -1121,7 +1121,10 @@ static int amrwb_decode_frame(AVCodecContext *avctx, void *data,
 header_size  = decode_mime_header(ctx, buf);
 expected_fr_size = ((cf_sizes_wb[ctx->fr_cur_mode] + 7) >> 3) + 1;
 
-if (ctx->fr_cur_mode == NO_DATA) {
+if (!ctx->fr_quality || ctx->fr_cur_mode > MODE_SID)
+av_log(avctx, AV_LOG_ERROR, "Encountered a bad or corrupted frame\n");
+
+if (ctx->fr_cur_mode == NO_DATA || !ctx->fr_quality) {
 for (i = 0; i < frame->nb_samples; i++)
 buf_out[i] = 0.f;
 *got_frame_ptr = 1;
@@ -1140,9 +1143,6 @@ static int amrwb_decode_frame(AVCodecContext *avctx, void *data,
 return AVERROR_INVALIDDATA;
 }
 
-if (!ctx->fr_quality || ctx->fr_cur_mode > MODE_SID)
-av_log(avctx, AV_LOG_ERROR, "Encountered a bad or corrupted frame\n");
-
 if (ctx->fr_cur_mode == MODE_SID) { /* Comfort noise frame */
 avpriv_request_sample(avctx, "SID mode");
 return AVERROR_PATCHWELCOME;
-- 
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]lavc/amrwbdec: Do not ignore NO_DATA frames

2020-04-04 Thread Carl Eugen Hoyos
Am Sa., 9. Feb. 2019 um 20:43 Uhr schrieb Paul B Mahol :
>
> On 2/9/19, Carl Eugen Hoyos  wrote:
> > 2019-01-30 14:47 GMT+01:00, Carl Eugen Hoyos :
> >> 2019-01-29 22:47 GMT+01:00, Carl Eugen Hoyos :
> >>> Hi!
> >>>
> >>> Attached patch fixes decoding NO_DATA amr-wb frames.
> >>
> >> Now with patch.
> >
> > Ping.
> >
> > This patch is supposed to fix the duration of files with NO_DATA
> > frames.
> >
>
> I guess if its not broken that its ok.

Patch applied.

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 4/4] avisynth: fix deprecation warning

2020-04-04 Thread Marton Balint



On Sun, 5 Apr 2020, Carl Eugen Hoyos wrote:


Am So., 5. Apr. 2020 um 00:48 Uhr schrieb Marton Balint :




On Sun, 5 Apr 2020, Carl Eugen Hoyos wrote:

> Am Fr., 13. März 2020 um 00:38 Uhr schrieb Stephen Hutchinson
> :
>>
>> ---
>>  libavformat/avisynth.c | 4 ++--
>>  1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/libavformat/avisynth.c b/libavformat/avisynth.c
>> index 43b65badc9..2c08ace8db 100644
>> --- a/libavformat/avisynth.c
>> +++ b/libavformat/avisynth.c
>> @@ -555,12 +555,12 @@ static int avisynth_open_file(AVFormatContext *s)
>>
>>  #ifdef _WIN32
>>  /* Convert UTF-8 to ANSI code page */
>> -MultiByteToWideChar(CP_UTF8, 0, s->filename, -1, filename_wc, MAX_PATH 
* 4);
>> +MultiByteToWideChar(CP_UTF8, 0, s->url, -1, filename_wc, MAX_PATH * 4);
>>  WideCharToMultiByte(CP_THREAD_ACP, 0, filename_wc, -1, filename_ansi,
>>  MAX_PATH * 4, NULL, NULL);
>>  arg = avs_new_value_string(filename_ansi);
>>  #else
>> -arg = avs_new_value_string(s->filename);
>> +arg = avs_new_value_string(s->url);
>>  #endif
>>  val = avs_library.avs_invoke(avs->env, "Import", arg, 0);
>>  if (avs_is_error(val)) {
>> --
>> 2.20.1
>
> Applying: avisynth: fix deprecation warning
> error: patch failed: libavformat/avisynth.c:555
> error: libavformat/avisynth.c: patch does not apply
> Patch failed at 0001 avisynth: fix deprecation warning

Have you applied the previous patches in the series? In order they
applied to me all cleanly.


Then please push them, the pings apparently did not arrive here
in the right order.


Ok, applied the series with a Changelog entry.

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

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

Re: [FFmpeg-devel] [PATCH]lavfi/telecine: Mark telecined frames as interlaced

2020-04-04 Thread Carl Eugen Hoyos
Am Sa., 4. Apr. 2020 um 00:44 Uhr schrieb Carl Eugen Hoyos :
>
> Am Sa., 4. Apr. 2020 um 00:40 Uhr schrieb James Almer :
> >
> > On 4/3/2020 6:37 PM, Carl Eugen Hoyos wrote:
> > > Am Fr., 3. Apr. 2020 um 23:19 Uhr schrieb Carl Eugen Hoyos 
> > > :
> > >
> > >> Attached patch marks actually telecined frames as interlaced,
> > >> other frames as progressive.
> > >
> > > New patch with changes to fate attached.
> > >
> > > Please comment, Carl Eugen
> >
> > Those yadif tests look wrong. The patch shouldn't affect them.
>
> Clearly, thank you!
>
> New patch attached, it should now only change the telecined
> frames and leave the other frames as they are, the setfield
> filter can be used to force a progressive setting for them.

New patch attached that also sets top_field_first

Please comment, Carl Eugen
From cd2f7b4336c1d0b786ba613d525830ff152788a3 Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos 
Date: Sun, 5 Apr 2020 01:00:44 +0200
Subject: [PATCH] lavfi/telecine: Mark telecined frames as interlaced.

---
 libavfilter/vf_telecine.c|  8 
 tests/ref/fate/filter-pixfmts-fieldmatch | 10 +-
 tests/ref/fate/filter-pixfmts-pullup | 24 
 3 files changed, 25 insertions(+), 17 deletions(-)

diff --git a/libavfilter/vf_telecine.c b/libavfilter/vf_telecine.c
index 62599a7a3a..ff8151dfc9 100644
--- a/libavfilter/vf_telecine.c
+++ b/libavfilter/vf_telecine.c
@@ -207,6 +207,8 @@ static int filter_frame(AVFilterLink *inlink, AVFrame *inpicref)
 s->stride[i],
 (s->planeheight[i] - !s->first_field + 1) / 2);
 }
+s->frame[nout]->interlaced_frame = 1;
+s->frame[nout]->top_field_first  = !s->first_field;
 nout++;
 len--;
 s->occupied = 0;
@@ -220,6 +222,8 @@ static int filter_frame(AVFilterLink *inlink, AVFrame *inpicref)
 inpicref->data[i], inpicref->linesize[i],
 s->stride[i],
 s->planeheight[i]);
+s->frame[nout]->interlaced_frame = inpicref->interlaced_frame;
+s->frame[nout]->top_field_first  = inpicref->top_field_first;
 nout++;
 len -= 2;
 }
@@ -236,6 +240,8 @@ static int filter_frame(AVFilterLink *inlink, AVFrame *inpicref)
 
 for (i = 0; i < nout; i++) {
 AVFrame *frame = av_frame_clone(s->frame[i]);
+int interlaced = frame->interlaced_frame;
+int tff= frame->top_field_first;
 
 if (!frame) {
 av_frame_free();
@@ -243,6 +249,8 @@ static int filter_frame(AVFilterLink *inlink, AVFrame *inpicref)
 }
 
 av_frame_copy_props(frame, inpicref);
+frame->interlaced_frame = interlaced;
+frame->top_field_first  = tff;
 frame->pts = ((s->start_time == AV_NOPTS_VALUE) ? 0 : s->start_time) +
  av_rescale(outlink->frame_count_in, s->ts_unit.num,
 s->ts_unit.den);
diff --git a/tests/ref/fate/filter-pixfmts-fieldmatch b/tests/ref/fate/filter-pixfmts-fieldmatch
index c3165b872d..eb0fc3c224 100644
--- a/tests/ref/fate/filter-pixfmts-fieldmatch
+++ b/tests/ref/fate/filter-pixfmts-fieldmatch
@@ -1,5 +1,5 @@
-yuv410p a6c9b4065e8253d8120772f69be0bf04
-yuv411p b913e634ad37ce046240252bed8681fb
-yuv420p a9286560141eb14595e427dbe5829b00
-yuv422p 11ad22ce00c5e8a30d0472f29fb15434
-yuv444p 6c5b0c1343d625d0656b6755906fd874
+yuv410p 572e4416ae6988dab3dbdbed3296b57c
+yuv411p ce9ccbb1985b7840955e57c23d4bc003
+yuv420p f06c53990f577893fef6a4270aab691b
+yuv422p 1c6ad2c3198ad577593214ebc9bc5705
+yuv444p 24813e175b1b09c01f5ec16149d83fce
diff --git a/tests/ref/fate/filter-pixfmts-pullup b/tests/ref/fate/filter-pixfmts-pullup
index c6ddb3489a..88c1dd565d 100644
--- a/tests/ref/fate/filter-pixfmts-pullup
+++ b/tests/ref/fate/filter-pixfmts-pullup
@@ -1,12 +1,12 @@
-gray415c928947f83f9b45c24ad15a094bda
-yuv410p 0f29d0b6394871e1e6cde484b4f351f4
-yuv411p ec059b1992e1acda472b9b2dd3e4506b
-yuv420p dba6303cd02cc39cb0db7b546793d565
-yuv422p d7d3224dd900bb1b96608a28a704360d
-yuv440p d4c5f20701cfceb4bbf7d75cfcc13514
-yuv444p 7e405274037e7f2ab845d7413a71e16d
-yuvj411pdc602e7bd3449d16e17e695815616b1e
-yuvj420pb98ec86eeef2d512aeb2fc4d32ffa656
-yuvj422pf09c3240bb662477b76ce4da34b4feed
-yuvj440p8d3ab69e2bd2f9be323c18922533
-yuvj444p2dc27560eed5d685354796de853c
+gray0af7cbb0cfb3efcb946e697c4b7bd5f9
+yuv410p c7a9e3aeb6b30eadcdf6ca5acb52c5b2
+yuv411p 2e19fb03dd57e4700ff560da3a84402e
+yuv420p 7019c5de9774970eb3a7828cb92439e8
+yuv422p 8fc1c9fff0aa2566a50ff10a54e80ba7
+yuv440p 

Re: [FFmpeg-devel] [PATCH 2/4] avisynth: switch to AviSynth+ on Linux

2020-04-04 Thread Stephen Hutchinson

On 3/24/2020 2:40 PM, Stephen Hutchinson wrote:

On 3/12/20 7:38 PM, Stephen Hutchinson wrote:

AviSynth+ now supports non-Windows OSes, making AvxSynth
obsolete.  Since we no longer support AviSynth 2.5 (which is
essentially what AvxSynth is), remove AvxSynth support and
replace it with AviSynth+.

As a result, the USING_AVISYNTH defines can be switched back
to generic _WIN32.
---
  libavformat/avisynth.c | 56 +++---
  1 file changed, 15 insertions(+), 41 deletions(-)

diff --git a/libavformat/avisynth.c b/libavformat/avisynth.c
index 55a2efd884..43b65badc9 100644
--- a/libavformat/avisynth.c
+++ b/libavformat/avisynth.c
@@ -1,5 +1,5 @@
  /*
- * AviSynth/AvxSynth support
+ * AviSynth(+) support
   * Copyright (c) 2012 AvxSynth Team
   *
   * This file is part of FFmpeg
@@ -31,20 +31,19 @@
  /* Enable function pointer definitions for runtime loading. */
  #define AVSC_NO_DECLSPEC
-/* Platform-specific directives for AviSynth vs AvxSynth. */
+/* Platform-specific directives. */
  #ifdef _WIN32
    #include "compat/w32dlfcn.h"
    #undef EXTERN_C
-  #include "compat/avisynth/avisynth_c.h"
    #define AVISYNTH_LIB "avisynth"
-  #define USING_AVISYNTH
  #else
    #include 
-  #include "compat/avisynth/avxsynth_c.h"
-  #define AVISYNTH_NAME "libavxsynth"
+  #define AVISYNTH_NAME "libavisynth"
    #define AVISYNTH_LIB AVISYNTH_NAME SLIBSUF
  #endif
+#include 
+
  typedef struct AviSynthLibrary {
  void *library;
  #define AVSC_DECLARE_FUNC(name) name ## _func name
@@ -62,7 +61,6 @@ typedef struct AviSynthLibrary {
  AVSC_DECLARE_FUNC(avs_release_value);
  AVSC_DECLARE_FUNC(avs_release_video_frame);
  AVSC_DECLARE_FUNC(avs_take_clip);
-#ifdef USING_AVISYNTH
  AVSC_DECLARE_FUNC(avs_bits_per_pixel);
  AVSC_DECLARE_FUNC(avs_get_height_p);
  AVSC_DECLARE_FUNC(avs_get_pitch_p);
@@ -70,7 +68,6 @@ typedef struct AviSynthLibrary {
  AVSC_DECLARE_FUNC(avs_get_row_size_p);
  AVSC_DECLARE_FUNC(avs_is_planar_rgb);
  AVSC_DECLARE_FUNC(avs_is_planar_rgba);
-#endif
  #undef AVSC_DECLARE_FUNC
  } AviSynthLibrary;
@@ -97,14 +94,12 @@ static const int avs_planes_packed[1] = { 0 };
  static const int avs_planes_grey[1]   = { AVS_PLANAR_Y };
  static const int avs_planes_yuv[3]    = { AVS_PLANAR_Y, AVS_PLANAR_U,
    AVS_PLANAR_V };
-#ifdef USING_AVISYNTH
  static const int avs_planes_rgb[3]    = { AVS_PLANAR_G, AVS_PLANAR_B,
    AVS_PLANAR_R };
  static const int avs_planes_yuva[4]   = { AVS_PLANAR_Y, AVS_PLANAR_U,
    AVS_PLANAR_V, AVS_PLANAR_A };
  static const int avs_planes_rgba[4]   = { AVS_PLANAR_G, AVS_PLANAR_B,
    AVS_PLANAR_R, AVS_PLANAR_A };
-#endif
  /* A conflict between C++ global objects, atexit, and dynamic 
loading requires

   * us to register our own atexit handler to prevent double freeing. */
@@ -142,7 +137,6 @@ static av_cold int avisynth_load_library(void)
  LOAD_AVS_FUNC(avs_release_value, 0);
  LOAD_AVS_FUNC(avs_release_video_frame, 0);
  LOAD_AVS_FUNC(avs_take_clip, 0);
-#ifdef USING_AVISYNTH
  LOAD_AVS_FUNC(avs_bits_per_pixel, 1);
  LOAD_AVS_FUNC(avs_get_height_p, 1);
  LOAD_AVS_FUNC(avs_get_pitch_p, 1);
@@ -150,7 +144,6 @@ static av_cold int avisynth_load_library(void)
  LOAD_AVS_FUNC(avs_get_row_size_p, 1);
  LOAD_AVS_FUNC(avs_is_planar_rgb, 1);
  LOAD_AVS_FUNC(avs_is_planar_rgba, 1);
-#endif
  #undef LOAD_AVS_FUNC
  atexit(avisynth_atexit_handler);
@@ -249,7 +242,6 @@ static int 
avisynth_create_stream_video(AVFormatContext *s, AVStream *st)
  avpriv_set_pts_info(st, 32, avs->vi->fps_denominator, 
avs->vi->fps_numerator);

  switch (avs->vi->pixel_type) {
-#ifdef USING_AVISYNTH
  /* 10~16-bit YUV pix_fmts (AviSynth+) */
  case AVS_CS_YUV444P10:
  st->codecpar->format = AV_PIX_FMT_YUV444P10;
@@ -434,8 +426,7 @@ static int 
avisynth_create_stream_video(AVFormatContext *s, AVStream *st)

  case AVS_CS_BGR64:
  st->codecpar->format = AV_PIX_FMT_BGRA64;
  break;
-#endif
-    /* AviSynth 2.5 and AvxSynth pix_fmts */
+    /* AviSynth 2.5 pix_fmts */
  case AVS_CS_BGR24:
  st->codecpar->format = AV_PIX_FMT_BGR24;
  break;
@@ -461,7 +452,6 @@ static int 
avisynth_create_stream_video(AVFormatContext *s, AVStream *st)

  }
  switch (planar) {
-#ifdef USING_AVISYNTH
  case 5: // Planar RGB + Alpha
  avs->n_planes = 4;
  avs->planes   = avs_planes_rgba;
@@ -474,7 +464,6 @@ static int 
avisynth_create_stream_video(AVFormatContext *s, AVStream *st)

  avs->n_planes = 3;
  avs->planes   = avs_planes_rgb;
  break;
-#endif
  case 2: // Y8
  avs->n_planes = 1;
  avs->planes   = avs_planes_grey;
@@ -556,7 +545,7 @@ static int avisynth_open_file(AVFormatContext *s)
  AviSynthContext *avs = s->priv_data;
  

Re: [FFmpeg-devel] [PATCH 4/4] avisynth: fix deprecation warning

2020-04-04 Thread Carl Eugen Hoyos
Am So., 5. Apr. 2020 um 00:48 Uhr schrieb Marton Balint :
>
>
>
> On Sun, 5 Apr 2020, Carl Eugen Hoyos wrote:
>
> > Am Fr., 13. März 2020 um 00:38 Uhr schrieb Stephen Hutchinson
> > :
> >>
> >> ---
> >>  libavformat/avisynth.c | 4 ++--
> >>  1 file changed, 2 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/libavformat/avisynth.c b/libavformat/avisynth.c
> >> index 43b65badc9..2c08ace8db 100644
> >> --- a/libavformat/avisynth.c
> >> +++ b/libavformat/avisynth.c
> >> @@ -555,12 +555,12 @@ static int avisynth_open_file(AVFormatContext *s)
> >>
> >>  #ifdef _WIN32
> >>  /* Convert UTF-8 to ANSI code page */
> >> -MultiByteToWideChar(CP_UTF8, 0, s->filename, -1, filename_wc, 
> >> MAX_PATH * 4);
> >> +MultiByteToWideChar(CP_UTF8, 0, s->url, -1, filename_wc, MAX_PATH * 
> >> 4);
> >>  WideCharToMultiByte(CP_THREAD_ACP, 0, filename_wc, -1, filename_ansi,
> >>  MAX_PATH * 4, NULL, NULL);
> >>  arg = avs_new_value_string(filename_ansi);
> >>  #else
> >> -arg = avs_new_value_string(s->filename);
> >> +arg = avs_new_value_string(s->url);
> >>  #endif
> >>  val = avs_library.avs_invoke(avs->env, "Import", arg, 0);
> >>  if (avs_is_error(val)) {
> >> --
> >> 2.20.1
> >
> > Applying: avisynth: fix deprecation warning
> > error: patch failed: libavformat/avisynth.c:555
> > error: libavformat/avisynth.c: patch does not apply
> > Patch failed at 0001 avisynth: fix deprecation warning
>
> Have you applied the previous patches in the series? In order they
> applied to me all cleanly.

Then please push them, the pings apparently did not arrive here
in the right order.

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 4/4] avisynth: fix deprecation warning

2020-04-04 Thread Marton Balint



On Sun, 5 Apr 2020, Carl Eugen Hoyos wrote:


Am Fr., 13. März 2020 um 00:38 Uhr schrieb Stephen Hutchinson
:


---
 libavformat/avisynth.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/libavformat/avisynth.c b/libavformat/avisynth.c
index 43b65badc9..2c08ace8db 100644
--- a/libavformat/avisynth.c
+++ b/libavformat/avisynth.c
@@ -555,12 +555,12 @@ static int avisynth_open_file(AVFormatContext *s)

 #ifdef _WIN32
 /* Convert UTF-8 to ANSI code page */
-MultiByteToWideChar(CP_UTF8, 0, s->filename, -1, filename_wc, MAX_PATH * 
4);
+MultiByteToWideChar(CP_UTF8, 0, s->url, -1, filename_wc, MAX_PATH * 4);
 WideCharToMultiByte(CP_THREAD_ACP, 0, filename_wc, -1, filename_ansi,
 MAX_PATH * 4, NULL, NULL);
 arg = avs_new_value_string(filename_ansi);
 #else
-arg = avs_new_value_string(s->filename);
+arg = avs_new_value_string(s->url);
 #endif
 val = avs_library.avs_invoke(avs->env, "Import", arg, 0);
 if (avs_is_error(val)) {
--
2.20.1


Applying: avisynth: fix deprecation warning
error: patch failed: libavformat/avisynth.c:555
error: libavformat/avisynth.c: patch does not apply
Patch failed at 0001 avisynth: fix deprecation warning


Have you applied the previous patches in the series? In order they 
applied to me all cleanly.


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 1/2] avformat/oggparsevorbis: Update context on double init

2020-04-04 Thread Michael Niedermayer
Fixes: memleak
Fixes: 
19949/clusterfuzz-testcase-minimized-ffmpeg_DEMUXER_fuzzer-5743636058210304

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

diff --git a/libavformat/oggparsevorbis.c b/libavformat/oggparsevorbis.c
index 8dd27e7770..d5784a5f5e 100644
--- a/libavformat/oggparsevorbis.c
+++ b/libavformat/oggparsevorbis.c
@@ -398,6 +398,7 @@ static int vorbis_header(AVFormatContext *s, int idx)
 st->codecpar->extradata_size = 0;
 return AVERROR_UNKNOWN;
 }
+st->internal->need_context_update = 1;
 }
 
 return 1;
-- 
2.17.1

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

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

[FFmpeg-devel] [PATCH 2/2] avcodec/cbs_h265_syntax_template: Check num_negative/positive_pics when inter_ref_pic_set_prediction_flag is set

2020-04-04 Thread Michael Niedermayer
Fixes: out of array access
Fixes: 
20446/clusterfuzz-testcase-minimized-ffmpeg_BSF_HEVC_METADATA_fuzzer-5707770718584832

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

diff --git a/libavcodec/cbs_h265_syntax_template.c 
b/libavcodec/cbs_h265_syntax_template.c
index 180a045c34..5f5531944c 100644
--- a/libavcodec/cbs_h265_syntax_template.c
+++ b/libavcodec/cbs_h265_syntax_template.c
@@ -601,6 +601,8 @@ static int FUNC(st_ref_pic_set)(CodedBitstreamContext *ctx, 
RWContext *rw,
 }
 }
 
+if (i > 15)
+return AVERROR_INVALIDDATA;
 infer(num_negative_pics, i);
 for (i = 0; i < current->num_negative_pics; i++) {
 infer(delta_poc_s0_minus1[i],
@@ -630,6 +632,8 @@ static int FUNC(st_ref_pic_set)(CodedBitstreamContext *ctx, 
RWContext *rw,
 }
 }
 
+if (i + current->num_negative_pics > 15)
+return AVERROR_INVALIDDATA;
 infer(num_positive_pics, i);
 for (i = 0; i < current->num_positive_pics; i++) {
 infer(delta_poc_s1_minus1[i],
-- 
2.17.1

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

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

Re: [FFmpeg-devel] [PATCH] doc/general.texi: AviSynth+ works on Linux now, AvxSynth is gone.

2020-04-04 Thread Stephen Hutchinson

On 3/24/2020 2:39 PM, Stephen Hutchinson wrote:

Related to this are the following changes:
* Mention the two methods that AviSynth+ provides for installing
   just the headers.
* Expand on users installing AviSynth on their system a little
   more.
---
This is the only patch that needed changes. I'll just ping the
other three.
  doc/general.texi | 21 -
  1 file changed, 12 insertions(+), 9 deletions(-)

diff --git a/doc/general.texi b/doc/general.texi
index 3684847ac1..5f0f1b2ad1 100644
--- a/doc/general.texi
+++ b/doc/general.texi
@@ -50,16 +50,18 @@ This driver can be installed using amdgpu-pro-install 
script in official amd dri
  @section AviSynth
  
  FFmpeg can read AviSynth scripts as input. To enable support, pass

-@code{--enable-avisynth} to configure.  The correct headers are
-included in compat/avisynth/, which allows the user to enable support
-without needing to search for these headers themselves.
+@code{--enable-avisynth} to configure after installing the headers
+provided by @url{https://github.com/AviSynth/AviSynthPlus, AviSynth+}.
+AviSynth+ can be configured to install only the headers by either
+passing `-DHEADERS_ONLY:bool=on` to the normal CMake-based build
+system, or by using the supplied @code{GNUmakefile}.
  
  For Windows, supported AviSynth variants are

  @url{http://avisynth.nl, AviSynth 2.6 RC1 or higher} for 32-bit builds and
  @url{http://avisynth.nl/index.php/AviSynth+, AviSynth+ r1718 or higher} for 
32-bit and 64-bit builds.
  
-For Linux and OS X, the supported AviSynth variant is

-@url{https://github.com/avxsynth/avxsynth, AvxSynth}.
+For Linux, macOS, and BSD, the only supported AviSynth variant is
+@url{https://github.com/AviSynth/AviSynthPlus, AviSynth+}, starting with 
version 3.5.
  
  @float NOTE

  In 2016, AviSynth+ added support for building with GCC. However, due to
@@ -77,10 +79,11 @@ GCC builds of AviSynth+ without any special flags.
  @end float
  
  @float NOTE

-AviSynth and AvxSynth are loaded dynamically.  Distributors can build FFmpeg
-with @code{--enable-avisynth}, and the binaries will work regardless of the
-end user having AviSynth or AvxSynth installed - they'll only need to be
-installed to use AviSynth scripts (obviously).
+AviSynth(+) is loaded dynamically.  Distributors can build FFmpeg
+with @code{--enable-avisynth}, and the binaries will work regardless
+of the end user having AviSynth installed.  If/when an end user
+would like to use AviSynth scripts, then they can install AviSynth(+)
+and FFmpeg will be able to find and use it to open scripts.
  @end float
  
  @section Chromaprint




Ping.

On Patchwork:
https://patchwork.ffmpeg.org/project/ffmpeg/patch/20200324183919.8789-1-qyo...@gmail.com/
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [PATCH] avformat/matroskaenc: remove MAX_TRACKS limit

2020-04-04 Thread Jan Chren (rindeal)
On Sat Apr 4 09:29:20 EEST 2020, Andreas Rheinhardt
 wrote:
> Are you running into this limitation?

Yes.

> If so, do the files that you
> create with this patch that have more than 127 tracks work? They
> shouldn't. The reason for this (and the reason that I didn't remove this
> limit altogether in 65ef74f74900590f134b4a130e8f56e5272d1925) lies in
> the way the TrackNumber is encoded in the (Simple)Blocks: They are
> encoded as variable-length numbers, so that encoding small TrackNumbers
> takes up less bytes than encoding bigger TrackNumbers. More precisely,
> TrackNumbers in the range 1..127 are encodable on one byte. And the way
> they are written in mkv_write_block() and mkv_write_vtt_blocks() relies
> on this. If you simply remove said limit, the tracks with TrackNumbers >
> 127 will not have any (Simple)Blocks associated with them; instead the
> encoded TrackNumber will be the desired TrackNumber modulo 128 and the
> (Simple)Block will appear to belong to the track with the encoded
> TrackNumber (if one exists).** The results will of course be catastrophic.

I skimmed through libmatroska's code in src/KaxBlock.cpp and their
limit is 0x4000-1, which is way more reasonable.

> Notice that I have sent a patchset that slightly increases the number of
> allowed tracks (without fixing the root cause though, because I didn't
> know if there are really people who run into this): [1] makes
> attachments no longer count towards the limit; [2] increases the limit
> to 127. I will resend said patchset soon.
>
> - Andreas
>
> [1]: https://ffmpeg.org/pipermail/ffmpeg-devel/2019-November/253452.html
> [2]: https://ffmpeg.org/pipermail/ffmpeg-devel/2019-November/252563.html
>
> *: The reason for setting MAX_TRACKS to 126 instead of 127 is probably
> that the encoding corresponding to the number 127 is special when
> encoding lengths (which use the same variable-length number scheme):
> Here it denotes an unknown length instead of a length of 127. But there
> are no such values with a special meaning for encoded TrackNumbers.

Indeed, libmatroska allows 0x80-1 (127) per byte. Your second patch
should have been merged.

> **: Notice that a TrackNumber of 0 is invalid, so any (Simple)Block that
> ought to belong to the tracks with TrackNumber 128, 256, 384, ... will
> have no matching track at all. FFmpeg's Matroska demuxer treats
> encountering such (Simple)Blocks as a sign of invalid data and it will
> try to resync to the next level 1 element (typically the next Cluster).
> Similar things can happen if you use attachments (in this case there may
> be gaps in the used TrackNumbers).

I have included a new patch, which writes the track_number using
put_ebml_num(), which should work perhaps?
From 477d1ee08115e09f2f61f75dd70ce7bc882d2c34 Mon Sep 17 00:00:00 2001
From: Jan Chren (rindeal) 
Date: Sat, 4 Apr 2020 00:00:00 +
Subject: [PATCH] avformat/matroskaenc: remove track limit

Strictly speaking, ebml_num_size() wastes one bit here.
Employing new ebml_num_size() and put_ebml_num() just for track_number
would solve this.

---
 libavformat/matroskaenc.c | 20 
 1 file changed, 4 insertions(+), 16 deletions(-)

diff --git a/libavformat/matroskaenc.c b/libavformat/matroskaenc.c
index 5dae53026d..30132a53e8 100644
--- a/libavformat/matroskaenc.c
+++ b/libavformat/matroskaenc.c
@@ -117,10 +117,6 @@ typedef struct mkv_attachments {
 #define MODE_MATROSKAv2 0x01
 #define MODE_WEBM   0x02
 
-/** Maximum number of tracks allowed in a Matroska file (with track numbers in
- * range 1 to 126 (inclusive) */
-#define MAX_TRACKS 126
-
 typedef struct MatroskaMuxContext {
 const AVClass   *class;
 int mode;
@@ -2089,9 +2085,8 @@ static int mkv_write_block(AVFormatContext *s, AVIOContext *pb,
 }
 
 put_ebml_id(pb, blockid);
-put_ebml_num(pb, size + 4, 0);
-// this assumes stream_index is less than 126
-avio_w8(pb, 0x80 | track_number);
+put_ebml_num(pb, size + ebml_num_size(track_number) + 2 + 1, 0);
+put_ebml_num(track_number, 0);
 avio_wb16(pb, ts - mkv->cluster_pts);
 avio_w8(pb, (blockid == MATROSKA_ID_SIMPLEBLOCK && keyframe) ? (1 << 7) : 0);
 avio_write(pb, data + offset, size);
@@ -2155,8 +2150,8 @@ static int mkv_write_vtt_blocks(AVFormatContext *s, AVIOContext *pb, AVPacket *p
 blockgroup = start_ebml_master(pb, MATROSKA_ID_BLOCKGROUP, mkv_blockgroup_size(size));
 
 put_ebml_id(pb, MATROSKA_ID_BLOCK);
-put_ebml_num(pb, size + 4, 0);
-avio_w8(pb, 0x80 | (pkt->stream_index + 1)); // this assumes stream_index is less than 126
+put_ebml_num(pb, size + ebml_num_size(pkt->stream_index + 1) + 2 + 1, 0);
+put_ebml_num(pkt->stream_index + 1, 0);
 avio_wb16(pb, ts - mkv->cluster_pts);
 avio_w8(pb, flags);
 avio_printf(pb, "%.*s\n%.*s\n%.*s", id_size, id, settings_size, settings, pkt->size, pkt->data);
@@ -2604,13 +2599,6 @@ static int mkv_init(struct AVFormatContext *s)
 {
 int i;
 
-if (s->nb_streams 

Re: [FFmpeg-devel] [PATCH 4/4] avisynth: fix deprecation warning

2020-04-04 Thread Carl Eugen Hoyos
Am Fr., 13. März 2020 um 00:38 Uhr schrieb Stephen Hutchinson
:
>
> ---
>  libavformat/avisynth.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/libavformat/avisynth.c b/libavformat/avisynth.c
> index 43b65badc9..2c08ace8db 100644
> --- a/libavformat/avisynth.c
> +++ b/libavformat/avisynth.c
> @@ -555,12 +555,12 @@ static int avisynth_open_file(AVFormatContext *s)
>
>  #ifdef _WIN32
>  /* Convert UTF-8 to ANSI code page */
> -MultiByteToWideChar(CP_UTF8, 0, s->filename, -1, filename_wc, MAX_PATH * 
> 4);
> +MultiByteToWideChar(CP_UTF8, 0, s->url, -1, filename_wc, MAX_PATH * 4);
>  WideCharToMultiByte(CP_THREAD_ACP, 0, filename_wc, -1, filename_ansi,
>  MAX_PATH * 4, NULL, NULL);
>  arg = avs_new_value_string(filename_ansi);
>  #else
> -arg = avs_new_value_string(s->filename);
> +arg = avs_new_value_string(s->url);
>  #endif
>  val = avs_library.avs_invoke(avs->env, "Import", arg, 0);
>  if (avs_is_error(val)) {
> --
> 2.20.1

Applying: avisynth: fix deprecation warning
error: patch failed: libavformat/avisynth.c:555
error: libavformat/avisynth.c: patch does not apply
Patch failed at 0001 avisynth: fix deprecation warning

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]lavc/aacdec_template: Only warn once about unusual 7.1 encoding

2020-04-04 Thread Carl Eugen Hoyos
Am Fr., 27. März 2020 um 22:38 Uhr schrieb Carl Eugen Hoyos
:
>
> Am Fr., 27. März 2020 um 19:00 Uhr schrieb Carl Eugen Hoyos
> :
>
> > Attached patch reduces warnings when decoding a file with 7.1(wide)
> > aac encoding.
>
> New patch attached that does not lead to new crashes.

Patch applied.

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 4/4] avisynth: fix deprecation warning

2020-04-04 Thread Stephen Hutchinson

On 3/24/2020 2:40 PM, Stephen Hutchinson wrote:

On 3/12/20 7:38 PM, Stephen Hutchinson wrote:

---
  libavformat/avisynth.c | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/libavformat/avisynth.c b/libavformat/avisynth.c
index 43b65badc9..2c08ace8db 100644
--- a/libavformat/avisynth.c
+++ b/libavformat/avisynth.c
@@ -555,12 +555,12 @@ static int avisynth_open_file(AVFormatContext *s)
  #ifdef _WIN32
  /* Convert UTF-8 to ANSI code page */
-    MultiByteToWideChar(CP_UTF8, 0, s->filename, -1, filename_wc, 
MAX_PATH * 4);
+    MultiByteToWideChar(CP_UTF8, 0, s->url, -1, filename_wc, MAX_PATH 
* 4);
  WideCharToMultiByte(CP_THREAD_ACP, 0, filename_wc, -1, 
filename_ansi,

  MAX_PATH * 4, NULL, NULL);
  arg = avs_new_value_string(filename_ansi);
  #else
-    arg = avs_new_value_string(s->filename);
+    arg = avs_new_value_string(s->url);
  #endif
  val = avs_library.avs_invoke(avs->env, "Import", arg, 0);
  if (avs_is_error(val)) {



Ping.


Ping #2.

On Patchwork:
https://patchwork.ffmpeg.org/project/ffmpeg/patch/20200312233802.4033-4-qyo...@gmail.com/
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [PATCH] avcodec/binkaudio: Check sample_rate to avoid integer overflow

2020-04-04 Thread Michael Niedermayer
On Sun, Feb 09, 2020 at 09:28:48PM +0100, Michael Niedermayer wrote:
> On Sat, Feb 01, 2020 at 11:48:06PM +0100, Michael Niedermayer wrote:
> > On Sat, Feb 01, 2020 at 04:17:10PM +0100, Paul B Mahol wrote:
> > > On 2/1/20, Michael Niedermayer  wrote:
> > > > On Tue, Jan 14, 2020 at 04:04:29PM +0100, Paul B Mahol wrote:
> > > >> This better belong to generic code.
> > > >
> > > > This specific check (which checks for INT_MAX) is specific to our
> > > > bink audio code which does a +1
> > > > so it would not fit in generic code
> > > >
> > > > We could arbitrarily decide on a maximum sample rate hardcode that
> > > > and check for that in generic code.
> > > > I can implement that if people prefer. It would not avoid all
> > > > sample rate checks in codecs though ...
> > > 
> > > sample rate can not be > INT_MAX
> > 
> > no and the code also doesnt check > INT_MAX 
> > I think you maybe missed the = in >=
> > theres a +1 and INT_MAX+1 is bad so INT_MAX is checked for
> > we can do that in generic code but its only this decoder that has this
> > issue other decoders may have other limits. That makes this specific
> > check threshold bad for a check in generic code. Another threshold
> > would work in generic code, it would be arbitrary though and limit
> > most decoders more than needed
> > Iam happy to implement what people prefer but the check as it is
> > makes not much sense if its moved as is into generic code
> 
> any preferrance on how to solve this ?
> or you are ok with the patch ?

ping

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

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


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

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

Re: [FFmpeg-devel] [PATCH]configure: Filter -Wl, linker flags out for msvc compilation

2020-04-04 Thread Carl Eugen Hoyos
Am Fr., 3. Apr. 2020 um 22:01 Uhr schrieb Carl Eugen Hoyos :
>
> Am Mi., 1. Apr. 2020 um 16:59 Uhr schrieb Carl Eugen Hoyos 
> :
>
> > Attached patch silences a few warnings when compiling with cl.exe or
> > clang-cl.exe.
> > Or are there any working options?
>
> I will push this if there are no objections.

Patch applied.

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]lavc/sbc: Remove bool usage

2020-04-04 Thread Carl Eugen Hoyos
Am Mi., 1. Apr. 2020 um 21:30 Uhr schrieb Carl Eugen Hoyos :

> It seems to me that this was forgotten when the codec was originally ported.

Patch applied.

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] avutil/log: update text requesting samples

2020-04-04 Thread Carl Eugen Hoyos
Am Sa., 4. Apr. 2020 um 19:26 Uhr schrieb Marton Balint :
>
> Signed-off-by: Marton Balint 
> ---
>  libavutil/log.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/libavutil/log.c b/libavutil/log.c
> index 8d4945249e..a0b2348bd5 100644
> --- a/libavutil/log.c
> +++ b/libavutil/log.c
> @@ -466,9 +466,9 @@ static void missing_feature_sample(int sample, void *avc, 
> const char *msg,
> "occurs, it means that your file has a feature which has not "
> "been implemented.\n");
>  if (sample)
> -av_log(avc, AV_LOG_WARNING, "If you want to help, upload a sample "
> -   "of this file to ftp://upload.ffmpeg.org/incoming/ "
> -   "and contact the ffmpeg-devel mailing list. 
> (ffmpeg-devel@ffmpeg.org)\n");
> +av_log(avc, AV_LOG_WARNING, "If you want to help, open an 
> enhancement "
> +"ticket on https://trac.ffmpeg.org/ and upload a sample of this "
> +"file to https://streams.videolan.org/upload/\n;);

The change to the upload link is good, I would prefer if we
do not ask for opening a ticket in every such case.

I believe I have dealt with every such (rare) mail in the past.

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

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

Re: [FFmpeg-devel] [PATCH]lavf, lavfi: Remove uses of sizeof(char)

2020-04-04 Thread Carl Eugen Hoyos
Am Sa., 4. Apr. 2020 um 06:40 Uhr schrieb Andreas Rheinhardt
:
>
> Carl Eugen Hoyos:
> > Hi!
> >
> > Attached patch removes uses of sizeof(char) from libavfilter and 
> > libavformat.
> >
> > Please comment, Carl Eugen
> >
> The commit message is misleading: Actually C is based around
> sizeof(char) = 1. From the semantics of the sizeof operator: "When
> applied to an operand that has type char, unsigned char, or signed char,
> (or a qualified version thereof) the result is 1." (C90, 6.3.3.4; C99,
> 6.5.3.4).

Pushed with an improved commit message.

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]qsv: Fix format specifiers for int variables

2020-04-04 Thread Carl Eugen Hoyos
Am Fr., 3. Apr. 2020 um 21:49 Uhr schrieb Carl Eugen Hoyos :
>
> Am Mi., 1. Apr. 2020 um 16:55 Uhr schrieb Carl Eugen Hoyos 
> :
>
> > Attached patches fix three wrong format specifiers, the variables are
> > all of type int but the specifier PRId16 is used.
>
> Will push them tomorrow.

Done.

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]lavc: Use supported_samplerates for Dolby Digital encoders

2020-04-04 Thread Carl Eugen Hoyos
Am Di., 11. Feb. 2020 um 00:24 Uhr schrieb Carl Eugen Hoyos
:

> Attached patch probably fixes ticket #8518 and definitely simplifies
> *ac3* encoding usage.

Patch applied.

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] avformat/matroskaenc: add matroska subtitle muxer (.mks)

2020-04-04 Thread Andreas Rheinhardt
James Almer:
> On 4/4/2020 3:00 PM, Jan Chren (rindeal) wrote:
>> On Sat, 4 Apr 2020 at 16:32, Andreas Rheinhardt
>>  wrote:
>>> What is the aim of your patch? If it is simply making sure that using
>>> the mks extension autoselects the Matroska muxer,
>>
>> That's correct.
>>
>>> then adding "mks" to
>>> the list of extensions of the ordinary Matroska muxer would be enough.
>>> (Notice that using mka for files with audio, but without video or mks
>>> for subtitle-only files is just a convention; putting something else
>>> than indicated by the extension in the files does not make them less
>>> spec-compliant.)
>>
>> Should I create a new patch which removes the audio muxer and just
>> adds `mka` and `mks` extensions to the ordinary muxer?
>> Or is there some reason why a dedicated audio muxer must exist,
>> whereas a subtitle muxer does not?
> 
> Is there a mimetype specific for .mks? If so, then a separate demuxer
> would be acceptable. Otherwise, simply adding the extension to the
> existing matroska muxer and adding stream checks to mkv_init() should
> suffice.
> 
> In any case, your patch is apparently not correct as it's missing all
> the allowed codec ids in AVCodec.codec_tag, and/or defining an
> AVCodec.query_codec function to only accept subtitle codecs.

Using mks is actually just a convention, so putting only subtitles into
it should not be enforced (just as is with the Matroska audio muxer). If
I am not mistaken, then a separate muxer would only help with stream
auto-selection (i.e. it would make -map in FFmpeg cli superfluous).

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

Re: [FFmpeg-devel] [PATCH] avformat/matroskaenc: add matroska subtitle muxer (.mks)

2020-04-04 Thread James Almer
On 4/4/2020 3:00 PM, Jan Chren (rindeal) wrote:
> On Sat, 4 Apr 2020 at 16:32, Andreas Rheinhardt
>  wrote:
>> What is the aim of your patch? If it is simply making sure that using
>> the mks extension autoselects the Matroska muxer,
> 
> That's correct.
> 
>> then adding "mks" to
>> the list of extensions of the ordinary Matroska muxer would be enough.
>> (Notice that using mka for files with audio, but without video or mks
>> for subtitle-only files is just a convention; putting something else
>> than indicated by the extension in the files does not make them less
>> spec-compliant.)
> 
> Should I create a new patch which removes the audio muxer and just
> adds `mka` and `mks` extensions to the ordinary muxer?
> Or is there some reason why a dedicated audio muxer must exist,
> whereas a subtitle muxer does not?

Is there a mimetype specific for .mks? If so, then a separate demuxer
would be acceptable. Otherwise, simply adding the extension to the
existing matroska muxer and adding stream checks to mkv_init() should
suffice.

In any case, your patch is apparently not correct as it's missing all
the allowed codec ids in AVCodec.codec_tag, and/or defining an
AVCodec.query_codec function to only accept subtitle codecs.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [PATCH] avformat/matroskaenc: add matroska subtitle muxer (.mks)

2020-04-04 Thread Carl Eugen Hoyos
Am Sa., 4. Apr. 2020 um 20:01 Uhr schrieb Jan Chren (rindeal)
:
>
> On Sat, 4 Apr 2020 at 16:32, Andreas Rheinhardt
>  wrote:
> > What is the aim of your patch? If it is simply making sure that using
> > the mks extension autoselects the Matroska muxer,
>
> That's correct.
>
> > then adding "mks" to
> > the list of extensions of the ordinary Matroska muxer would be enough.
> > (Notice that using mka for files with audio, but without video or mks
> > for subtitle-only files is just a convention; putting something else
> > than indicated by the extension in the files does not make them less
> > spec-compliant.)
>
> Should I create a new patch which removes the audio muxer and just
> adds `mka`

No.

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] avdevice/decklink_dec: increase autodetect timeout to 3 sec

2020-04-04 Thread Marton Balint



On Wed, 1 Apr 2020, Marton Balint wrote:


1 sec might not be enough for the cards to detect the format...

Signed-off-by: Marton Balint 
---
libavdevice/decklink_dec.cpp | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/libavdevice/decklink_dec.cpp b/libavdevice/decklink_dec.cpp
index c8d931517e..82106aa69e 100644
--- a/libavdevice/decklink_dec.cpp
+++ b/libavdevice/decklink_dec.cpp
@@ -950,8 +950,8 @@ static int decklink_autodetect(struct decklink_cctx *cctx) {
return -1;
}

-// 1 second timeout
-for (i = 0; i < 10; i++) {
+// 3 second timeout
+for (i = 0; i < 30; i++) {
av_usleep(10);
/* Sometimes VideoInputFrameArrived is called without the
 * bmdFrameHasNoInputSource flag before VideoInputFormatChanged.


Applied.

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] avcodec/v4l2_m2m_enc: Add option to remove ivf container

2020-04-04 Thread Andriy Gelman
From: Andriy Gelman 

The dequeued packets from vp8 (s5p-mfc) encoder are output in ivf format
which breaks the stream when the packets are muxed in avformat. This commit
adds an option to remove the container and thus support the encoder.

Signed-off-by: Andriy Gelman 
---
 libavcodec/v4l2_m2m.h |  2 ++
 libavcodec/v4l2_m2m_enc.c | 53 +++
 2 files changed, 45 insertions(+), 10 deletions(-)

diff --git a/libavcodec/v4l2_m2m.h b/libavcodec/v4l2_m2m.h
index 456281f48c..525f9456e9 100644
--- a/libavcodec/v4l2_m2m.h
+++ b/libavcodec/v4l2_m2m.h
@@ -73,6 +73,8 @@ typedef struct V4L2m2mPriv {
 
 int num_output_buffers;
 int num_capture_buffers;
+int strip_ivf;
+int ivf_detected;
 } V4L2m2mPriv;
 
 /**
diff --git a/libavcodec/v4l2_m2m_enc.c b/libavcodec/v4l2_m2m_enc.c
index c9f1741bfd..9c11f90567 100644
--- a/libavcodec/v4l2_m2m_enc.c
+++ b/libavcodec/v4l2_m2m_enc.c
@@ -25,6 +25,8 @@
 #include 
 #include 
 #include "libavcodec/avcodec.h"
+#include "libavcodec/internal.h"
+#include "libavutil/intreadwrite.h"
 #include "libavutil/pixdesc.h"
 #include "libavutil/pixfmt.h"
 #include "libavutil/opt.h"
@@ -256,6 +258,7 @@ static int v4l2_send_frame(AVCodecContext *avctx, const 
AVFrame *frame)
 
 static int v4l2_receive_packet(AVCodecContext *avctx, AVPacket *avpkt)
 {
+V4L2m2mPriv *priv = avctx->priv_data;
 V4L2m2mContext *s = ((V4L2m2mPriv*)avctx->priv_data)->context;
 V4L2Context *const capture = >capture;
 V4L2Context *const output = >output;
@@ -281,7 +284,28 @@ static int v4l2_receive_packet(AVCodecContext *avctx, 
AVPacket *avpkt)
 }
 
 dequeue:
-return ff_v4l2_context_dequeue_packet(capture, avpkt);
+ret = ff_v4l2_context_dequeue_packet(capture, avpkt);
+if (ret)
+return ret;
+
+if (priv->strip_ivf) {
+int header_offset = 0;
+if (avpkt->size >= 32 && AV_RL32(avpkt->data) == 
MKTAG('D','K','I','F')) {
+header_offset = 32;
+priv->ivf_detected = 1;
+} else if (priv->ivf_detected) {
+header_offset = 12;
+}
+header_offset = FFMIN(header_offset, avpkt->size);
+avpkt->data  += header_offset;
+avpkt->size  -= header_offset;
+
+if (avpkt->size == 0) {
+av_packet_unref(avpkt);
+goto dequeue;
+}
+}
+return 0;
 }
 
 static av_cold int v4l2_encode_init(AVCodecContext *avctx)
@@ -349,16 +373,25 @@ static const AVOption options[] = {
 { NULL },
 };
 
-#define M2MENC_CLASS(NAME) \
+static const AVOption vp8_options[] = {
+V4L_M2M_DEFAULT_OPTS,
+{ "num_capture_buffers", "Number of buffers in the capture context",
+OFFSET(num_capture_buffers), AV_OPT_TYPE_INT, { .i64 = 4 }, 4, 
INT_MAX, FLAGS },
+{ "strip_ivf", "Strip ivf container",
+OFFSET(strip_ivf), AV_OPT_TYPE_BOOL, { .i64 = 1 }, 0, 1, FLAGS },
+{ NULL },
+};
+
+#define M2MENC_CLASS(NAME, OPTIONS) \
 static const AVClass v4l2_m2m_ ## NAME ## _enc_class = { \
 .class_name = #NAME "_v4l2m2m_encoder", \
 .item_name  = av_default_item_name, \
-.option = options, \
+.option = OPTIONS, \
 .version= LIBAVUTIL_VERSION_INT, \
 };
 
-#define M2MENC(NAME, LONGNAME, CODEC) \
-M2MENC_CLASS(NAME) \
+#define M2MENC(NAME, LONGNAME, CODEC, OPTIONS) \
+M2MENC_CLASS(NAME, OPTIONS) \
 AVCodec ff_ ## NAME ## _v4l2m2m_encoder = { \
 .name   = #NAME "_v4l2m2m" , \
 .long_name  = NULL_IF_CONFIG_SMALL("V4L2 mem2mem " LONGNAME " 
encoder wrapper"), \
@@ -374,8 +407,8 @@ static const AVOption options[] = {
 .wrapper_name   = "v4l2m2m", \
 };
 
-M2MENC(mpeg4,"MPEG4", AV_CODEC_ID_MPEG4);
-M2MENC(h263, "H.263", AV_CODEC_ID_H263);
-M2MENC(h264, "H.264", AV_CODEC_ID_H264);
-M2MENC(hevc, "HEVC",  AV_CODEC_ID_HEVC);
-M2MENC(vp8,  "VP8",   AV_CODEC_ID_VP8);
+M2MENC(mpeg4,"MPEG4", AV_CODEC_ID_MPEG4, options);
+M2MENC(h263, "H.263", AV_CODEC_ID_H263,  options);
+M2MENC(h264, "H.264", AV_CODEC_ID_H264,  options);
+M2MENC(hevc, "HEVC",  AV_CODEC_ID_HEVC,  options);
+M2MENC(vp8,  "VP8",   AV_CODEC_ID_VP8,   vp8_options);
-- 
2.25.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 v11 1/3] libavcodec/jpeg2000dec.c: Add support for PPT marker

2020-04-04 Thread Carl Eugen Hoyos
Am Sa., 4. Apr. 2020 um 22:20 Uhr schrieb Michael Niedermayer
:
>
> On Sat, Apr 04, 2020 at 01:14:51PM +0530, gautamr...@gmail.com wrote:
> > From: Gautam Ramakrishnan 
> >
> > This patch adds functional changes to support the
> > PPT marker.
>
> Does this fix any files / testcases ?
> If yes, they should be mentioned in the commit message

The patch is supposed to fix ticket #4610.

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] avformat/mov: Discard last STSC if its empty

2020-04-04 Thread Michael Niedermayer
On Tue, Feb 04, 2020 at 02:48:42PM +0100, Michael Niedermayer wrote:
> Fixes: Ticket8508
> ---
>  libavformat/mov.c | 4 
>  1 file changed, 4 insertions(+)

will apply

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

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



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

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

Re: [FFmpeg-devel] [PATCH] fftools/ffmpeg: Disable copy_ts on timestamp wraparound

2020-04-04 Thread Michael Niedermayer
On Fri, May 03, 2019 at 05:36:07PM +0200, Michael Niedermayer wrote:
> This allows handling more than 26.5h of mpeg* input
> 
> Fixes: Ticket 7876
> 
> Signed-off-by: Michael Niedermayer 
> ---
>  fftools/ffmpeg.c | 13 -
>  1 file changed, 12 insertions(+), 1 deletion(-)

will apply

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

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


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

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

Re: [FFmpeg-devel] [PATCH 4/4] swscale/output: Fix integer overflow in alpha computation in yuv2gbrp16_full_X_c()

2020-04-04 Thread Michael Niedermayer
On Sun, Feb 16, 2020 at 08:43:03PM +0100, Michael Niedermayer wrote:
> Fixes: signed integer overflow: 524280 * 4432 cannot be represented in type 
> 'int'
> Fixes: ticket8322
> 
> Found-by: Suhwan
> Signed-off-by: Michael Niedermayer 
> ---
>  libswscale/output.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

will apply

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

Everything should be made as simple as possible, but not simpler.
-- Albert Einstein


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

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

Re: [FFmpeg-devel] [PATCH 3/4] swscale/output: Fix integer overflow in yuv2rgb_write_full() with out of range input

2020-04-04 Thread Michael Niedermayer
On Sun, Feb 16, 2020 at 08:43:02PM +0100, Michael Niedermayer wrote:
> Fixes: signed integer overflow: 1169365504 + 981452800 cannot be represented 
> in type 'int'
> Fixes: ticket8293
> 
> Found-by: Suhwan
> Signed-off-by: Michael Niedermayer 
> ---
>  libswscale/output.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)

will apply

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

Never trust a computer, one day, it may think you are the virus. -- Compn


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 v11 1/3] libavcodec/jpeg2000dec.c: Add support for PPT marker

2020-04-04 Thread Michael Niedermayer
On Sat, Apr 04, 2020 at 01:14:51PM +0530, gautamr...@gmail.com wrote:
> From: Gautam Ramakrishnan 
> 
> This patch adds functional changes to support the
> PPT marker.

Does this fix any files / testcases ?
If yes, they should be mentioned in the commit message

thx

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

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


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

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

[FFmpeg-devel] [PATCH v2] avcodec/amfenc: adapt to the new internal encode API

2020-04-04 Thread James Almer
Signed-off-by: James Almer 
---
 libavcodec/amfenc.c  | 43 
 libavcodec/amfenc.h  |  2 --
 libavcodec/amfenc_h264.c |  1 -
 libavcodec/amfenc_hevc.c |  1 -
 4 files changed, 17 insertions(+), 30 deletions(-)

diff --git a/libavcodec/amfenc.c b/libavcodec/amfenc.c
index 876fddd2b6..da0652943d 100644
--- a/libavcodec/amfenc.c
+++ b/libavcodec/amfenc.c
@@ -33,6 +33,7 @@
 #include "libavutil/time.h"
 
 #include "amfenc.h"
+#include "encode.h"
 #include "internal.h"
 
 #if CONFIG_D3D11VA
@@ -588,17 +589,27 @@ static void amf_release_buffer_with_frame_ref(AMFBuffer 
*frame_ref_storage_buffe
 frame_ref_storage_buffer->pVtbl->Release(frame_ref_storage_buffer);
 }
 
-int ff_amf_send_frame(AVCodecContext *avctx, const AVFrame *frame)
+int ff_amf_receive_packet(AVCodecContext *avctx, AVPacket *avpkt)
 {
 AmfContext *ctx = avctx->priv_data;
 AMFSurface *surface;
 AMF_RESULT  res;
 int ret;
+AMF_RESULT  res_query;
+AMFData*data = NULL;
+AVFrame*frame = ctx->delayed_frame;
+int block_and_wait;
 
 if (!ctx->encoder)
 return AVERROR(EINVAL);
 
-if (!frame) { // submit drain
+if (!frame->buf[0]) {
+ret = ff_encode_get_frame(avctx, frame);
+if (ret < 0 && ret != AVERROR_EOF)
+return ret;
+}
+
+if (!frame->buf[0]) { // submit drain
 if (!ctx->eof) { // submit drain one time only
 if (ctx->delayed_surface != NULL) {
 ctx->delayed_drain = 1; // input queue is full: resubmit 
Drain() in ff_amf_receive_packet
@@ -613,15 +624,10 @@ int ff_amf_send_frame(AVCodecContext *avctx, const 
AVFrame *frame)
 AMF_RETURN_IF_FALSE(ctx, res == AMF_OK, AVERROR_UNKNOWN, 
"Drain() failed with error %d\n", res);
 }
 }
-} else{
-return AVERROR_EOF;
 }
-} else { // submit frame
+} else if (!ctx->delayed_surface) { // submit frame
 int hw_surface = 0;
 
-if (ctx->delayed_surface != NULL) {
-return AVERROR(EAGAIN); // should not happen when called from 
ffmpeg, other clients may resubmit
-}
 // prepare surface from frame
 switch (frame->format) {
 #if CONFIG_D3D11VA
@@ -693,38 +699,23 @@ int ff_amf_send_frame(AVCodecContext *avctx, const 
AVFrame *frame)
 break;
 }
 
-
 // submit surface
 res = ctx->encoder->pVtbl->SubmitInput(ctx->encoder, 
(AMFData*)surface);
 if (res == AMF_INPUT_FULL) { // handle full queue
 //store surface for later submission
 ctx->delayed_surface = surface;
-if (surface->pVtbl->GetMemoryType(surface) == AMF_MEMORY_DX11) {
-av_frame_ref(ctx->delayed_frame, frame);
-}
 } else {
+int64_t pts = frame->pts;
 surface->pVtbl->Release(surface);
 AMF_RETURN_IF_FALSE(ctx, res == AMF_OK, AVERROR_UNKNOWN, 
"SubmitInput() failed with error %d\n", res);
 
-if ((ret = timestamp_queue_enqueue(avctx, frame->pts)) < 0) {
+av_frame_unref(frame);
+if ((ret = timestamp_queue_enqueue(avctx, pts)) < 0) {
 return ret;
 }
-
 }
 }
-return 0;
-}
-int ff_amf_receive_packet(AVCodecContext *avctx, AVPacket *avpkt)
-{
-int ret;
-AMF_RESULT  res;
-AMF_RESULT  res_query;
-AmfContext *ctx = avctx->priv_data;
-AMFData*data = NULL;
-int block_and_wait;
 
-if (!ctx->encoder)
-return AVERROR(EINVAL);
 
 do {
 block_and_wait = 0;
diff --git a/libavcodec/amfenc.h b/libavcodec/amfenc.h
index b1361842bd..80658c6b2a 100644
--- a/libavcodec/amfenc.h
+++ b/libavcodec/amfenc.h
@@ -129,8 +129,6 @@ int ff_amf_encode_close(AVCodecContext *avctx);
 /**
 * Ecoding one frame - common function for all AMF encoders
 */
-
-int ff_amf_send_frame(AVCodecContext *avctx, const AVFrame *frame);
 int ff_amf_receive_packet(AVCodecContext *avctx, AVPacket *avpkt);
 
 /**
diff --git a/libavcodec/amfenc_h264.c b/libavcodec/amfenc_h264.c
index 7f2817f115..7a8029f3b7 100644
--- a/libavcodec/amfenc_h264.c
+++ b/libavcodec/amfenc_h264.c
@@ -383,7 +383,6 @@ AVCodec ff_h264_amf_encoder = {
 .type   = AVMEDIA_TYPE_VIDEO,
 .id = AV_CODEC_ID_H264,
 .init   = amf_encode_init_h264,
-.send_frame = ff_amf_send_frame,
 .receive_packet = ff_amf_receive_packet,
 .close  = ff_amf_encode_close,
 .priv_data_size = sizeof(AmfContext),
diff --git a/libavcodec/amfenc_hevc.c b/libavcodec/amfenc_hevc.c
index 77e57d2461..8b2302f2af 100644
--- a/libavcodec/amfenc_hevc.c
+++ b/libavcodec/amfenc_hevc.c
@@ -313,7 +313,6 @@ AVCodec ff_hevc_amf_encoder = {
 .type   = AVMEDIA_TYPE_VIDEO,
 .id = AV_CODEC_ID_HEVC,
 .init   = amf_encode_init_hevc,
-.send_frame = 

Re: [FFmpeg-devel] [PATCH] avcodec/amfenc: adapt to the new internal encode API

2020-04-04 Thread James Almer
On 4/4/2020 1:59 PM, Fu, Linjie wrote:
>> From: ffmpeg-devel  On Behalf Of
>> James Almer
>> Sent: Saturday, April 4, 2020 06:19
>> To: ffmpeg-devel@ffmpeg.org
>> Subject: [FFmpeg-devel] [PATCH] avcodec/amfenc: adapt to the new
>> internal encode API
>>
>> Signed-off-by: James Almer 
>> ---
>>  libavcodec/amfenc.c  | 45 
>>  libavcodec/amfenc.h  |  2 ++
>>  libavcodec/amfenc_h264.c |  1 -
>>  libavcodec/amfenc_hevc.c |  1 -
>>  4 files changed, 25 insertions(+), 24 deletions(-)
>>
>> diff --git a/libavcodec/amfenc.c b/libavcodec/amfenc.c
>> index 876fddd2b6..d318c21978 100644
>> --- a/libavcodec/amfenc.c
>> +++ b/libavcodec/amfenc.c
>> @@ -33,6 +33,7 @@
>>  #include "libavutil/time.h"
>>
>>  #include "amfenc.h"
>> +#include "encode.h"
>>  #include "internal.h"
>>
>>  #if CONFIG_D3D11VA
>> @@ -112,6 +113,10 @@ static int amf_load_library(AVCodecContext *avctx)
>>  AMFQueryVersion_Fn version_fun;
>>  AMF_RESULT res;
>>
>> +ctx->frame = av_frame_alloc();
>> +if (!ctx->frame) {
>> +return AVERROR(ENOMEM);
>> +}
>>  ctx->delayed_frame = av_frame_alloc();
>>  if (!ctx->delayed_frame) {
>>  return AVERROR(ENOMEM);
>> @@ -401,6 +406,7 @@ int av_cold ff_amf_encode_close(AVCodecContext
>> *avctx)
>>  ctx->factory = NULL;
>>  ctx->version = 0;
>>  ctx->delayed_drain = 0;
>> +av_frame_free(>frame);
>>  av_frame_free(>delayed_frame);
>>  av_fifo_freep(>timestamp_list);
>>
>> @@ -588,17 +594,27 @@ static void
>> amf_release_buffer_with_frame_ref(AMFBuffer
>> *frame_ref_storage_buffe
>>  frame_ref_storage_buffer->pVtbl->Release(frame_ref_storage_buffer);
>>  }
>>
>> -int ff_amf_send_frame(AVCodecContext *avctx, const AVFrame *frame)
>> +int ff_amf_receive_packet(AVCodecContext *avctx, AVPacket *avpkt)
> Would be better to remove the declaration in amfenc.h as well since the 
> function
> has been removed already?
> 
> - Linjie

Yeah, missed that. Will send an updated patch with some other changes.
___
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] fftools/ffmpeg: Disable copy_ts on timestamp wraparound

2020-04-04 Thread Michael Niedermayer
On Thu, Oct 10, 2019 at 01:37:50PM +0300, Aleksey Skripka wrote:
> Greetings!
> 
> Michael,
> patch works good for mpegts input, 
> 
> but for hls input it works only if add AVFMT_TS_DISCONT to .flags in 
> ff_hls_demuxer structure (libavformat/hls.c).
> Is it right way?

since d6ac6650b911f0957e69545d7fc25be6b7728705 we now have AVFMT_TS_DISCONT
set, so this should be resolved

thx


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

Everything should be made as simple as possible, but not simpler.
-- Albert Einstein


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

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

Re: [FFmpeg-devel] [PATCH] avformat/matroskaenc: add matroska subtitle muxer (.mks)

2020-04-04 Thread Jan Chren (rindeal)
On Sat, 4 Apr 2020 at 16:32, Andreas Rheinhardt
 wrote:
> What is the aim of your patch? If it is simply making sure that using
> the mks extension autoselects the Matroska muxer,

That's correct.

> then adding "mks" to
> the list of extensions of the ordinary Matroska muxer would be enough.
> (Notice that using mka for files with audio, but without video or mks
> for subtitle-only files is just a convention; putting something else
> than indicated by the extension in the files does not make them less
> spec-compliant.)

Should I create a new patch which removes the audio muxer and just
adds `mka` and `mks` extensions to the ordinary muxer?
Or is there some reason why a dedicated audio muxer must exist,
whereas a subtitle muxer does not?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [inline assembly compliance] Issues and patches

2020-04-04 Thread FRÉDÉRIC RECOULES
> i can retest and find a mininal command line for configure which triggers 
> this 
> in case you cannot reproduce it ? 

Thank you, but it is a known (non) issue of Clang and is reproducible since at 
least 3.4.1. 
The fact is that GCC uses incomplete types in to say "block of unknown size" 
but Clang have chosen to not follow it on this. 

Also, I have resubmitted the patches and I hope they will be more readable and 
useful. 

Regards, 
Frédéric Recoules 


De: "Michael Niedermayer"  
À: "ffmpeg-devel"  
Envoyé: Samedi 4 Avril 2020 18:55:27 
Objet: Re: [FFmpeg-devel] [inline assembly compliance] Issues and patches 

On Sat, Apr 04, 2020 at 12:28:43PM +0200, FRÉDÉRIC RECOULES wrote: 
> Thank you for your answers. 
> 
> As you have pointed out, these patches are full of unrelated changes that are 
> not important for safety. 
> Most of them were never intended to be posted here, the diff we submitted was 
> the one of an 
> experimental branch and we apologize to have made such a mistake. 
> We will resubmit the patch with only essential patches in a more appropriate 
> format very soon 
> (git format-patch). 
> 
> @Michael These errors come with the Clang compiler, aren't they? 

yes, seems this was 
clang version 4.0.0 (trunk 283753) 

i can retest and find a mininal command line for configure which triggers this 
in case you cannot reproduce it ? 


> We are aware that support for inline assembly may differ from one compiler to 
> another 
> despite the "higly-compatibility" that is stated. The safety patches we are 
> proposing 
> do not rely on them. 
> 
> @Carl @Kieran So far, we passed the FATE tests. 
> The output is slightly different because we have merged contiguous assembly 
> statement 
> such that the compiler can no longer insert instruction between them, but the 
> differences 
> are only instruction swaps A.B.C -> B.A.C. 

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

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

___ 
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] avutil/log: update text requesting samples

2020-04-04 Thread Marton Balint
Signed-off-by: Marton Balint 
---
 libavutil/log.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/libavutil/log.c b/libavutil/log.c
index 8d4945249e..a0b2348bd5 100644
--- a/libavutil/log.c
+++ b/libavutil/log.c
@@ -466,9 +466,9 @@ static void missing_feature_sample(int sample, void *avc, 
const char *msg,
"occurs, it means that your file has a feature which has not "
"been implemented.\n");
 if (sample)
-av_log(avc, AV_LOG_WARNING, "If you want to help, upload a sample "
-   "of this file to ftp://upload.ffmpeg.org/incoming/ "
-   "and contact the ffmpeg-devel mailing list. 
(ffmpeg-devel@ffmpeg.org)\n");
+av_log(avc, AV_LOG_WARNING, "If you want to help, open an enhancement "
+"ticket on https://trac.ffmpeg.org/ and upload a sample of this "
+"file to https://streams.videolan.org/upload/\n;);
 }
 
 void avpriv_request_sample(void *avc, const char *msg, ...)
-- 
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".

Re: [FFmpeg-devel] [PATCH] avformat/matroskaenc: add matroska subtitle muxer (.mks)

2020-04-04 Thread Jan Chren (rindeal)
On Sat, 4 Apr 2020 at 16:32, Andreas Rheinhardt
 wrote:
>
> You should read my answers to your earlier mails.

Any earlier mails have not reached either my mailbox or Patchwork. But
hopefully I have found them in the public mail archive now. Terrible
workflow got even worse...

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

Re: [FFmpeg-devel] [PATCH] avcodec/amfenc: adapt to the new internal encode API

2020-04-04 Thread Fu, Linjie
> From: ffmpeg-devel  On Behalf Of
> James Almer
> Sent: Saturday, April 4, 2020 06:19
> To: ffmpeg-devel@ffmpeg.org
> Subject: [FFmpeg-devel] [PATCH] avcodec/amfenc: adapt to the new
> internal encode API
> 
> Signed-off-by: James Almer 
> ---
>  libavcodec/amfenc.c  | 45 
>  libavcodec/amfenc.h  |  2 ++
>  libavcodec/amfenc_h264.c |  1 -
>  libavcodec/amfenc_hevc.c |  1 -
>  4 files changed, 25 insertions(+), 24 deletions(-)
> 
> diff --git a/libavcodec/amfenc.c b/libavcodec/amfenc.c
> index 876fddd2b6..d318c21978 100644
> --- a/libavcodec/amfenc.c
> +++ b/libavcodec/amfenc.c
> @@ -33,6 +33,7 @@
>  #include "libavutil/time.h"
> 
>  #include "amfenc.h"
> +#include "encode.h"
>  #include "internal.h"
> 
>  #if CONFIG_D3D11VA
> @@ -112,6 +113,10 @@ static int amf_load_library(AVCodecContext *avctx)
>  AMFQueryVersion_Fn version_fun;
>  AMF_RESULT res;
> 
> +ctx->frame = av_frame_alloc();
> +if (!ctx->frame) {
> +return AVERROR(ENOMEM);
> +}
>  ctx->delayed_frame = av_frame_alloc();
>  if (!ctx->delayed_frame) {
>  return AVERROR(ENOMEM);
> @@ -401,6 +406,7 @@ int av_cold ff_amf_encode_close(AVCodecContext
> *avctx)
>  ctx->factory = NULL;
>  ctx->version = 0;
>  ctx->delayed_drain = 0;
> +av_frame_free(>frame);
>  av_frame_free(>delayed_frame);
>  av_fifo_freep(>timestamp_list);
> 
> @@ -588,17 +594,27 @@ static void
> amf_release_buffer_with_frame_ref(AMFBuffer
> *frame_ref_storage_buffe
>  frame_ref_storage_buffer->pVtbl->Release(frame_ref_storage_buffer);
>  }
> 
> -int ff_amf_send_frame(AVCodecContext *avctx, const AVFrame *frame)
> +int ff_amf_receive_packet(AVCodecContext *avctx, AVPacket *avpkt)
Would be better to remove the declaration in amfenc.h as well since the function
has been removed already?

- Linjie

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

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

Re: [FFmpeg-devel] [inline assembly compliance] Issues and patches

2020-04-04 Thread Michael Niedermayer
On Sat, Apr 04, 2020 at 12:28:43PM +0200, FRÉDÉRIC RECOULES wrote:
> Thank you for your answers. 
> 
> As you have pointed out, these patches are full of unrelated changes that are 
> not important for safety. 
> Most of them were never intended to be posted here, the diff we submitted was 
> the one of an 
> experimental branch and we apologize to have made such a mistake. 
> We will resubmit the patch with only essential patches in a more appropriate 
> format very soon 
> (git format-patch). 
> 
> @Michael These errors come with the Clang compiler, aren't they? 

yes, seems this was
clang version 4.0.0 (trunk 283753)

i can retest and find a mininal command line for configure which triggers this
in case you cannot reproduce it ?


> We are aware that support for inline assembly may differ from one compiler to 
> another 
> despite the "higly-compatibility" that is stated. The safety patches we are 
> proposing 
> do not rely on them. 
> 
> @Carl @Kieran So far, we passed the FATE tests. 
> The output is slightly different because we have merged contiguous assembly 
> statement 
> such that the compiler can no longer insert instruction between them, but the 
> differences 
> are only instruction swaps A.B.C -> B.A.C. 

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

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


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

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

[FFmpeg-devel] [PATCH] lavc/vaapi_encode: adapt to the new internal encode API

2020-04-04 Thread Linjie Fu
Should be squashed with:


Tested with:
ffmpeg -hwaccel vaapi -vaapi_device /dev/dri/renderD128 -hwaccel_output_format 
vaapi \
-i ../bbb_sunflower_1080p_30fps_normal.mp4 -c:v h264_vaapi -f h264  -y 
/dev/null

Performance improved from 120 fps to 136 fps after applying this patch.

Signed-off-by: Linjie Fu 
---
Futher more, if integrated with the fix to async the encoding and output 
procedure in [1],
the fps reaches 155 fps.

[1] 
https://patchwork.ffmpeg.org/project/ffmpeg/patch/20191107163203.6799-1-linjie...@intel.com/

 libavcodec/vaapi_encode.c   | 26 ++
 libavcodec/vaapi_encode.h   |  4 +++-
 libavcodec/vaapi_encode_h264.c  |  1 -
 libavcodec/vaapi_encode_h265.c  |  1 -
 libavcodec/vaapi_encode_mjpeg.c |  1 -
 libavcodec/vaapi_encode_mpeg2.c |  1 -
 libavcodec/vaapi_encode_vp8.c   |  1 -
 libavcodec/vaapi_encode_vp9.c   |  1 -
 8 files changed, 25 insertions(+), 11 deletions(-)

diff --git a/libavcodec/vaapi_encode.c b/libavcodec/vaapi_encode.c
index 8ff720e..1424380 100644
--- a/libavcodec/vaapi_encode.c
+++ b/libavcodec/vaapi_encode.c
@@ -25,6 +25,7 @@
 #include "libavutil/pixdesc.h"
 
 #include "vaapi_encode.h"
+#include "encode.h"
 #include "avcodec.h"
 
 static const char * const picture_type_name[] = { "IDR", "I", "P", "B" };
@@ -1038,7 +1039,7 @@ static int vaapi_encode_check_frame(AVCodecContext *avctx,
 return 0;
 }
 
-int ff_vaapi_encode_send_frame(AVCodecContext *avctx, const AVFrame *frame)
+static int vaapi_encode_send_frame(AVCodecContext *avctx, AVFrame *frame)
 {
 VAAPIEncodeContext *ctx = avctx->priv_data;
 VAAPIEncodePicture *pic;
@@ -1061,9 +1062,7 @@ int ff_vaapi_encode_send_frame(AVCodecContext *avctx, 
const AVFrame *frame)
 err = AVERROR(ENOMEM);
 goto fail;
 }
-err = av_frame_ref(pic->input_image, frame);
-if (err < 0)
-goto fail;
+av_frame_move_ref(pic->input_image, frame);
 
 if (ctx->input_order == 0 || frame->pict_type == AV_PICTURE_TYPE_I)
 pic->force_idr = 1;
@@ -1109,8 +1108,20 @@ int ff_vaapi_encode_receive_packet(AVCodecContext 
*avctx, AVPacket *pkt)
 {
 VAAPIEncodeContext *ctx = avctx->priv_data;
 VAAPIEncodePicture *pic;
+AVFrame *frame = ctx->frame;
 int err;
 
+err = ff_encode_get_frame(avctx, frame);
+if (err < 0 && err != AVERROR_EOF)
+return err;
+
+if (err == AVERROR_EOF)
+frame = NULL;
+
+err = vaapi_encode_send_frame(avctx, frame);
+if (err < 0)
+return err;
+
 if (!ctx->pic_start) {
 if (ctx->end_of_stream)
 return AVERROR_EOF;
@@ -2209,6 +2220,11 @@ av_cold int ff_vaapi_encode_init(AVCodecContext *avctx)
 VAStatus vas;
 int err;
 
+ctx->frame = av_frame_alloc();
+if (!ctx->frame) {
+return AVERROR(ENOMEM);
+}
+
 if (!avctx->hw_frames_ctx) {
 av_log(avctx, AV_LOG_ERROR, "A hardware frames reference is "
"required to associate the encoding device.\n");
@@ -2387,6 +2403,8 @@ av_cold int ff_vaapi_encode_close(AVCodecContext *avctx)
 ctx->va_config = VA_INVALID_ID;
 }
 
+av_frame_free(>frame);
+
 av_freep(>codec_sequence_params);
 av_freep(>codec_picture_params);
 
diff --git a/libavcodec/vaapi_encode.h b/libavcodec/vaapi_encode.h
index b9a3def..c4d1412 100644
--- a/libavcodec/vaapi_encode.h
+++ b/libavcodec/vaapi_encode.h
@@ -325,6 +325,9 @@ typedef struct VAAPIEncodeContext {
 // If the driver does not support ROI then warn the first time we
 // encounter a frame with ROI side data.
 int roi_warned;
+
+// Adapt to the new internal encode API
+AVFrame *frame;
 } VAAPIEncodeContext;
 
 enum {
@@ -416,7 +419,6 @@ typedef struct VAAPIEncodeType {
 } VAAPIEncodeType;
 
 
-int ff_vaapi_encode_send_frame(AVCodecContext *avctx, const AVFrame *frame);
 int ff_vaapi_encode_receive_packet(AVCodecContext *avctx, AVPacket *pkt);
 
 int ff_vaapi_encode_init(AVCodecContext *avctx);
diff --git a/libavcodec/vaapi_encode_h264.c b/libavcodec/vaapi_encode_h264.c
index f4965d8..58de2a1 100644
--- a/libavcodec/vaapi_encode_h264.c
+++ b/libavcodec/vaapi_encode_h264.c
@@ -1351,7 +1351,6 @@ AVCodec ff_h264_vaapi_encoder = {
 .id = AV_CODEC_ID_H264,
 .priv_data_size = sizeof(VAAPIEncodeH264Context),
 .init   = _encode_h264_init,
-.send_frame = _vaapi_encode_send_frame,
 .receive_packet = _vaapi_encode_receive_packet,
 .close  = _encode_h264_close,
 .priv_class = _encode_h264_class,
diff --git a/libavcodec/vaapi_encode_h265.c b/libavcodec/vaapi_encode_h265.c
index 97dc5a7..97a18f5 100644
--- a/libavcodec/vaapi_encode_h265.c
+++ b/libavcodec/vaapi_encode_h265.c
@@ -1287,7 +1287,6 @@ AVCodec ff_hevc_vaapi_encoder = {
 .id = AV_CODEC_ID_HEVC,
 .priv_data_size = 

Re: [FFmpeg-devel] [PATCH 2/2] lavc/libaomenc: Support lossless encoding

2020-04-04 Thread Ryo Hirafuji
> In an ideal world, crf 0 would force all other settings for a lossless
encoding.

I forgot to say that if "-lossless 1" is set, "crf" will also be 0 (in
libaom, internally).

All those conditions will be forced (ot at least checked by libaom) if we
execute this line:

> codecctl_int(avctx, AV1E_SET_LOSSLESS, ctx->lossless);

So, how about executing this line if the "-crf 0" is set?
libaom changes so fast, so this might be a more robust way to ensure
lossless encoding, rather than setting those settings by hand.

If it's okay, I will make an additional patch.

2020年4月5日(日) 0:34 Carl Eugen Hoyos :

> Am Sa., 4. Apr. 2020 um 13:17 Uhr schrieb Ryo Hirafuji
> :
> >
> > > So "crf 0" already has a meaning different from all other crf values?
> >
> > No. "crf 0" has the same meanings. It just makes the quality better than
> > "crf 1".
>
> That was my question, sorry for being unclear.
>
> > I read libaom again, and I apologize for my wrong explanation:
> > I found that if certain conditions are met, "crf 0" also generates
> > lossless videos.
> >
> > If these conditions are not met, "-crf 0" will be lossless:
> >
> > <>
> >   "-bit_rate 0" (which means, enccfg.rc_end_usage = AOM_Q)
> >   "-aq-mode none"
> >   "-enable_restoration 0"
> >
> > <>
> >   AV1E_SET_ENABLE_CHROMA_DELTAQ must be 0
> >   AV1E_SET_ENABLE_SUPERRES must be 0
> >
> > Thus, at least, "-lossless" does have a different meaning from "-crf 0",
> > so I think it would be useful to add "-lossless" flags.
>
> In an ideal world, crf 0 would force all other settings for a lossless
> encoding.
>
> Carl Eugen
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

[FFmpeg-devel] [PATCH] hwcontext_vulkan: only use one semaphore per image

2020-04-04 Thread Lynne
The idea was to allow separate planes to be filtered independently, however,
in hindsight, literaly nothing uses separate per-plane semaphores and it
would only work when each plane is backed by separate device memory.

Patch attached.

>From 39506e3d6d703b070d861f88d4cde5689eea7ae2 Mon Sep 17 00:00:00 2001
From: Lynne 
Date: Sat, 4 Apr 2020 17:19:59 +0100
Subject: [PATCH] hwcontext_vulkan: only use one semaphore per image

The idea was to allow separate planes to be filtered independently, however,
in hindsight, literaly nothing uses separate per-plane semaphores and it
would only work when each plane is backed by separate device memory.
---
 libavfilter/vulkan.c |  38 +-
 libavutil/hwcontext_vulkan.c | 131 ++-
 libavutil/hwcontext_vulkan.h |   4 +-
 3 files changed, 86 insertions(+), 87 deletions(-)

diff --git a/libavfilter/vulkan.c b/libavfilter/vulkan.c
index ff76ab15e9..c103440529 100644
--- a/libavfilter/vulkan.c
+++ b/libavfilter/vulkan.c
@@ -390,32 +390,28 @@ int ff_vk_add_exec_dep(AVFilterContext *avctx, FFVkExecContext *e,
AVFrame *frame, VkPipelineStageFlagBits in_wait_dst_flag)
 {
 AVVkFrame *f = (AVVkFrame *)frame->data[0];
-AVHWFramesContext *fc = (AVHWFramesContext *)frame->hw_frames_ctx->data;
-int planes = av_pix_fmt_count_planes(fc->sw_format);
 
-for (int i = 0; i < planes; i++) {
-e->sem_wait = av_fast_realloc(e->sem_wait, >sem_wait_alloc,
-  (e->sem_wait_cnt + 1)*sizeof(*e->sem_wait));
-if (!e->sem_wait)
-return AVERROR(ENOMEM);
+e->sem_wait = av_fast_realloc(e->sem_wait, >sem_wait_alloc,
+  (e->sem_wait_cnt + 1)*sizeof(*e->sem_wait));
+if (!e->sem_wait)
+return AVERROR(ENOMEM);
 
-e->sem_wait_dst = av_fast_realloc(e->sem_wait_dst, >sem_wait_dst_alloc,
-  (e->sem_wait_cnt + 1)*sizeof(*e->sem_wait_dst));
-if (!e->sem_wait_dst)
-return AVERROR(ENOMEM);
+e->sem_wait_dst = av_fast_realloc(e->sem_wait_dst, >sem_wait_dst_alloc,
+  (e->sem_wait_cnt + 1)*sizeof(*e->sem_wait_dst));
+if (!e->sem_wait_dst)
+return AVERROR(ENOMEM);
 
-e->sem_sig = av_fast_realloc(e->sem_sig, >sem_sig_alloc,
- (e->sem_sig_cnt + 1)*sizeof(*e->sem_sig));
-if (!e->sem_sig)
-return AVERROR(ENOMEM);
+e->sem_sig = av_fast_realloc(e->sem_sig, >sem_sig_alloc,
+ (e->sem_sig_cnt + 1)*sizeof(*e->sem_sig));
+if (!e->sem_sig)
+return AVERROR(ENOMEM);
 
-e->sem_wait[e->sem_wait_cnt] = f->sem[i];
-e->sem_wait_dst[e->sem_wait_cnt] = in_wait_dst_flag;
-e->sem_wait_cnt++;
+e->sem_wait[e->sem_wait_cnt] = f->sem;
+e->sem_wait_dst[e->sem_wait_cnt] = in_wait_dst_flag;
+e->sem_wait_cnt++;
 
-e->sem_sig[e->sem_sig_cnt] = f->sem[i];
-e->sem_sig_cnt++;
-}
+e->sem_sig[e->sem_sig_cnt] = f->sem;
+e->sem_sig_cnt++;
 
 return 0;
 }
diff --git a/libavutil/hwcontext_vulkan.c b/libavutil/hwcontext_vulkan.c
index ed88979d0d..7eb333b353 100644
--- a/libavutil/hwcontext_vulkan.c
+++ b/libavutil/hwcontext_vulkan.c
@@ -81,7 +81,7 @@ typedef struct AVVkFrameInternal {
 CUexternalMemory ext_mem[AV_NUM_DATA_POINTERS];
 CUmipmappedArray cu_mma[AV_NUM_DATA_POINTERS];
 CUarray cu_array[AV_NUM_DATA_POINTERS];
-CUexternalSemaphore cu_sem[AV_NUM_DATA_POINTERS];
+CUexternalSemaphore cu_sem;
 #endif
 } AVVkFrameInternal;
 
@@ -1042,9 +1042,10 @@ static void vulkan_free_internal(AVVkFrameInternal *internal)
 AVCUDADeviceContextInternal *cu_internal = cuda_dev->internal;
 CudaFunctions *cu = cu_internal->cuda_dl;
 
+if (internal->cu_sem)
+CHECK_CU(cu->cuDestroyExternalSemaphore(internal->cu_sem));
+
 for (int i = 0; i < planes; i++) {
-if (internal->cu_sem[i])
-CHECK_CU(cu->cuDestroyExternalSemaphore(internal->cu_sem[i]));
 if (internal->cu_mma[i])
 CHECK_CU(cu->cuMipmappedArrayDestroy(internal->cu_mma[i]));
 if (internal->ext_mem[i])
@@ -1070,9 +1071,10 @@ static void vulkan_frame_free(void *opaque, uint8_t *data)
 for (int i = 0; i < planes; i++) {
 vkDestroyImage(hwctx->act_dev, f->img[i], hwctx->alloc);
 vkFreeMemory(hwctx->act_dev, f->mem[i], hwctx->alloc);
-vkDestroySemaphore(hwctx->act_dev, f->sem[i], hwctx->alloc);
 }
 
+vkDestroySemaphore(hwctx->act_dev, f->sem, hwctx->alloc);
+
 av_free(f);
 }
 
@@ -1166,8 +1168,8 @@ static int prepare_frame(AVHWFramesContext *hwfc, VulkanExecCtx *ectx,
 .commandBufferCount   = 1,
 .pCommandBuffers  = >buf,
 
-.pSignalSemaphores= frame->sem,
-.signalSemaphoreCount = planes,
+.pSignalSemaphores= >sem,
+

Re: [FFmpeg-devel] [PATCH] avformat/matroskaenc: add matroska subtitle muxer (.mks)

2020-04-04 Thread Andreas Rheinhardt
Jan Chren (rindeal):
> On Sat, 4 Apr 2020 at 15:56, Paul B Mahol  wrote:
>>
>> Looks like you sent exactly same patch as before.
>>
> 
> This is actually the third time I sent it, but first time it went
> through to Patchwork, which is what counts.
> 
>> This patch does unfortunately nothing as some changes from other files
>> are missing.
> 
> Do you happen to know what the "other files" might be?

You should read my answers to your earlier mails.

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

Re: [FFmpeg-devel] [PATCH] avformat/matroskaenc: add matroska subtitle muxer (.mks)

2020-04-04 Thread Jan Chren (rindeal)
On Sat, 4 Apr 2020 at 15:56, Paul B Mahol  wrote:
>
> Looks like you sent exactly same patch as before.
>

This is actually the third time I sent it, but first time it went
through to Patchwork, which is what counts.

> This patch does unfortunately nothing as some changes from other files
> are missing.

Do you happen to know what the "other files" might be?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [PATCH] avformat/matroskaenc: remove MAX_TRACKS limit

2020-04-04 Thread Carl Eugen Hoyos
Am Sa., 4. Apr. 2020 um 17:46 Uhr schrieb Jan Chren (rindeal)
:

> [...]

I believe the question was: How did you test your patch?

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

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

Re: [FFmpeg-devel] [PATCH] avformat/matroskaenc: add matroska subtitle muxer (.mks)

2020-04-04 Thread Paul B Mahol
On 4/4/20, Jan Chren (rindeal)  wrote:
>
>

Looks like you sent exactly same patch as before.

This patch does unfortunately nothing as some changes from other files
are missing.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

[FFmpeg-devel] [PATCH] avformat/matroskaenc: add matroska subtitle muxer (.mks)

2020-04-04 Thread Jan Chren (rindeal)

From eaa9f2685436725e19eb94e7f2d0174ba56b7429 Mon Sep 17 00:00:00 2001
From: Jan Chren (rindeal) 
Date: Thu, 1 Apr 2020 00:00:00 +
Subject: [PATCH] avformat/matroskaenc: add matroska subtitle muxer (.mks)

Signed-off-by: Jan Chren (rindeal) 
---
 libavformat/matroskaenc.c | 28 
 1 file changed, 28 insertions(+)

diff --git a/libavformat/matroskaenc.c b/libavformat/matroskaenc.c
index 5dae53026d8..62127fe97f0 100644
--- a/libavformat/matroskaenc.c
+++ b/libavformat/matroskaenc.c
@@ -2793,3 +2793,31 @@ AVOutputFormat ff_matroska_audio_muxer = {
 .priv_class= _class,
 };
 #endif
+
+#if CONFIG_MATROSKA_SUBTITLE_MUXER
+static const AVClass mks_class = {
+.class_name = "matroska subtitle muxer",
+.item_name  = av_default_item_name,
+.option = options,
+.version= LIBAVUTIL_VERSION_INT,
+};
+AVOutputFormat ff_matroska_subtitle_muxer = {
+.name  = "matroska",
+.long_name = NULL_IF_CONFIG_SMALL("Matroska Subtitles"),
+.extensions= "mks",
+.priv_data_size= sizeof(MatroskaMuxContext),
+.subtitle_codec= AV_CODEC_ID_ASS,
+.init  = mkv_init,
+.deinit= mkv_deinit,
+.write_header  = mkv_write_header,
+.write_packet  = mkv_write_flush_packet,
+.write_trailer = mkv_write_trailer,
+.check_bitstream   = mkv_check_bitstream,
+.flags = AVFMT_GLOBALHEADER | AVFMT_VARIABLE_FPS |
+ AVFMT_TS_NONSTRICT | AVFMT_ALLOW_FLUSH,
+.codec_tag = (const AVCodecTag* const []){
+additional_subtitle_tags, 0
+},
+.priv_class= _class,
+};
+#endif
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

[FFmpeg-devel] [PATCH] avformat/matroskaenc: remove MAX_TRACKS limit

2020-04-04 Thread Jan Chren (rindeal)

From 43e4b9695a4342112b1117db6526bafa1f9dab3e Mon Sep 17 00:00:00 2001
From: Jan Chren (rindeal) 
Date: Thu, 1 Apr 2020 00:00:00 +
Subject: [PATCH] avformat/matroskaenc: remove MAX_TRACKS limit

It was introduced in 7be0f48a32155ef9f471ffc5a1b41d662ea337f1
to set size of an array struct field, but that bad design was fixed
in 65ef74f74900590f134b4a130e8f56e5272d1925.
As such this artificial limit serves no purpose anymore.

Signed-off-by: Jan Chren (rindeal) 
---
 libavformat/matroskaenc.c | 11 ---
 1 file changed, 11 deletions(-)

diff --git a/libavformat/matroskaenc.c b/libavformat/matroskaenc.c
index 5dae53026d8..3af05403d1d 100644
--- a/libavformat/matroskaenc.c
+++ b/libavformat/matroskaenc.c
@@ -117,10 +117,6 @@ typedef struct mkv_attachments {
 #define MODE_MATROSKAv2 0x01
 #define MODE_WEBM   0x02
 
-/** Maximum number of tracks allowed in a Matroska file (with track numbers in
- * range 1 to 126 (inclusive) */
-#define MAX_TRACKS 126
-
 typedef struct MatroskaMuxContext {
 const AVClass   *class;
 int mode;
@@ -2604,13 +2600,6 @@ static int mkv_init(struct AVFormatContext *s)
 {
 int i;
 
-if (s->nb_streams > MAX_TRACKS) {
-av_log(s, AV_LOG_ERROR,
-   "At most %d streams are supported for muxing in Matroska\n",
-   MAX_TRACKS);
-return AVERROR(EINVAL);
-}
-
 for (i = 0; i < s->nb_streams; i++) {
 if (s->streams[i]->codecpar->codec_id == AV_CODEC_ID_ATRAC3 ||
 s->streams[i]->codecpar->codec_id == AV_CODEC_ID_COOK ||
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [PATCH 2/2] lavc/libaomenc: Support lossless encoding

2020-04-04 Thread Carl Eugen Hoyos
Am Sa., 4. Apr. 2020 um 13:17 Uhr schrieb Ryo Hirafuji
:
>
> > So "crf 0" already has a meaning different from all other crf values?
>
> No. "crf 0" has the same meanings. It just makes the quality better than
> "crf 1".

That was my question, sorry for being unclear.

> I read libaom again, and I apologize for my wrong explanation:
> I found that if certain conditions are met, "crf 0" also generates
> lossless videos.
>
> If these conditions are not met, "-crf 0" will be lossless:
>
> <>
>   "-bit_rate 0" (which means, enccfg.rc_end_usage = AOM_Q)
>   "-aq-mode none"
>   "-enable_restoration 0"
>
> <>
>   AV1E_SET_ENABLE_CHROMA_DELTAQ must be 0
>   AV1E_SET_ENABLE_SUPERRES must be 0
>
> Thus, at least, "-lossless" does have a different meaning from "-crf 0",
> so I think it would be useful to add "-lossless" flags.

In an ideal world, crf 0 would force all other settings for a lossless
encoding.

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] avformat/mpegts: use buffer pools for allocating packets

2020-04-04 Thread Marton Balint



On Sat, 4 Apr 2020, James Almer wrote:


On 4/4/2020 11:47 AM, Marton Balint wrote:

This brings a performance improvement when demuxing files, most of the
improvement comes from buffer pooling unbound packets.


Yes, as i mentioned in my last reply this was my experience as well.



time ffprobe -i samples/ffmpeg-bugs/trac/ticket6132/Samsung_HDR_-_Chasing_the_Light.ts 
-show_packets >/dev/null 2>&1

Before:
real0m1.967s
user0m1.471s
sys 0m0.493s

After:
real0m1.497s
user0m1.364s
sys 0m0.129s

Based on a patch of James Almer.

Signed-off-by: Marton Balint 
---
 libavformat/mpegts.c | 23 +++
 1 file changed, 19 insertions(+), 4 deletions(-)

diff --git a/libavformat/mpegts.c b/libavformat/mpegts.c
index 7f56bacb2c..fbafc1d257 100644
--- a/libavformat/mpegts.c
+++ b/libavformat/mpegts.c
@@ -170,6 +170,7 @@ struct MpegTSContext {
 int current_pid;

 AVStream *epg_stream;
+AVBufferPool* pools[32];


Isn't 32 way more than required?


The number of required pools is 
log2(MAX_PES_PAYLOAD+AV_INPUT_BUFFER_PADDING_SIZE)+1, so currently 18, but 
since as far as I know there is no compile time log2 I did not want to 
limit it here so MAX_PES_PAYLOAD can still be changeable without adjusting 
this.





 };

 #define MPEGTS_OPTIONS \
@@ -1103,6 +1104,18 @@ static int read_sl_header(PESContext *pes, SLConfigDescr 
*sl,
 return (get_bits_count() + 7) >> 3;
 }

+static AVBufferRef *buffer_pool_get(MpegTSContext *ts, int size)
+{
+int index = av_log2(size + AV_INPUT_BUFFER_PADDING_SIZE);
+if (!ts->pools[index]) {
+int pool_size = FFMIN(MAX_PES_PAYLOAD + AV_INPUT_BUFFER_PADDING_SIZE, 2 
<< index);
+ts->pools[index] = av_buffer_pool_init(pool_size, NULL);
+if (!ts->pools[index])
+return NULL;
+}
+return av_buffer_pool_get(ts->pools[index]);
+}
+
 /* return non zero if a packet could be constructed */
 static int mpegts_push_data(MpegTSFilter *filter,
 const uint8_t *buf, int buf_size, int is_start,
@@ -1177,8 +1190,8 @@ static int mpegts_push_data(MpegTSFilter *filter,
 pes->total_size = MAX_PES_PAYLOAD;

 /* allocate pes buffer */
-pes->buffer = av_buffer_alloc(pes->total_size +
-  
AV_INPUT_BUFFER_PADDING_SIZE);
+pes->buffer = buffer_pool_get(ts, pes->total_size);
+
 if (!pes->buffer)
 return AVERROR(ENOMEM);

@@ -1351,8 +1364,7 @@ skip:
 if (ret < 0)
 return ret;
 pes->total_size = MAX_PES_PAYLOAD;
-pes->buffer = av_buffer_alloc(pes->total_size +
-  
AV_INPUT_BUFFER_PADDING_SIZE);
+pes->buffer = buffer_pool_get(ts, pes->total_size);
 if (!pes->buffer)
 return AVERROR(ENOMEM);
 ts->stop_parse = 1;
@@ -3200,6 +3212,9 @@ static void mpegts_free(MpegTSContext *ts)

 clear_programs(ts);

+for (i = 0; i < FF_ARRAY_ELEMS(ts->pools); i++)
+av_buffer_pool_uninit(>pools[i]);
+
 for (i = 0; i < NB_PID_MAX; i++)
 if (ts->pids[i])
 mpegts_close_filter(ts, ts->pids[i]);


LGTM. I assume the pools for the smaller sizes will not end up being
slower than just allocating new buffers each time.


I tried to measure this but there was no significant difference.

Will apply.

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] avformat/mpegts: use buffer pools for allocating packets

2020-04-04 Thread James Almer
On 4/4/2020 11:47 AM, Marton Balint wrote:
> This brings a performance improvement when demuxing files, most of the
> improvement comes from buffer pooling unbound packets.

Yes, as i mentioned in my last reply this was my experience as well.

> 
> time ffprobe -i 
> samples/ffmpeg-bugs/trac/ticket6132/Samsung_HDR_-_Chasing_the_Light.ts 
> -show_packets >/dev/null 2>&1
> 
> Before:
> real0m1.967s
> user0m1.471s
> sys 0m0.493s
> 
> After:
> real0m1.497s
> user0m1.364s
> sys 0m0.129s
> 
> Based on a patch of James Almer.
> 
> Signed-off-by: Marton Balint 
> ---
>  libavformat/mpegts.c | 23 +++
>  1 file changed, 19 insertions(+), 4 deletions(-)
> 
> diff --git a/libavformat/mpegts.c b/libavformat/mpegts.c
> index 7f56bacb2c..fbafc1d257 100644
> --- a/libavformat/mpegts.c
> +++ b/libavformat/mpegts.c
> @@ -170,6 +170,7 @@ struct MpegTSContext {
>  int current_pid;
>  
>  AVStream *epg_stream;
> +AVBufferPool* pools[32];

Isn't 32 way more than required?

>  };
>  
>  #define MPEGTS_OPTIONS \
> @@ -1103,6 +1104,18 @@ static int read_sl_header(PESContext *pes, 
> SLConfigDescr *sl,
>  return (get_bits_count() + 7) >> 3;
>  }
>  
> +static AVBufferRef *buffer_pool_get(MpegTSContext *ts, int size)
> +{
> +int index = av_log2(size + AV_INPUT_BUFFER_PADDING_SIZE);
> +if (!ts->pools[index]) {
> +int pool_size = FFMIN(MAX_PES_PAYLOAD + 
> AV_INPUT_BUFFER_PADDING_SIZE, 2 << index);
> +ts->pools[index] = av_buffer_pool_init(pool_size, NULL);
> +if (!ts->pools[index])
> +return NULL;
> +}
> +return av_buffer_pool_get(ts->pools[index]);
> +}
> +
>  /* return non zero if a packet could be constructed */
>  static int mpegts_push_data(MpegTSFilter *filter,
>  const uint8_t *buf, int buf_size, int is_start,
> @@ -1177,8 +1190,8 @@ static int mpegts_push_data(MpegTSFilter *filter,
>  pes->total_size = MAX_PES_PAYLOAD;
>  
>  /* allocate pes buffer */
> -pes->buffer = av_buffer_alloc(pes->total_size +
> -  
> AV_INPUT_BUFFER_PADDING_SIZE);
> +pes->buffer = buffer_pool_get(ts, pes->total_size);
> +
>  if (!pes->buffer)
>  return AVERROR(ENOMEM);
>  
> @@ -1351,8 +1364,7 @@ skip:
>  if (ret < 0)
>  return ret;
>  pes->total_size = MAX_PES_PAYLOAD;
> -pes->buffer = av_buffer_alloc(pes->total_size +
> -  
> AV_INPUT_BUFFER_PADDING_SIZE);
> +pes->buffer = buffer_pool_get(ts, pes->total_size);
>  if (!pes->buffer)
>  return AVERROR(ENOMEM);
>  ts->stop_parse = 1;
> @@ -3200,6 +3212,9 @@ static void mpegts_free(MpegTSContext *ts)
>  
>  clear_programs(ts);
>  
> +for (i = 0; i < FF_ARRAY_ELEMS(ts->pools); i++)
> +av_buffer_pool_uninit(>pools[i]);
> +
>  for (i = 0; i < NB_PID_MAX; i++)
>  if (ts->pids[i])
>  mpegts_close_filter(ts, ts->pids[i]);

LGTM. I assume the pools for the smaller sizes will not end up being
slower than just allocating new buffers each time.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

[FFmpeg-devel] [PATCH] avformat/mpegts: use buffer pools for allocating packets

2020-04-04 Thread Marton Balint
This brings a performance improvement when demuxing files, most of the
improvement comes from buffer pooling unbound packets.

time ffprobe -i 
samples/ffmpeg-bugs/trac/ticket6132/Samsung_HDR_-_Chasing_the_Light.ts 
-show_packets >/dev/null 2>&1

Before:
real0m1.967s
user0m1.471s
sys 0m0.493s

After:
real0m1.497s
user0m1.364s
sys 0m0.129s

Based on a patch of James Almer.

Signed-off-by: Marton Balint 
---
 libavformat/mpegts.c | 23 +++
 1 file changed, 19 insertions(+), 4 deletions(-)

diff --git a/libavformat/mpegts.c b/libavformat/mpegts.c
index 7f56bacb2c..fbafc1d257 100644
--- a/libavformat/mpegts.c
+++ b/libavformat/mpegts.c
@@ -170,6 +170,7 @@ struct MpegTSContext {
 int current_pid;
 
 AVStream *epg_stream;
+AVBufferPool* pools[32];
 };
 
 #define MPEGTS_OPTIONS \
@@ -1103,6 +1104,18 @@ static int read_sl_header(PESContext *pes, SLConfigDescr 
*sl,
 return (get_bits_count() + 7) >> 3;
 }
 
+static AVBufferRef *buffer_pool_get(MpegTSContext *ts, int size)
+{
+int index = av_log2(size + AV_INPUT_BUFFER_PADDING_SIZE);
+if (!ts->pools[index]) {
+int pool_size = FFMIN(MAX_PES_PAYLOAD + AV_INPUT_BUFFER_PADDING_SIZE, 
2 << index);
+ts->pools[index] = av_buffer_pool_init(pool_size, NULL);
+if (!ts->pools[index])
+return NULL;
+}
+return av_buffer_pool_get(ts->pools[index]);
+}
+
 /* return non zero if a packet could be constructed */
 static int mpegts_push_data(MpegTSFilter *filter,
 const uint8_t *buf, int buf_size, int is_start,
@@ -1177,8 +1190,8 @@ static int mpegts_push_data(MpegTSFilter *filter,
 pes->total_size = MAX_PES_PAYLOAD;
 
 /* allocate pes buffer */
-pes->buffer = av_buffer_alloc(pes->total_size +
-  
AV_INPUT_BUFFER_PADDING_SIZE);
+pes->buffer = buffer_pool_get(ts, pes->total_size);
+
 if (!pes->buffer)
 return AVERROR(ENOMEM);
 
@@ -1351,8 +1364,7 @@ skip:
 if (ret < 0)
 return ret;
 pes->total_size = MAX_PES_PAYLOAD;
-pes->buffer = av_buffer_alloc(pes->total_size +
-  
AV_INPUT_BUFFER_PADDING_SIZE);
+pes->buffer = buffer_pool_get(ts, pes->total_size);
 if (!pes->buffer)
 return AVERROR(ENOMEM);
 ts->stop_parse = 1;
@@ -3200,6 +3212,9 @@ static void mpegts_free(MpegTSContext *ts)
 
 clear_programs(ts);
 
+for (i = 0; i < FF_ARRAY_ELEMS(ts->pools); i++)
+av_buffer_pool_uninit(>pools[i]);
+
 for (i = 0; i < NB_PID_MAX; i++)
 if (ts->pids[i])
 mpegts_close_filter(ts, ts->pids[i]);
-- 
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".

Re: [FFmpeg-devel] [PATCH 1/4] avformat/avidec: Don't reimplement ff_free_stream()

2020-04-04 Thread Andreas Rheinhardt
James Almer:
> On 3/27/2020 6:55 AM, Andreas Rheinhardt wrote:
>> Using ff_free_stream() makes the code more readable, more future-proof
>> (the old code freed AVCodecContexts and AVCodecParameters and its
>> substructures manually, so that there is a chance that there would be a
>> memleak for some time if new substructures were added) and reduces
>> code size.
>>
>> Signed-off-by: Andreas Rheinhardt 
>> ---
>>  libavformat/avidec.c | 17 ++---
>>  1 file changed, 2 insertions(+), 15 deletions(-)
>>
>> diff --git a/libavformat/avidec.c b/libavformat/avidec.c
>> index 00c3978b2d..ae343e732a 100644
>> --- a/libavformat/avidec.c
>> +++ b/libavformat/avidec.c
>> @@ -600,21 +600,8 @@ static int avi_read_header(AVFormatContext *s)
>>  goto fail;
>>  
>>  ast = s->streams[0]->priv_data;
>> -av_freep(>streams[0]->codecpar->extradata);
>> -av_freep(>streams[0]->codecpar);
>> -#if FF_API_LAVF_AVCTX
>> -FF_DISABLE_DEPRECATION_WARNINGS
>> -av_freep(>streams[0]->codec);
>> -FF_ENABLE_DEPRECATION_WARNINGS
>> -#endif
>> -if (s->streams[0]->info)
>> -av_freep(>streams[0]->info->duration_error);
>> -av_freep(>streams[0]->info);
>> -if (s->streams[0]->internal)
>> -av_freep(>streams[0]->internal->avctx);
>> -av_freep(>streams[0]->internal);
>> -av_freep(>streams[0]);
>> -s->nb_streams = 0;
>> +st->priv_data = NULL;
>> +ff_free_stream(s, st);
> 
> I stream_index guaranteed to be 0 here? Or in turn, was s->streams[0]
> correct in this chunk to begin with?
> 

Yes. See lines 592-595:

/* After some consideration -- I don't think we
 * have to support anything but DV in type1 AVIs. */
if (s->nb_streams != 1)
goto fail;

(I basically don't know DV, so I don't know how much additional work it
would be to extend this. I also don't know if simply freeing the last
stream (as ff_free_stream() does automatically) would mean that the
above check could be removed. All I know is that the
avpriv_dv_init_demux() will add a new stream to s.)

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

Re: [FFmpeg-devel] [PATCH 1/4] avformat/avidec: Don't reimplement ff_free_stream()

2020-04-04 Thread James Almer
On 3/27/2020 6:55 AM, Andreas Rheinhardt wrote:
> Using ff_free_stream() makes the code more readable, more future-proof
> (the old code freed AVCodecContexts and AVCodecParameters and its
> substructures manually, so that there is a chance that there would be a
> memleak for some time if new substructures were added) and reduces
> code size.
> 
> Signed-off-by: Andreas Rheinhardt 
> ---
>  libavformat/avidec.c | 17 ++---
>  1 file changed, 2 insertions(+), 15 deletions(-)
> 
> diff --git a/libavformat/avidec.c b/libavformat/avidec.c
> index 00c3978b2d..ae343e732a 100644
> --- a/libavformat/avidec.c
> +++ b/libavformat/avidec.c
> @@ -600,21 +600,8 @@ static int avi_read_header(AVFormatContext *s)
>  goto fail;
>  
>  ast = s->streams[0]->priv_data;
> -av_freep(>streams[0]->codecpar->extradata);
> -av_freep(>streams[0]->codecpar);
> -#if FF_API_LAVF_AVCTX
> -FF_DISABLE_DEPRECATION_WARNINGS
> -av_freep(>streams[0]->codec);
> -FF_ENABLE_DEPRECATION_WARNINGS
> -#endif
> -if (s->streams[0]->info)
> -av_freep(>streams[0]->info->duration_error);
> -av_freep(>streams[0]->info);
> -if (s->streams[0]->internal)
> -av_freep(>streams[0]->internal->avctx);
> -av_freep(>streams[0]->internal);
> -av_freep(>streams[0]);
> -s->nb_streams = 0;
> +st->priv_data = NULL;
> +ff_free_stream(s, st);

I stream_index guaranteed to be 0 here? Or in turn, was s->streams[0]
correct in this chunk to begin with?

>  if (CONFIG_DV_DEMUXER) {
>  avi->dv_demux = avpriv_dv_init_demux(s);
>  if (!avi->dv_demux)
> 

___
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] lavd/avfoundation.m: Remove transport controls for iOS.

2020-04-04 Thread Thilo Borgmann
$Subject

-Thilo
From 20f16ed1ef9f99b847798a28fff46812246a8039 Mon Sep 17 00:00:00 2001
From: Thilo Borgmann 
Date: Sat, 4 Apr 2020 13:49:46 +0200
Subject: [PATCH 1/2] lavd/avfoundation.m: Remove transport controls for iOS.

---
 libavdevice/avfoundation.m | 12 ++--
 1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/libavdevice/avfoundation.m b/libavdevice/avfoundation.m
index 43b2edb44d..9f8186b4d7 100644
--- a/libavdevice/avfoundation.m
+++ b/libavdevice/avfoundation.m
@@ -168,6 +168,7 @@ - (id)initWithContext:(AVFContext*)context
 _context = context;
 
 // start observing if a device is set for it
+#if !TARGET_OS_IPHONE && __MAC_OS_X_VERSION_MIN_REQUIRED >= 1070
 if (_context->observed_device) {
 NSString *keyPath = 
NSStringFromSelector(@selector(transportControlsPlaybackMode));
 NSKeyValueObservingOptions options = NSKeyValueObservingOptionNew;
@@ -177,14 +178,19 @@ - (id)initWithContext:(AVFContext*)context
options: options
context: _context];
 }
+#endif
 }
 return self;
 }
 
 - (void)dealloc {
 // stop observing if a device is set for it
-NSString *keyPath = 
NSStringFromSelector(@selector(transportControlsPlaybackMode));
-[_context->observed_device removeObserver: self forKeyPath: keyPath];
+#if !TARGET_OS_IPHONE && __MAC_OS_X_VERSION_MIN_REQUIRED >= 1070
+if (_context->observed_device) {
+NSString *keyPath = 
NSStringFromSelector(@selector(transportControlsPlaybackMode));
+[_context->observed_device removeObserver: self forKeyPath: keyPath];
+}
+#endif
 [super dealloc];
 }
 
@@ -537,6 +543,7 @@ static int add_video_device(AVFormatContext *s, 
AVCaptureDevice *video_device)
 }
 [ctx->video_output setAlwaysDiscardsLateVideoFrames:ctx->drop_late_frames];
 
+#if !TARGET_OS_IPHONE && __MAC_OS_X_VERSION_MIN_REQUIRED >= 1070
 // check for transport control support and set observer device if supported
 int trans_ctrl = [video_device transportControlsSupported];
 AVCaptureDeviceTransportControlsPlaybackMode trans_mode = [video_device 
transportControlsPlaybackMode];
@@ -545,6 +552,7 @@ static int add_video_device(AVFormatContext *s, 
AVCaptureDevice *video_device)
 ctx->observed_mode   = trans_mode;
 ctx->observed_device = video_device;
 }
+#endif
 
 ctx->avf_delegate = [[AVFFrameReceiver alloc] initWithContext:ctx];
 
-- 
2.20.1 (Apple Git-117)

___
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] lavd/avfoundation.m: Do not use transport controls for screen capture devices.

2020-04-04 Thread Thilo Borgmann
$Subject

-Thilo
From a754bd117b6eff1e7c9468a76e236d3f062eb580 Mon Sep 17 00:00:00 2001
From: Thilo Borgmann 
Date: Sat, 4 Apr 2020 13:51:17 +0200
Subject: [PATCH 2/2] lavd/avfoundation.m: Do not use transport controls for
 screen capture devices.

---
 libavdevice/avfoundation.m | 20 +++-
 1 file changed, 11 insertions(+), 9 deletions(-)

diff --git a/libavdevice/avfoundation.m b/libavdevice/avfoundation.m
index 9f8186b4d7..0b1888693f 100644
--- a/libavdevice/avfoundation.m
+++ b/libavdevice/avfoundation.m
@@ -99,6 +99,7 @@
 int capture_raw_data;
 int drop_late_frames;
 int video_is_muxed;
+int video_is_screen;
 
 int list_devices;
 int video_device_index;
@@ -545,12 +546,14 @@ static int add_video_device(AVFormatContext *s, 
AVCaptureDevice *video_device)
 
 #if !TARGET_OS_IPHONE && __MAC_OS_X_VERSION_MIN_REQUIRED >= 1070
 // check for transport control support and set observer device if supported
-int trans_ctrl = [video_device transportControlsSupported];
-AVCaptureDeviceTransportControlsPlaybackMode trans_mode = [video_device 
transportControlsPlaybackMode];
+if (!ctx->video_is_screen) {
+int trans_ctrl = [video_device transportControlsSupported];
+AVCaptureDeviceTransportControlsPlaybackMode trans_mode = 
[video_device transportControlsPlaybackMode];
 
-if (trans_ctrl) {
-ctx->observed_mode   = trans_mode;
-ctx->observed_device = video_device;
+if (trans_ctrl) {
+ctx->observed_mode   = trans_mode;
+ctx->observed_device = video_device;
+}
 }
 #endif
 
@@ -750,7 +753,6 @@ static int get_audio_config(AVFormatContext *s)
 static int avf_read_header(AVFormatContext *s)
 {
 NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];
-int capture_screen  = 0;
 uint32_t num_screens= 0;
 AVFContext *ctx = (AVFContext*)s->priv_data;
 AVCaptureDevice *video_device = nil;
@@ -847,7 +849,7 @@ static int avf_read_header(AVFormatContext *s)
 }
 
 video_device = (AVCaptureDevice*) capture_screen_input;
-capture_screen = 1;
+ctx->video_is_screen = 1;
 #endif
  } else {
 av_log(ctx, AV_LOG_ERROR, "Invalid device index\n");
@@ -884,7 +886,7 @@ static int avf_read_header(AVFormatContext *s)
 AVCaptureScreenInput* capture_screen_input = 
[[[AVCaptureScreenInput alloc] initWithDisplayID:screens[idx]] autorelease];
 video_device = (AVCaptureDevice*) capture_screen_input;
 ctx->video_device_index = ctx->num_video_devices + idx;
-capture_screen = 1;
+ctx->video_is_screen = 1;
 
 if (ctx->framerate.num > 0) {
 capture_screen_input.minFrameDuration = 
CMTimeMake(ctx->framerate.den, ctx->framerate.num);
@@ -975,7 +977,7 @@ static int avf_read_header(AVFormatContext *s)
 
 /* Unlock device configuration only after the session is started so it
  * does not reset the capture formats */
-if (!capture_screen) {
+if (!ctx->video_is_screen) {
 [video_device unlockForConfiguration];
 }
 
-- 
2.20.1 (Apple Git-117)

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

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

[FFmpeg-devel] [PATCH 0/2] lavd/avfoundation: Fix build on iOS and fix screen capture

2020-04-04 Thread Thilo Borgmann
Hi,

fixing two bugs revealed after last patch to avfoundation.

Will apply soon if there are no objections.

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

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

Re: [FFmpeg-devel] [PATCH v1] avformat/mux: Set AV_PKT_FLAG_KEY for is_intra_only packet

2020-04-04 Thread Limin Wang
On Sat, Apr 04, 2020 at 11:42:06AM +0200, Nicolas George wrote:
> Limin Wang (12020-04-04):
> > I think it's caused by the keyframe flags, so have no clue how to check
> > the beneficial for these fate testing.
> 
> Take the actual files produced by the tests, possibly changing the
> output format from framecrc to an actual format, and compare carefully
> the version before the patch and the version after the patch.

the md5 framecrc is generated by libavformat/tests/movenc.c, I have no
clue how the movenc testing work and how to get the real input to check why
the frame isn't bitexact as I haven't see any subtitle track. 

> 
> Tests are there for a reason. If you cannot explain exactly why a change
> in a reference file is beneficial, then the patch is not acceptable.

> 
> Regards,
> 
> -- 
>   Nicolas George



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


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

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

Re: [FFmpeg-devel] [PATCH 2/2] lavc/libaomenc: Support lossless encoding

2020-04-04 Thread Ryo Hirafuji
> So "crf 0" already has a meaning different from all other crf values?

No. "crf 0" has the same meanings. It just makes the quality better than
"crf 1".

I read libaom again, and I apologize for my wrong explanation:
  I found that if certain conditions are met, "crf 0" also generates
lossless videos.

If these conditions are not met, "-crf 0" will be lossless:

<>
  "-bit_rate 0" (which means, enccfg.rc_end_usage = AOM_Q)
  "-aq-mode none"
  "-enable_restoration 0"

<>
  AV1E_SET_ENABLE_CHROMA_DELTAQ must be 0
  AV1E_SET_ENABLE_SUPERRES must be 0

Thus, at least, "-lossless" does have a different meaning from "-crf 0",
so I think it would be useful to add "-lossless" flags.


2020年4月4日(土) 19:29 Carl Eugen Hoyos :

> Am Sa., 4. Apr. 2020 um 12:16 Uhr schrieb Ryo Hirafuji
> :
> >
> > > Is it possible to use "cfr 0" instead?
> >
> > Unfortunately, crf=0 is not lossless.
> > "lossless" flag uses "quantisation matrices", which is different from the
> > default quantizer determined by "-crf", to achieve lossless encoding.
>
> So "crf 0" already has a meaning different from all other crf values?
>
> 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".
___
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 5/5] x86 inline assembly compliance

2020-04-04 Thread FRÉDÉRIC RECOULES
[inline assembly] add "memory" to sub_median_pred_mmxext 

--- 
libavcodec/x86/lossless_videoencdsp_init.c | 2 +- 
1 file changed, 1 insertion(+), 1 deletion(-) 

diff --git a/libavcodec/x86/lossless_videoencdsp_init.c 
b/libavcodec/x86/lossless_videoencdsp_init.c 
index fb481e66f5..feb6874f94 100644 
--- a/libavcodec/x86/lossless_videoencdsp_init.c 
+++ b/libavcodec/x86/lossless_videoencdsp_init.c 
@@ -71,7 +71,7 @@ static void sub_median_pred_mmxext(uint8_t *dst, const 
uint8_t *src1, 
" jb 1b \n\t" 
: "+r" (i) 
: "r" (src1), "r" (src2), "r" (dst), "r" ((x86_reg) w) 
- : MMX_CLOBBERS("mm0", "mm1", "mm2", "mm3", "mm4", "mm5") 
+ : MMX_CLOBBERS("mm0", "mm1", "mm2", "mm3", "mm4", "mm5",) "memory" 
); 

l = *left; 
-- 
2.17.1 
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

[FFmpeg-devel] [PATCH 4/5] x86 inline assembly compliance

2020-04-04 Thread FRÉDÉRIC RECOULES
[inline assembly] add mmx clobbers in 3 statements 

- 1 in lossless_videoencdsp_init.c 
- 2 in rnd_template.c 
--- 
libavcodec/x86/lossless_videoencdsp_init.c | 4 +++- 
libavcodec/x86/rnd_template.c | 8 ++-- 
2 files changed, 9 insertions(+), 3 deletions(-) 

diff --git a/libavcodec/x86/lossless_videoencdsp_init.c 
b/libavcodec/x86/lossless_videoencdsp_init.c 
index 40407add52..fb481e66f5 100644 
--- a/libavcodec/x86/lossless_videoencdsp_init.c 
+++ b/libavcodec/x86/lossless_videoencdsp_init.c 
@@ -70,7 +70,9 @@ static void sub_median_pred_mmxext(uint8_t *dst, const 
uint8_t *src1, 
"cmp %4, %0 \n\t" 
" jb 1b \n\t" 
: "+r" (i) 
- : "r" (src1), "r" (src2), "r" (dst), "r" ((x86_reg) w)); 
+ : "r" (src1), "r" (src2), "r" (dst), "r" ((x86_reg) w) 
+ : MMX_CLOBBERS("mm0", "mm1", "mm2", "mm3", "mm4", "mm5") 
+ ); 

l = *left; 
lt = *left_top; 
diff --git a/libavcodec/x86/rnd_template.c b/libavcodec/x86/rnd_template.c 
index a98fbc10ab..013aa1a645 100644 
--- a/libavcodec/x86/rnd_template.c 
+++ b/libavcodec/x86/rnd_template.c 
@@ -94,7 +94,9 @@ av_unused STATIC void DEF(put, pixels8_xy2)(uint8_t *block, 
const uint8_t *pixel 
"jnz 1b \n\t" 
:"+g"(h), "+S"(pixels) 
:"D"(block), "r"((x86_reg)line_size) COMMA_SET_RND_IN 
- :FF_REG_a, "memory"); 
+ :FF_REG_a, "memory" 
+ MMX_CLOBBERS(, "mm0", "mm1", "mm2", "mm3", "mm4", "mm5", "mm6", "mm7") 
+ ); 
} 

// avg_pixels 
@@ -171,5 +173,7 @@ av_unused STATIC void DEF(avg, pixels8_xy2)(uint8_t *block, 
const uint8_t *pixel 
"jnz 1b \n\t" 
:"+g"(h), "+S"(pixels) 
:"D"(block), "r"((x86_reg)line_size) COMMA_SET_RND_IN 
- :FF_REG_a, "memory"); 
+ :FF_REG_a, "memory" 
+ MMX_CLOBBERS(, "mm0", "mm1", "mm2", "mm3", "mm4", "mm5", "mm6", "mm7") 
+ ); 
} 
-- 
2.17.1 


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

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

[FFmpeg-devel] [PATCH 3/5] x86 inline assembly compliance

2020-04-04 Thread FRÉDÉRIC RECOULES
[inline assembly] prepares for mmx clobbers akin to xmm 

--- 
configure | 4  
libavutil/x86/asm.h | 20  
2 files changed, 24 insertions(+) 

diff --git a/configure b/configure 
index 5fe9950e20..4062ca095a 100755 
--- a/configure 
+++ b/configure 
@@ -2275,6 +2275,7 @@ TOOLCHAIN_FEATURES=" 
symver_gnu_asm 
vfp_args 
xform_asm 
+ mmx_clobbers 
xmm_clobbers 
" 

@@ -5907,6 +5908,9 @@ EOF 
check_inline_asm ebx_available '""::"b"(0)' && 
check_inline_asm ebx_available '"":::"%ebx"' 

+ # check whether mmx clobbers are supported 
+ check_inline_asm mmx_clobbers '"":::"%mm0"' 
+ 
# check whether xmm clobbers are supported 
check_inline_asm xmm_clobbers '"":::"%xmm0"' 

diff --git a/libavutil/x86/asm.h b/libavutil/x86/asm.h 
index 9bff42d628..bb3c13f5c1 100644 
--- a/libavutil/x86/asm.h 
+++ b/libavutil/x86/asm.h 
@@ -79,6 +79,26 @@ typedef int x86_reg; 
# define BROKEN_RELOCATIONS 1 
#endif 

+/* 
+ * If gcc is not set to support mmx (-mmmx) it will not accept mmx registers 
+ * in the clobber list for inline asm. MMX_CLOBBERS takes a list of mmx 
+ * registers to be marked as clobbered and evaluates to nothing if they are 
+ * not supported, or to the list itself if they are supported. Since a clobber 
+ * list may not be empty, XMM_CLOBBERS_ONLY should be used if the mmx 
+ * registers are the only in the clobber list. 
+ * For example a list with "eax" and "mm0" as clobbers should become: 
+ * : MMX_CLOBBERS("mm0",) "eax" 
+ * and a list with only "mm0" should become: 
+ * MMX_CLOBBERS_ONLY("mm0") 
+ */ 
+#if HAVE_MMX_CLOBBERS 
+# define MMX_CLOBBERS(...) __VA_ARGS__ 
+# define MMX_CLOBBERS_ONLY(...) : __VA_ARGS__ 
+#else 
+# define MMX_CLOBBERS(...) 
+# define MMX_CLOBBERS_ONLY(...) 
+#endif 
+ 
/* 
* If gcc is not set to support sse (-msse) it will not accept xmm registers 
* in the clobber list for inline asm. XMM_CLOBBERS takes a list of xmm 
-- 
2.17.1 


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

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

Re: [FFmpeg-devel] [PATCH] ffplay: flush correct stream after stats update

2020-04-04 Thread Gyan Doshi



On 04-04-2020 03:30 pm, Marton Balint wrote:



On Fri, 3 Apr 2020, Gyan Doshi wrote:


Stats and logs are written to stderr, not stdout.
---
fftools/ffplay.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fftools/ffplay.c b/fftools/ffplay.c
index 416ebbf7df..1beec54293 100644
--- a/fftools/ffplay.c
+++ b/fftools/ffplay.c
@@ -1736,7 +1736,7 @@ display:
    else
    av_log(NULL, AV_LOG_INFO, "%s", buf.str);

-    fflush(stdout);
+    fflush(stderr);


LGTM, thanks.


Thanks. Pushed as b195b5f2ba3527172ff6ac28d018a6ba23262af9

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

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

[FFmpeg-devel] [PATCH 2/5] x86 inline assembly compliance

2020-04-04 Thread FRÉDÉRIC RECOULES
[inline assembly] merges contiguous assembly statements 

--- 
libavcodec/x86/hpeldsp_init.c | 8  
libavcodec/x86/rnd_template.c | 14 +++--- 
2 files changed, 15 insertions(+), 7 deletions(-) 

diff --git a/libavcodec/x86/hpeldsp_init.c b/libavcodec/x86/hpeldsp_init.c 
index d89928cec6..c99513035b 100644 
--- a/libavcodec/x86/hpeldsp_init.c 
+++ b/libavcodec/x86/hpeldsp_init.c 
@@ -95,6 +95,8 @@ void ff_avg_approx_pixels8_xy2_3dnow(uint8_t *block, const 
uint8_t *pixels, 
/* MMX no rounding */ 
#define DEF(x, y) x ## _no_rnd_ ## y ## _mmx 
#define SET_RND MOVQ_WONE 
+#define SET_RND_TPL MOVQ_WONE_TPL 
+#define COMMA_SET_RND_IN 
#define PAVGBP(a, b, c, d, e, f) PAVGBP_MMX_NO_RND(a, b, c, d, e, f) 
#define PAVGB(a, b, c, e) PAVGB_MMX_NO_RND(a, b, c, e) 
#define STATIC static 
@@ -104,6 +106,8 @@ void ff_avg_approx_pixels8_xy2_3dnow(uint8_t *block, const 
uint8_t *pixels, 

#undef DEF 
#undef SET_RND 
+#undef SET_RND_TPL 
+#undef COMMA_SET_RND_IN 
#undef PAVGBP 
#undef PAVGB 
#undef STATIC 
@@ -121,6 +125,8 @@ CALL_2X_PIXELS(put_no_rnd_pixels16_xy2_mmx, 
put_no_rnd_pixels8_xy2_mmx, 8) 

#define DEF(x, y) x ## _ ## y ## _mmx 
#define SET_RND MOVQ_WTWO 
+#define SET_RND_TPL MOVQ_WTWO_TPL 
+#define COMMA_SET_RND_IN COMMA_MOVQ_WTWO_IN 
#define PAVGBP(a, b, c, d, e, f) PAVGBP_MMX(a, b, c, d, e, f) 
#define PAVGB(a, b, c, e) PAVGB_MMX(a, b, c, e) 

@@ -134,6 +140,8 @@ CALL_2X_PIXELS(put_no_rnd_pixels16_xy2_mmx, 
put_no_rnd_pixels8_xy2_mmx, 8) 

#undef DEF 
#undef SET_RND 
+#undef SET_RND_TPL 
+#undef COMMA_SET_RND_IN 
#undef PAVGBP 
#undef PAVGB 

diff --git a/libavcodec/x86/rnd_template.c b/libavcodec/x86/rnd_template.c 
index 09946bd23f..a98fbc10ab 100644 
--- a/libavcodec/x86/rnd_template.c 
+++ b/libavcodec/x86/rnd_template.c 
@@ -33,9 +33,9 @@ 
av_unused STATIC void DEF(put, pixels8_xy2)(uint8_t *block, const uint8_t 
*pixels, 
ptrdiff_t line_size, int h) 
{ 
- MOVQ_ZERO(mm7); 
- SET_RND(mm6); // =2 for rnd and =1 for no_rnd version 
__asm__ volatile( 
+ MOVQ_ZERO_TPL(mm7) 
+ SET_RND_TPL(mm6) // =2 for rnd and =1 for no_rnd version 
"movq (%1), %%mm0 \n\t" 
"movq 1(%1), %%mm4 \n\t" 
"movq %%mm0, %%mm1 \n\t" 
@@ -93,7 +93,7 @@ av_unused STATIC void DEF(put, pixels8_xy2)(uint8_t *block, 
const uint8_t *pixel 
"subl $2, %0 \n\t" 
"jnz 1b \n\t" 
:"+g"(h), "+S"(pixels) 
- :"D"(block), "r"((x86_reg)line_size) 
+ :"D"(block), "r"((x86_reg)line_size) COMMA_SET_RND_IN 
:FF_REG_a, "memory"); 
} 

@@ -102,10 +102,10 @@ av_unused STATIC void DEF(put, pixels8_xy2)(uint8_t 
*block, const uint8_t *pixel 
av_unused STATIC void DEF(avg, pixels8_xy2)(uint8_t *block, const uint8_t 
*pixels, 
ptrdiff_t line_size, int h) 
{ 
- MOVQ_ZERO(mm7); 
- SET_RND(mm6); // =2 for rnd and =1 for no_rnd version 
__asm__ volatile( 
- "movq (%1), %%mm0 \n\t" 
+ MOVQ_ZERO_TPL(mm7) 
+ SET_RND_TPL(mm6) // =2 for rnd and =1 for no_rnd version 
+ "movq (%1), %%mm0 \n\t" 
"movq 1(%1), %%mm4 \n\t" 
"movq %%mm0, %%mm1 \n\t" 
"movq %%mm4, %%mm5 \n\t" 
@@ -170,6 +170,6 @@ av_unused STATIC void DEF(avg, pixels8_xy2)(uint8_t *block, 
const uint8_t *pixel 
"subl $2, %0 \n\t" 
"jnz 1b \n\t" 
:"+g"(h), "+S"(pixels) 
- :"D"(block), "r"((x86_reg)line_size) 
+ :"D"(block), "r"((x86_reg)line_size) COMMA_SET_RND_IN 
:FF_REG_a, "memory"); 
} 
-- 
2.17.1 


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

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

[FFmpeg-devel] [PATCH 1/5] x86 inline assembly compliance

2020-04-04 Thread FRÉDÉRIC RECOULES
[inline assembly] prepares for contiguous assembly statements merging 

--- 
libavcodec/x86/inline_asm.h | 29 + 
1 file changed, 17 insertions(+), 12 deletions(-) 

diff --git a/libavcodec/x86/inline_asm.h b/libavcodec/x86/inline_asm.h 
index 0198746719..6ead73ac33 100644 
--- a/libavcodec/x86/inline_asm.h 
+++ b/libavcodec/x86/inline_asm.h 
@@ -23,13 +23,15 @@ 

#include "constants.h" 

-#define MOVQ_WONE(regd) \ 
- __asm__ volatile ( \ 
- "pcmpeqd %%" #regd ", %%" #regd " \n\t" \ 
- "psrlw $15, %%" #regd ::) 
+#define MOVQ_WONE_TPL(regd) \ 
+ "pcmpeqd %%"#regd", %%"#regd" \n\t" \ 
+ "psrlw $15, %%" #regd" \n\t" 
+#define MOVQ_WONE(regd) __asm__ volatile (MOVQ_WONE_TPL(regd) ::) 

#define JUMPALIGN() __asm__ volatile (".p2align 3"::) 
-#define MOVQ_ZERO(regd) __asm__ volatile ("pxor %%"#regd", %%"#regd ::) 
+ 
+#define MOVQ_ZERO_TPL(regd) "pxor %%"#regd", %%"#regd" \n\t" 
+#define MOVQ_ZERO(regd) __asm__ volatile (MOVQ_ZERO_TPL(regd) ::) 

#define MOVQ_BFE(regd) \ 
__asm__ volatile ( \ 
@@ -37,17 +39,20 @@ 
"paddb %%"#regd", %%"#regd" \n\t" ::) 

#ifndef PIC 
-#define MOVQ_WTWO(regd) __asm__ volatile ("movq %0, %%"#regd" \n\t" :: 
"m"(ff_pw_2)) 
+#define MOVQ_WTWO_TPL(regd) "movq %[ff_pw_2], %%"#regd" \n\t" 
+#define MOVQ_WTWO_IN [ff_pw_2] "m" (ff_pw_2) 
+#define COMMA_MOVQ_WTWO_IN , MOVQ_WTWO_IN 
#else 
// for shared library it's better to use this way for accessing constants 
// pcmpeqd -> -1 
-#define MOVQ_WTWO(regd) \ 
- __asm__ volatile ( \ 
- "pcmpeqd %%"#regd", %%"#regd" \n\t" \ 
- "psrlw $15, %%"#regd" \n\t" \ 
- "psllw $1, %%"#regd" \n\t"::) 
- 
+#define MOVQ_WTWO_TPL(regd) \ 
+ "pcmpeqd %%"#regd", %%"#regd" \n\t" \ 
+ "psrlw $15, %%"#regd" \n\t" \ 
+ "psllw $1, %%"#regd" \n\t" 
+#define MOVQ_WTWO_IN 
+#define COMMA_MOVQ_WTWO_IN 
#endif 
+#define MOVQ_WTWO(regd) __asm__ volatile (MOVQ_WTWO_TPL(regd) :: MOVQ_WTWO_IN) 

// using regr as temporary and for the output result 
// first argument is unmodified and second is trashed 
-- 
2.17.1 


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

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

Re: [FFmpeg-devel] [PATCH 2/2] lavc/libaomenc: Support lossless encoding

2020-04-04 Thread Carl Eugen Hoyos
Am Sa., 4. Apr. 2020 um 12:16 Uhr schrieb Ryo Hirafuji
:
>
> > Is it possible to use "cfr 0" instead?
>
> Unfortunately, crf=0 is not lossless.
> "lossless" flag uses "quantisation matrices", which is different from the
> default quantizer determined by "-crf", to achieve lossless encoding.

So "crf 0" already has a meaning different from all other crf values?

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] [inline assembly compliance] Issues and patches

2020-04-04 Thread FRÉDÉRIC RECOULES
Thank you for your answers. 

As you have pointed out, these patches are full of unrelated changes that are 
not important for safety. 
Most of them were never intended to be posted here, the diff we submitted was 
the one of an 
experimental branch and we apologize to have made such a mistake. 
We will resubmit the patch with only essential patches in a more appropriate 
format very soon 
(git format-patch). 

@Michael These errors come with the Clang compiler, aren't they? 
We are aware that support for inline assembly may differ from one compiler to 
another 
despite the "higly-compatibility" that is stated. The safety patches we are 
proposing 
do not rely on them. 

@Carl @Kieran So far, we passed the FATE tests. 
The output is slightly different because we have merged contiguous assembly 
statement 
such that the compiler can no longer insert instruction between them, but the 
differences 
are only instruction swaps A.B.C -> B.A.C. 

Frédéric Recoules 


De: "Michael Niedermayer"  
À: "ffmpeg-devel"  
Envoyé: Samedi 4 Avril 2020 00:39:13 
Objet: Re: [FFmpeg-devel] [inline assembly compliance] Issues and patches 

On Fri, Apr 03, 2020 at 10:41:58PM +0200, FRÉDÉRIC RECOULES wrote: 
> Dear developpers, 
> 
> 
> 
> we are academic researchers working in automated program analysis. 
> We are currently interested in checking compliance of inline asm chunks 
> as found in C programs. 
> 
> While benchmarking our tool and technique, we found a number of issues in 
> FFMPEG. We report them to you, as well as adequate patches. 
> Actually, we found 59 significant compliance issues in your code. 
> We join 3 patches for some of them, together with explanations and 
> we can send you other patches on demand. 
> 
> 
> * All these bugs are related to compliance between the block of asm and its 
> surrounding "contract" (in gcc-style notation). They are akin to undefined or 
> implementation-defined behaviours in C: they currently do not manifest 
> themselves in your program, but at some point in time with compiler 
> optimizations becoming more and more aggressive or changes in undocumented 
> compiler choices regarding asm chunks, they can suddenly trigger a 
> (hard-to-find) bug. 
> 
> * The typical problems come from the compiler missing dataflow information 
> and performing undue optimizations on this wrong basis, or the compiler 
> allocating an already used register. Actually, we demonstrate "in lab" 
> problems 
> with all these categories of bugs in case of inlining 
> (especially with LTO enabler) or code refactoring. 
> 
> * Some of those issues may seems benign or irrealistic but it cost nothing 
> to patch so, why not do it? 
> 
> 
> We would be very interested to hear your opinion on these matters. 
> Are you interested in such errors and patches? 
> Also, besides the patches, we are currently working on a code analyzer 
> prototype designed to check asm compliance and to propose patches when the 
> chunk is not compliant. This is still work in progress and we are finalizing 
> it. 
> The errors and patches I reported to you came from my prototype. 
> In case such a prototype would be made available, would you consider using 
> it? 
> 
> 
> 
> Best regards 
> 
> Frédéric Recoules 

This breaks build with shared libs 

In file included from src/libavcodec/x86/hpeldsp_init.c:104: 
src/libavcodec/x86/rnd_template.c:102:30: error: dereference of pointer to 
incomplete type 'const uint8_t []' 
"m" (*(const uint8_t (*)[])pixels), 
^ 
src/libavcodec/x86/rnd_template.c:188:30: error: dereference of pointer to 
incomplete type 'const uint8_t []' 
"m" (*(const uint8_t (*)[])pixels), 
^ 
In file included from src/libavcodec/x86/hpeldsp_init.c:139: 
src/libavcodec/x86/rnd_template.c:102:30: error: dereference of pointer to 
incomplete type 'const uint8_t []' 
"m" (*(const uint8_t (*)[])pixels), 
^ 
src/libavcodec/x86/rnd_template.c:188:30: error: dereference of pointer to 
incomplete type 'const uint8_t []' 
"m" (*(const uint8_t (*)[])pixels), 
^ 
4 errors generated. 
src/ffbuild/common.mak:59: recipe for target 'libavcodec/x86/hpeldsp_init.o' 
failed 
make: *** [libavcodec/x86/hpeldsp_init.o] Error 1 



[...] 
> diff --git a/libavcodec/x86/rnd_template.c b/libavcodec/x86/rnd_template.c 
> index 09946bd23f..1be010e066 100644 
> --- a/libavcodec/x86/rnd_template.c 
> +++ b/libavcodec/x86/rnd_template.c 
> @@ -30,146 +30,164 @@ 
> #include "inline_asm.h" 
> 
> // put_pixels 
> -av_unused STATIC void DEF(put, pixels8_xy2)(uint8_t *block, const uint8_t 
> *pixels, 
> - ptrdiff_t line_size, int h) 
> +av_unused STATIC void DEF(put, pixels8_xy2)(uint8_t *block, 
> + const uint8_t *pixels, 
> + ptrdiff_t line_size, int h) 

unrelated whitespace change 


> { 
> - MOVQ_ZERO(mm7); 
> - SET_RND(mm6); // =2 for rnd and =1 for no_rnd version 
> - __asm__ volatile( 
> - "movq (%1), %%mm0 \n\t" 
> - "movq 1(%1), %%mm4 \n\t" 
> - "movq %%mm0, %%mm1 \n\t" 
> - "movq %%mm4, %%mm5 \n\t" 
> - "punpcklbw %%mm7, %%mm0 \n\t" 
> - 

Re: [FFmpeg-devel] [PATCH 2/2] lavc/libaomenc: Support lossless encoding

2020-04-04 Thread Ryo Hirafuji
> Is it possible to use "cfr 0" instead?

Unfortunately, crf=0 is not lossless.
"lossless" flag uses "quantisation matrices", which is different from the
default quantizer determined by "-crf", to achieve lossless encoding.


2020年4月4日(土) 18:59 Carl Eugen Hoyos :

> Am Sa., 4. Apr. 2020 um 11:57 Uhr schrieb Ryo Hirafuji <
> ryo.hiraf...@gmail.com>:
> >
> > From: Ryo Hirafuji 
> >
> > AV1 support lossless encoding.
> > In this patch, I added a command line flag to enable it.
> >
> > ---
> >  libavcodec/libaomenc.c | 12 +++-
> >  1 file changed, 11 insertions(+), 1 deletion(-)
> >
> > diff --git a/libavcodec/libaomenc.c b/libavcodec/libaomenc.c
> > index fb61ce82e2..4a7f4b662a 100644
> > --- a/libavcodec/libaomenc.c
> > +++ b/libavcodec/libaomenc.c
> > @@ -94,6 +94,7 @@ typedef struct AOMEncoderContext {
> >  int enable_intrabc;
> >  int enable_restoration;
> >  int usage;
> > +int lossless;
> >  } AOMContext;
> >
> >  static const char *const ctlidstr[] = {
> > @@ -130,6 +131,9 @@ static const char *const ctlidstr[] = {
> >  #endif
> >  #ifdef AOM_CTRL_AV1E_SET_ENABLE_INTRABC
> >  [AV1E_SET_ENABLE_INTRABC]   = "AV1E_SET_ENABLE_INTRABC",
> > +#endif
> > +#ifdef AOM_CTRL_AV1E_SET_LOSSLESS
> > +[AV1E_SET_LOSSLESS]   = "AOM_CTRL_AV1E_SET_LOSSLESS",
> >  #endif
> >  [AV1E_SET_ENABLE_CDEF]  = "AV1E_SET_ENABLE_CDEF",
> >  };
> > @@ -154,7 +158,7 @@ static av_cold void dump_enc_cfg(AVCodecContext
> *avctx,
> >  av_log(avctx, level, "aom_codec_enc_cfg\n");
> >  av_log(avctx, level, "generic settings\n"
> >   "  %*s%u\n  %*s%u\n  %*s%u\n  %*s%u\n  %*s%u\n"
> > - "  %*s%u\n  %*s%u\n"
> > + "  %*s%u\n  %*s%u\n  %*s%u\n"
> >   "  %*s{%u/%u}\n  %*s%u\n  %*s%d\n  %*s%u\n",
> > width, "g_usage:",   cfg->g_usage,
> > width, "g_threads:", cfg->g_threads,
> > @@ -163,6 +167,7 @@ static av_cold void dump_enc_cfg(AVCodecContext
> *avctx,
> > width, "g_h:",   cfg->g_h,
> > width, "g_bit_depth:",   cfg->g_bit_depth,
> > width, "g_input_bit_depth:", cfg->g_input_bit_depth,
> > +   width, "monochrome:",cfg->monochrome,
> > width, "g_timebase:",cfg->g_timebase.num,
> cfg->g_timebase.den,
> > width, "g_error_resilient:", cfg->g_error_resilient,
> > width, "g_pass:",cfg->g_pass,
> > @@ -751,6 +756,10 @@ static av_cold int aom_init(AVCodecContext *avctx,
> >  codecctl_int(avctx, AV1E_SET_MAX_REFERENCE_FRAMES, avctx->refs);
> >  }
> >  #endif
> > +#ifdef AOM_CTRL_AV1E_SET_LOSSLESS
> > +if (ctx->lossless >= 0)
> > +codecctl_int(avctx, AV1E_SET_LOSSLESS, ctx->lossless);
> > +#endif
> >  #ifdef AOM_CTRL_AV1E_SET_ROW_MT
> >  if (ctx->row_mt >= 0)
> >  codecctl_int(avctx, AV1E_SET_ROW_MT, ctx->row_mt);
> > @@ -1132,6 +1141,7 @@ static const AVOption options[] = {
> >  { "usage",   "Quality and compression efficiency vs speed
> tradeof", OFFSET(usage), AV_OPT_TYPE_INT, {.i64 = 0}, 0, INT_MAX, VE,
> "usage"},
> >  { "good","Good quality",  0, AV_OPT_TYPE_CONST,
> {.i64 = 0 /* AOM_USAGE_GOOD_QUALITY */}, 0, 0, VE, "usage"},
> >  { "realtime","Realtime encoding", 0, AV_OPT_TYPE_CONST,
> {.i64 = 1 /* AOM_USAGE_REALTIME */}, 0, 0, VE, "usage"},
>
> > +{ "lossless","Lossless encoding", OFFSET(lossless),
> AV_OPT_TYPE_BOOL, {.i64 = -1}, -1, 1, VE},
>
> Is it possible to use "cfr 0" instead?
>
> Carl Eugen
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

[FFmpeg-devel] [PATCH 2/2] lavc/libaomenc: Support lossless encoding

2020-04-04 Thread Ryo Hirafuji
From: Ryo Hirafuji 

AV1 support lossless encoding.
In this patch, I added a command line flag to enable it.

---
 libavcodec/libaomenc.c | 12 +++-
 1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/libavcodec/libaomenc.c b/libavcodec/libaomenc.c
index fb61ce82e2..4a7f4b662a 100644
--- a/libavcodec/libaomenc.c
+++ b/libavcodec/libaomenc.c
@@ -94,6 +94,7 @@ typedef struct AOMEncoderContext {
 int enable_intrabc;
 int enable_restoration;
 int usage;
+int lossless;
 } AOMContext;
 
 static const char *const ctlidstr[] = {
@@ -130,6 +131,9 @@ static const char *const ctlidstr[] = {
 #endif
 #ifdef AOM_CTRL_AV1E_SET_ENABLE_INTRABC
 [AV1E_SET_ENABLE_INTRABC]   = "AV1E_SET_ENABLE_INTRABC",
+#endif
+#ifdef AOM_CTRL_AV1E_SET_LOSSLESS
+[AV1E_SET_LOSSLESS]   = "AOM_CTRL_AV1E_SET_LOSSLESS",
 #endif
 [AV1E_SET_ENABLE_CDEF]  = "AV1E_SET_ENABLE_CDEF",
 };
@@ -154,7 +158,7 @@ static av_cold void dump_enc_cfg(AVCodecContext *avctx,
 av_log(avctx, level, "aom_codec_enc_cfg\n");
 av_log(avctx, level, "generic settings\n"
  "  %*s%u\n  %*s%u\n  %*s%u\n  %*s%u\n  %*s%u\n"
- "  %*s%u\n  %*s%u\n"
+ "  %*s%u\n  %*s%u\n  %*s%u\n"
  "  %*s{%u/%u}\n  %*s%u\n  %*s%d\n  %*s%u\n",
width, "g_usage:",   cfg->g_usage,
width, "g_threads:", cfg->g_threads,
@@ -163,6 +167,7 @@ static av_cold void dump_enc_cfg(AVCodecContext *avctx,
width, "g_h:",   cfg->g_h,
width, "g_bit_depth:",   cfg->g_bit_depth,
width, "g_input_bit_depth:", cfg->g_input_bit_depth,
+   width, "monochrome:",cfg->monochrome,
width, "g_timebase:",cfg->g_timebase.num, 
cfg->g_timebase.den,
width, "g_error_resilient:", cfg->g_error_resilient,
width, "g_pass:",cfg->g_pass,
@@ -751,6 +756,10 @@ static av_cold int aom_init(AVCodecContext *avctx,
 codecctl_int(avctx, AV1E_SET_MAX_REFERENCE_FRAMES, avctx->refs);
 }
 #endif
+#ifdef AOM_CTRL_AV1E_SET_LOSSLESS
+if (ctx->lossless >= 0)
+codecctl_int(avctx, AV1E_SET_LOSSLESS, ctx->lossless);
+#endif
 #ifdef AOM_CTRL_AV1E_SET_ROW_MT
 if (ctx->row_mt >= 0)
 codecctl_int(avctx, AV1E_SET_ROW_MT, ctx->row_mt);
@@ -1132,6 +1141,7 @@ static const AVOption options[] = {
 { "usage",   "Quality and compression efficiency vs speed 
tradeof", OFFSET(usage), AV_OPT_TYPE_INT, {.i64 = 0}, 0, INT_MAX, VE, "usage"},
 { "good","Good quality",  0, AV_OPT_TYPE_CONST, {.i64 = 0 
/* AOM_USAGE_GOOD_QUALITY */}, 0, 0, VE, "usage"},
 { "realtime","Realtime encoding", 0, AV_OPT_TYPE_CONST, {.i64 = 1 
/* AOM_USAGE_REALTIME */}, 0, 0, VE, "usage"},
+{ "lossless","Lossless encoding", OFFSET(lossless), 
AV_OPT_TYPE_BOOL, {.i64 = -1}, -1, 1, VE},
 { NULL },
 };
 
-- 
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] ffplay: flush correct stream after stats update

2020-04-04 Thread Marton Balint



On Fri, 3 Apr 2020, Gyan Doshi wrote:


Stats and logs are written to stderr, not stdout.
---
fftools/ffplay.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fftools/ffplay.c b/fftools/ffplay.c
index 416ebbf7df..1beec54293 100644
--- a/fftools/ffplay.c
+++ b/fftools/ffplay.c
@@ -1736,7 +1736,7 @@ display:
else
av_log(NULL, AV_LOG_INFO, "%s", buf.str);

-fflush(stdout);
+fflush(stderr);


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

[FFmpeg-devel] [PATCH 2/2] libavcodec/libaomenc.c: Support lossless encoding

2020-04-04 Thread Ryo Hirafuji
AV1 support lossless encoding.
In this patch, I added a command line flag to enable it.

---
 libavcodec/libaomenc.c | 12 +++-
 1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/libavcodec/libaomenc.c b/libavcodec/libaomenc.c
index fb61ce82e2..4a7f4b662a 100644
--- a/libavcodec/libaomenc.c
+++ b/libavcodec/libaomenc.c
@@ -94,6 +94,7 @@ typedef struct AOMEncoderContext {
 int enable_intrabc;
 int enable_restoration;
 int usage;
+int lossless;
 } AOMContext;
 
 static const char *const ctlidstr[] = {
@@ -130,6 +131,9 @@ static const char *const ctlidstr[] = {
 #endif
 #ifdef AOM_CTRL_AV1E_SET_ENABLE_INTRABC
 [AV1E_SET_ENABLE_INTRABC]   = "AV1E_SET_ENABLE_INTRABC",
+#endif
+#ifdef AOM_CTRL_AV1E_SET_LOSSLESS
+[AV1E_SET_LOSSLESS]   = "AOM_CTRL_AV1E_SET_LOSSLESS",
 #endif
 [AV1E_SET_ENABLE_CDEF]  = "AV1E_SET_ENABLE_CDEF",
 };
@@ -154,7 +158,7 @@ static av_cold void dump_enc_cfg(AVCodecContext *avctx,
 av_log(avctx, level, "aom_codec_enc_cfg\n");
 av_log(avctx, level, "generic settings\n"
  "  %*s%u\n  %*s%u\n  %*s%u\n  %*s%u\n  %*s%u\n"
- "  %*s%u\n  %*s%u\n"
+ "  %*s%u\n  %*s%u\n  %*s%u\n"
  "  %*s{%u/%u}\n  %*s%u\n  %*s%d\n  %*s%u\n",
width, "g_usage:",   cfg->g_usage,
width, "g_threads:", cfg->g_threads,
@@ -163,6 +167,7 @@ static av_cold void dump_enc_cfg(AVCodecContext *avctx,
width, "g_h:",   cfg->g_h,
width, "g_bit_depth:",   cfg->g_bit_depth,
width, "g_input_bit_depth:", cfg->g_input_bit_depth,
+   width, "monochrome:",cfg->monochrome,
width, "g_timebase:",cfg->g_timebase.num, 
cfg->g_timebase.den,
width, "g_error_resilient:", cfg->g_error_resilient,
width, "g_pass:",cfg->g_pass,
@@ -751,6 +756,10 @@ static av_cold int aom_init(AVCodecContext *avctx,
 codecctl_int(avctx, AV1E_SET_MAX_REFERENCE_FRAMES, avctx->refs);
 }
 #endif
+#ifdef AOM_CTRL_AV1E_SET_LOSSLESS
+if (ctx->lossless >= 0)
+codecctl_int(avctx, AV1E_SET_LOSSLESS, ctx->lossless);
+#endif
 #ifdef AOM_CTRL_AV1E_SET_ROW_MT
 if (ctx->row_mt >= 0)
 codecctl_int(avctx, AV1E_SET_ROW_MT, ctx->row_mt);
@@ -1132,6 +1141,7 @@ static const AVOption options[] = {
 { "usage",   "Quality and compression efficiency vs speed 
tradeof", OFFSET(usage), AV_OPT_TYPE_INT, {.i64 = 0}, 0, INT_MAX, VE, "usage"},
 { "good","Good quality",  0, AV_OPT_TYPE_CONST, {.i64 = 0 
/* AOM_USAGE_GOOD_QUALITY */}, 0, 0, VE, "usage"},
 { "realtime","Realtime encoding", 0, AV_OPT_TYPE_CONST, {.i64 = 1 
/* AOM_USAGE_REALTIME */}, 0, 0, VE, "usage"},
+{ "lossless","Lossless encoding", OFFSET(lossless), 
AV_OPT_TYPE_BOOL, {.i64 = -1}, -1, 1, VE},
 { NULL },
 };
 
-- 
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 2/2] lavc/libaomenc: Support lossless encoding

2020-04-04 Thread Carl Eugen Hoyos
Am Sa., 4. Apr. 2020 um 11:57 Uhr schrieb Ryo Hirafuji :
>
> From: Ryo Hirafuji 
>
> AV1 support lossless encoding.
> In this patch, I added a command line flag to enable it.
>
> ---
>  libavcodec/libaomenc.c | 12 +++-
>  1 file changed, 11 insertions(+), 1 deletion(-)
>
> diff --git a/libavcodec/libaomenc.c b/libavcodec/libaomenc.c
> index fb61ce82e2..4a7f4b662a 100644
> --- a/libavcodec/libaomenc.c
> +++ b/libavcodec/libaomenc.c
> @@ -94,6 +94,7 @@ typedef struct AOMEncoderContext {
>  int enable_intrabc;
>  int enable_restoration;
>  int usage;
> +int lossless;
>  } AOMContext;
>
>  static const char *const ctlidstr[] = {
> @@ -130,6 +131,9 @@ static const char *const ctlidstr[] = {
>  #endif
>  #ifdef AOM_CTRL_AV1E_SET_ENABLE_INTRABC
>  [AV1E_SET_ENABLE_INTRABC]   = "AV1E_SET_ENABLE_INTRABC",
> +#endif
> +#ifdef AOM_CTRL_AV1E_SET_LOSSLESS
> +[AV1E_SET_LOSSLESS]   = "AOM_CTRL_AV1E_SET_LOSSLESS",
>  #endif
>  [AV1E_SET_ENABLE_CDEF]  = "AV1E_SET_ENABLE_CDEF",
>  };
> @@ -154,7 +158,7 @@ static av_cold void dump_enc_cfg(AVCodecContext *avctx,
>  av_log(avctx, level, "aom_codec_enc_cfg\n");
>  av_log(avctx, level, "generic settings\n"
>   "  %*s%u\n  %*s%u\n  %*s%u\n  %*s%u\n  %*s%u\n"
> - "  %*s%u\n  %*s%u\n"
> + "  %*s%u\n  %*s%u\n  %*s%u\n"
>   "  %*s{%u/%u}\n  %*s%u\n  %*s%d\n  %*s%u\n",
> width, "g_usage:",   cfg->g_usage,
> width, "g_threads:", cfg->g_threads,
> @@ -163,6 +167,7 @@ static av_cold void dump_enc_cfg(AVCodecContext *avctx,
> width, "g_h:",   cfg->g_h,
> width, "g_bit_depth:",   cfg->g_bit_depth,
> width, "g_input_bit_depth:", cfg->g_input_bit_depth,
> +   width, "monochrome:",cfg->monochrome,
> width, "g_timebase:",cfg->g_timebase.num, 
> cfg->g_timebase.den,
> width, "g_error_resilient:", cfg->g_error_resilient,
> width, "g_pass:",cfg->g_pass,
> @@ -751,6 +756,10 @@ static av_cold int aom_init(AVCodecContext *avctx,
>  codecctl_int(avctx, AV1E_SET_MAX_REFERENCE_FRAMES, avctx->refs);
>  }
>  #endif
> +#ifdef AOM_CTRL_AV1E_SET_LOSSLESS
> +if (ctx->lossless >= 0)
> +codecctl_int(avctx, AV1E_SET_LOSSLESS, ctx->lossless);
> +#endif
>  #ifdef AOM_CTRL_AV1E_SET_ROW_MT
>  if (ctx->row_mt >= 0)
>  codecctl_int(avctx, AV1E_SET_ROW_MT, ctx->row_mt);
> @@ -1132,6 +1141,7 @@ static const AVOption options[] = {
>  { "usage",   "Quality and compression efficiency vs speed 
> tradeof", OFFSET(usage), AV_OPT_TYPE_INT, {.i64 = 0}, 0, INT_MAX, VE, 
> "usage"},
>  { "good","Good quality",  0, AV_OPT_TYPE_CONST, {.i64 = 
> 0 /* AOM_USAGE_GOOD_QUALITY */}, 0, 0, VE, "usage"},
>  { "realtime","Realtime encoding", 0, AV_OPT_TYPE_CONST, {.i64 = 
> 1 /* AOM_USAGE_REALTIME */}, 0, 0, VE, "usage"},

> +{ "lossless","Lossless encoding", OFFSET(lossless), 
> AV_OPT_TYPE_BOOL, {.i64 = -1}, -1, 1, VE},

Is it possible to use "cfr 0" instead?

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 2/2] lavc/libaomenc: Support lossless encoding

2020-04-04 Thread Ryo Hirafuji
From: Ryo Hirafuji 

AV1 support lossless encoding.
In this patch, I added a command line flag to enable it.

---
 libavcodec/libaomenc.c | 12 +++-
 1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/libavcodec/libaomenc.c b/libavcodec/libaomenc.c
index fb61ce82e2..4a7f4b662a 100644
--- a/libavcodec/libaomenc.c
+++ b/libavcodec/libaomenc.c
@@ -94,6 +94,7 @@ typedef struct AOMEncoderContext {
 int enable_intrabc;
 int enable_restoration;
 int usage;
+int lossless;
 } AOMContext;
 
 static const char *const ctlidstr[] = {
@@ -130,6 +131,9 @@ static const char *const ctlidstr[] = {
 #endif
 #ifdef AOM_CTRL_AV1E_SET_ENABLE_INTRABC
 [AV1E_SET_ENABLE_INTRABC]   = "AV1E_SET_ENABLE_INTRABC",
+#endif
+#ifdef AOM_CTRL_AV1E_SET_LOSSLESS
+[AV1E_SET_LOSSLESS]   = "AOM_CTRL_AV1E_SET_LOSSLESS",
 #endif
 [AV1E_SET_ENABLE_CDEF]  = "AV1E_SET_ENABLE_CDEF",
 };
@@ -154,7 +158,7 @@ static av_cold void dump_enc_cfg(AVCodecContext *avctx,
 av_log(avctx, level, "aom_codec_enc_cfg\n");
 av_log(avctx, level, "generic settings\n"
  "  %*s%u\n  %*s%u\n  %*s%u\n  %*s%u\n  %*s%u\n"
- "  %*s%u\n  %*s%u\n"
+ "  %*s%u\n  %*s%u\n  %*s%u\n"
  "  %*s{%u/%u}\n  %*s%u\n  %*s%d\n  %*s%u\n",
width, "g_usage:",   cfg->g_usage,
width, "g_threads:", cfg->g_threads,
@@ -163,6 +167,7 @@ static av_cold void dump_enc_cfg(AVCodecContext *avctx,
width, "g_h:",   cfg->g_h,
width, "g_bit_depth:",   cfg->g_bit_depth,
width, "g_input_bit_depth:", cfg->g_input_bit_depth,
+   width, "monochrome:",cfg->monochrome,
width, "g_timebase:",cfg->g_timebase.num, 
cfg->g_timebase.den,
width, "g_error_resilient:", cfg->g_error_resilient,
width, "g_pass:",cfg->g_pass,
@@ -751,6 +756,10 @@ static av_cold int aom_init(AVCodecContext *avctx,
 codecctl_int(avctx, AV1E_SET_MAX_REFERENCE_FRAMES, avctx->refs);
 }
 #endif
+#ifdef AOM_CTRL_AV1E_SET_LOSSLESS
+if (ctx->lossless >= 0)
+codecctl_int(avctx, AV1E_SET_LOSSLESS, ctx->lossless);
+#endif
 #ifdef AOM_CTRL_AV1E_SET_ROW_MT
 if (ctx->row_mt >= 0)
 codecctl_int(avctx, AV1E_SET_ROW_MT, ctx->row_mt);
@@ -1132,6 +1141,7 @@ static const AVOption options[] = {
 { "usage",   "Quality and compression efficiency vs speed 
tradeof", OFFSET(usage), AV_OPT_TYPE_INT, {.i64 = 0}, 0, INT_MAX, VE, "usage"},
 { "good","Good quality",  0, AV_OPT_TYPE_CONST, {.i64 = 0 
/* AOM_USAGE_GOOD_QUALITY */}, 0, 0, VE, "usage"},
 { "realtime","Realtime encoding", 0, AV_OPT_TYPE_CONST, {.i64 = 1 
/* AOM_USAGE_REALTIME */}, 0, 0, VE, "usage"},
+{ "lossless","Lossless encoding", OFFSET(lossless), 
AV_OPT_TYPE_BOOL, {.i64 = -1}, -1, 1, VE},
 { NULL },
 };
 
-- 
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 1/2] libavcodec/libaomenc.c: Support gray input

2020-04-04 Thread Ryo Hirafuji
AV1 decoders, libaomdec and libdav1d, both support grayscale image.
However, libaomenc does not support it yet.
In this patch, I add a grayscale image support also to libaomenc.

---
 libavcodec/libaomenc.c | 48 --
 1 file changed, 42 insertions(+), 6 deletions(-)

diff --git a/libavcodec/libaomenc.c b/libavcodec/libaomenc.c
index 096aadbe1c..fb61ce82e2 100644
--- a/libavcodec/libaomenc.c
+++ b/libavcodec/libaomenc.c
@@ -276,6 +276,25 @@ static int set_pix_fmt(AVCodecContext *avctx, 
aom_codec_caps_t codec_caps,
 AOMContext av_unused *ctx = avctx->priv_data;
 enccfg->g_bit_depth = enccfg->g_input_bit_depth = 8;
 switch (avctx->pix_fmt) {
+case AV_PIX_FMT_GRAY8:
+enccfg->monochrome = 1u;
+enccfg->g_profile = FF_PROFILE_AV1_MAIN;
+*img_fmt = AOM_IMG_FMT_I420;
+return 0;
+case AV_PIX_FMT_GRAY10:
+case AV_PIX_FMT_GRAY12:
+if (codec_caps & AOM_CODEC_CAP_HIGHBITDEPTH) {
+enccfg->monochrome = 1u;
+enccfg->g_profile = 
+avctx->pix_fmt == AV_PIX_FMT_GRAY10 ? FF_PROFILE_AV1_MAIN
+: 
FF_PROFILE_AV1_PROFESSIONAL;
+enccfg->g_bit_depth = enccfg->g_input_bit_depth =
+avctx->pix_fmt == AV_PIX_FMT_GRAY10 ? 10 : 12;
+*img_fmt = AOM_IMG_FMT_I420;
+*flags |= AOM_CODEC_USE_HIGHBITDEPTH;
+return 0;
+}
+break;
 case AV_PIX_FMT_YUV420P:
 enccfg->g_profile = FF_PROFILE_AV1_MAIN;
 *img_fmt = AOM_IMG_FMT_I420;
@@ -979,12 +998,25 @@ static int aom_encode(AVCodecContext *avctx, AVPacket 
*pkt,
 
 if (frame) {
 rawimg  = >rawimg;
-rawimg->planes[AOM_PLANE_Y] = frame->data[0];
-rawimg->planes[AOM_PLANE_U] = frame->data[1];
-rawimg->planes[AOM_PLANE_V] = frame->data[2];
-rawimg->stride[AOM_PLANE_Y] = frame->linesize[0];
-rawimg->stride[AOM_PLANE_U] = frame->linesize[1];
-rawimg->stride[AOM_PLANE_V] = frame->linesize[2];
+if (frame->format == AV_PIX_FMT_GRAY8 ||
+frame->format == AV_PIX_FMT_GRAY10 ||
+frame->format == AV_PIX_FMT_GRAY12) {
+rawimg->monochrome = 1;
+rawimg->planes[AOM_PLANE_Y] = frame->data[0];
+rawimg->planes[AOM_PLANE_U] = frame->data[0];
+rawimg->planes[AOM_PLANE_V] = frame->data[0];
+rawimg->stride[AOM_PLANE_Y] = frame->linesize[0];
+rawimg->stride[AOM_PLANE_U] = frame->linesize[0];
+rawimg->stride[AOM_PLANE_V] = frame->linesize[0];
+} else {
+rawimg->monochrome = 0;
+rawimg->planes[AOM_PLANE_Y] = frame->data[0];
+rawimg->planes[AOM_PLANE_U] = frame->data[1];
+rawimg->planes[AOM_PLANE_V] = frame->data[2];
+rawimg->stride[AOM_PLANE_Y] = frame->linesize[0];
+rawimg->stride[AOM_PLANE_U] = frame->linesize[1];
+rawimg->stride[AOM_PLANE_V] = frame->linesize[2];
+}
 timestamp   = frame->pts;
 switch (frame->color_range) {
 case AVCOL_RANGE_MPEG:
@@ -1025,6 +1057,7 @@ static int aom_encode(AVCodecContext *avctx, AVPacket 
*pkt,
 }
 
 static const enum AVPixelFormat av1_pix_fmts[] = {
+AV_PIX_FMT_GRAY8,
 AV_PIX_FMT_YUV420P,
 AV_PIX_FMT_YUV422P,
 AV_PIX_FMT_YUV444P,
@@ -1032,6 +1065,9 @@ static const enum AVPixelFormat av1_pix_fmts[] = {
 };
 
 static const enum AVPixelFormat av1_pix_fmts_highbd[] = {
+AV_PIX_FMT_GRAY8,
+AV_PIX_FMT_GRAY10,
+AV_PIX_FMT_GRAY12,
 AV_PIX_FMT_YUV420P,
 AV_PIX_FMT_YUV422P,
 AV_PIX_FMT_YUV444P,
-- 
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] ffplay: always show stats at all log levels if requested by user

2020-04-04 Thread Gyan Doshi



On 04-04-2020 02:49 pm, Marton Balint wrote:



On Fri, 3 Apr 2020, Gyan Doshi wrote:


Since 3b491c5a500, stats would be hidden if loglevel was lower than
info, even if -stats was set.

Fixes #6962
---
doc/ffplay.texi  |  5 +++--
fftools/ffplay.c | 36 
2 files changed, 27 insertions(+), 14 deletions(-)

diff --git a/doc/ffplay.texi b/doc/ffplay.texi
index a487c0de8d..f3761bb12e 100644
--- a/doc/ffplay.texi
+++ b/doc/ffplay.texi
@@ -133,8 +133,9 @@ This option has been deprecated in favor of 
private options, try -pixel_format.

@item -stats
Print several playback statistics, in particular show the stream
duration, the codec parameters, the current position in the stream and
-the audio/video synchronisation drift. It is on by default, to
-explicitly disable it you need to specify @code{-nostats}.
+the audio/video synchronisation drift. It is shown by default, 
unless the
+log level is lower than @code{info}. Its display can be forced by 
manually
+specifying this option. To disable it, you need to specify 
@code{-nostats}.


@item -fast
Non-spec-compliant optimizations.
diff --git a/fftools/ffplay.c b/fftools/ffplay.c
index 2ed4b22d3e..416ebbf7df 100644
--- a/fftools/ffplay.c
+++ b/fftools/ffplay.c
@@ -40,6 +40,7 @@
#include "libavutil/samplefmt.h"
#include "libavutil/avassert.h"
#include "libavutil/time.h"
+#include "libavutil/bprint.h"
#include "libavformat/avformat.h"
#include "libavdevice/avdevice.h"
#include "libswscale/swscale.h"
@@ -326,7 +327,7 @@ static int display_disable;
static int borderless;
static int alwaysontop;
static int startup_volume = 100;
-static int show_status = 1;
+static int show_status = -1;
static int av_sync_type = AV_SYNC_AUDIO_MASTER;
static int64_t start_time = AV_NOPTS_VALUE;
static int64_t duration = AV_NOPTS_VALUE;
@@ -1692,6 +1693,7 @@ display:
    }
    is->force_refresh = 0;
    if (show_status) {
+    AVBPrint buf;
    static int64_t last_time;
    int64_t cur_time;
    int aqsize, vqsize, sqsize;
@@ -1715,18 +1717,28 @@ display:
    av_diff = get_master_clock(is) - get_clock(>vidclk);
    else if (is->audio_st)
    av_diff = get_master_clock(is) - get_clock(>audclk);
-    av_log(NULL, AV_LOG_INFO,
-   "%7.2f %s:%7.3f fd=%4d aq=%5dKB vq=%5dKB sq=%5dB 
f=%"PRId64"/%"PRId64"   \r",

-   get_master_clock(is),
-   (is->audio_st && is->video_st) ? "A-V" : 
(is->video_st ? "M-V" : (is->audio_st ? "M-A" : "   ")),

-   av_diff,
-   is->frame_drops_early + is->frame_drops_late,
-   aqsize / 1024,
-   vqsize / 1024,
-   sqsize,
-   is->video_st ? 
is->viddec.avctx->pts_correction_num_faulty_dts : 0,
-   is->video_st ? 
is->viddec.avctx->pts_correction_num_faulty_pts : 0);

+
+    av_bprint_init(, 0, AV_BPRINT_SIZE_AUTOMATIC);
+    av_bprintf(,
+  "%7.2f %s:%7.3f fd=%4d aq=%5dKB vq=%5dKB 
sq=%5dB f=%"PRId64"/%"PRId64"   \r",

+  get_master_clock(is),
+  (is->audio_st && is->video_st) ? "A-V" : 
(is->video_st ? "M-V" : (is->audio_st ? "M-A" : "   ")),

+  av_diff,
+  is->frame_drops_early + is->frame_drops_late,
+  aqsize / 1024,
+  vqsize / 1024,
+  sqsize,
+  is->video_st ? 
is->viddec.avctx->pts_correction_num_faulty_dts : 0,
+  is->video_st ? 
is->viddec.avctx->pts_correction_num_faulty_pts : 0);

+
+    if (show_status == 1 && AV_LOG_INFO > av_log_get_level())
+    fprintf(stderr, "%s", buf.str);
+    else
+    av_log(NULL, AV_LOG_INFO, "%s", buf.str);
+
    fflush(stdout);
+    av_bprint_finalize(, NULL);
+
    last_time = cur_time;
    }
    }


LGTM, thanks.


Thanks. Pushed as 2d6a89872ea2e20a3464be825d683d6f91d67c62

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 v1] avformat/mux: Set AV_PKT_FLAG_KEY for is_intra_only packet

2020-04-04 Thread Nicolas George
Limin Wang (12020-04-04):
> I think it's caused by the keyframe flags, so have no clue how to check
> the beneficial for these fate testing.

Take the actual files produced by the tests, possibly changing the
output format from framecrc to an actual format, and compare carefully
the version before the patch and the version after the patch.

Tests are there for a reason. If you cannot explain exactly why a change
in a reference file is beneficial, then the patch is not acceptable.

Regards,

-- 
  Nicolas George


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

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

Re: [FFmpeg-devel] [PATCH v2] ffplay: always show stats at all log levels if requested by user

2020-04-04 Thread Marton Balint



On Fri, 3 Apr 2020, Gyan Doshi wrote:


Since 3b491c5a500, stats would be hidden if loglevel was lower than
info, even if -stats was set.

Fixes #6962
---
doc/ffplay.texi  |  5 +++--
fftools/ffplay.c | 36 
2 files changed, 27 insertions(+), 14 deletions(-)

diff --git a/doc/ffplay.texi b/doc/ffplay.texi
index a487c0de8d..f3761bb12e 100644
--- a/doc/ffplay.texi
+++ b/doc/ffplay.texi
@@ -133,8 +133,9 @@ This option has been deprecated in favor of private 
options, try -pixel_format.
@item -stats
Print several playback statistics, in particular show the stream
duration, the codec parameters, the current position in the stream and
-the audio/video synchronisation drift. It is on by default, to
-explicitly disable it you need to specify @code{-nostats}.
+the audio/video synchronisation drift. It is shown by default, unless the
+log level is lower than @code{info}. Its display can be forced by manually
+specifying this option. To disable it, you need to specify @code{-nostats}.

@item -fast
Non-spec-compliant optimizations.
diff --git a/fftools/ffplay.c b/fftools/ffplay.c
index 2ed4b22d3e..416ebbf7df 100644
--- a/fftools/ffplay.c
+++ b/fftools/ffplay.c
@@ -40,6 +40,7 @@
#include "libavutil/samplefmt.h"
#include "libavutil/avassert.h"
#include "libavutil/time.h"
+#include "libavutil/bprint.h"
#include "libavformat/avformat.h"
#include "libavdevice/avdevice.h"
#include "libswscale/swscale.h"
@@ -326,7 +327,7 @@ static int display_disable;
static int borderless;
static int alwaysontop;
static int startup_volume = 100;
-static int show_status = 1;
+static int show_status = -1;
static int av_sync_type = AV_SYNC_AUDIO_MASTER;
static int64_t start_time = AV_NOPTS_VALUE;
static int64_t duration = AV_NOPTS_VALUE;
@@ -1692,6 +1693,7 @@ display:
}
is->force_refresh = 0;
if (show_status) {
+AVBPrint buf;
static int64_t last_time;
int64_t cur_time;
int aqsize, vqsize, sqsize;
@@ -1715,18 +1717,28 @@ display:
av_diff = get_master_clock(is) - get_clock(>vidclk);
else if (is->audio_st)
av_diff = get_master_clock(is) - get_clock(>audclk);
-av_log(NULL, AV_LOG_INFO,
-   "%7.2f %s:%7.3f fd=%4d aq=%5dKB vq=%5dKB sq=%5dB 
f=%"PRId64"/%"PRId64"   \r",
-   get_master_clock(is),
-   (is->audio_st && is->video_st) ? "A-V" : (is->video_st ? "M-V" : (is->audio_st 
? "M-A" : "   ")),
-   av_diff,
-   is->frame_drops_early + is->frame_drops_late,
-   aqsize / 1024,
-   vqsize / 1024,
-   sqsize,
-   is->video_st ? 
is->viddec.avctx->pts_correction_num_faulty_dts : 0,
-   is->video_st ? 
is->viddec.avctx->pts_correction_num_faulty_pts : 0);
+
+av_bprint_init(, 0, AV_BPRINT_SIZE_AUTOMATIC);
+av_bprintf(,
+  "%7.2f %s:%7.3f fd=%4d aq=%5dKB vq=%5dKB sq=%5dB 
f=%"PRId64"/%"PRId64"   \r",
+  get_master_clock(is),
+  (is->audio_st && is->video_st) ? "A-V" : (is->video_st ? "M-V" : 
(is->audio_st ? "M-A" : "   ")),
+  av_diff,
+  is->frame_drops_early + is->frame_drops_late,
+  aqsize / 1024,
+  vqsize / 1024,
+  sqsize,
+  is->video_st ? 
is->viddec.avctx->pts_correction_num_faulty_dts : 0,
+  is->video_st ? 
is->viddec.avctx->pts_correction_num_faulty_pts : 0);
+
+if (show_status == 1 && AV_LOG_INFO > av_log_get_level())
+fprintf(stderr, "%s", buf.str);
+else
+av_log(NULL, AV_LOG_INFO, "%s", buf.str);
+
fflush(stdout);
+av_bprint_finalize(, NULL);
+
last_time = cur_time;
}
}


LGTM, 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 v1] avformat/mux: Set AV_PKT_FLAG_KEY for is_intra_only packet

2020-04-04 Thread Andreas Rheinhardt
Limin Wang:
> On Fri, Apr 03, 2020 at 11:23:59PM +0200, Michael Niedermayer wrote:
>> On Fri, Apr 03, 2020 at 11:05:59PM +0800, lance.lmw...@gmail.com wrote:
>>> From: Limin Wang 
>>>
>>> Signed-off-by: Limin Wang 
>>> ---
>>>  libavformat/mux.c| 16 
>>>  tests/ref/fate/binsub-movtextenc |  2 +-
>>>  tests/ref/fate/movenc| 50 +++
>>>  tests/ref/fate/sub2video | 86 
>>> 
>>>  4 files changed, 85 insertions(+), 69 deletions(-)
>>>
>>> diff --git a/libavformat/mux.c b/libavformat/mux.c
>>> index cc2d1e2..dc897c2 100644
>>> --- a/libavformat/mux.c
>>> +++ b/libavformat/mux.c
>>> @@ -548,6 +548,17 @@ fail:
>>>  return ret;
>>>  }
>>>  
>>> +static int is_intra_only(enum AVCodecID id)
>>> +{
>>> +const AVCodecDescriptor *d = avcodec_descriptor_get(id);
>>> +if (!d)
>>> +return 0;
>>> +if ((d->type == AVMEDIA_TYPE_VIDEO || d->type == AVMEDIA_TYPE_AUDIO) &&
>>> +!(d->props & AV_CODEC_PROP_INTRA_ONLY))
>>> +return 0;
>>> +return 1;
>>> +}
>>
>> this should not be duplicated with code in utils.c
> 
> OK
> 
>>
>>
>>> +
>>>  #define AV_PKT_FLAG_UNCODED_FRAME 0x2000
>>>  
>>>  /* Note: using sizeof(AVFrame) from outside lavu is unsafe in general, but
>>> @@ -664,6 +675,11 @@ static int compute_muxer_pkt_fields(AVFormatContext 
>>> *s, AVStream *st, AVPacket *
>>>  frac_add(st->internal->priv_pts, (int64_t)st->time_base.den * 
>>> st->time_base.num);
>>>  break;
>>>  }
>>> +
>>> +/* update flags */
>>> +if (is_intra_only(st->codecpar->codec_id))
>>> +pkt->flags |= AV_PKT_FLAG_KEY;
>>> +
>>
>> it may make sense to store the AVCodecDescriptor and not search it again for
>> each packet. But then the "is_intra_only" itself also does not change so that
>> should itself be computet just once per stream
> 
> Do you say we should add a is_intra_only field in AVStream to compute at 
> beginning,
> however it'll change the API header. So I prefer to use is_intra_only() 
> function first,  

This should be added to AVStreamInternal, not AVStream itself. And of
course this can and should also be used for demuxing.

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

Re: [FFmpeg-devel] [PATCH 1/4] avformat/avidec: Don't reimplement ff_free_stream()

2020-04-04 Thread Andreas Rheinhardt
Andreas Rheinhardt:
> Using ff_free_stream() makes the code more readable, more future-proof
> (the old code freed AVCodecContexts and AVCodecParameters and its
> substructures manually, so that there is a chance that there would be a
> memleak for some time if new substructures were added) and reduces
> code size.
> 
> Signed-off-by: Andreas Rheinhardt 
> ---
>  libavformat/avidec.c | 17 ++---
>  1 file changed, 2 insertions(+), 15 deletions(-)
> 
> diff --git a/libavformat/avidec.c b/libavformat/avidec.c
> index 00c3978b2d..ae343e732a 100644
> --- a/libavformat/avidec.c
> +++ b/libavformat/avidec.c
> @@ -600,21 +600,8 @@ static int avi_read_header(AVFormatContext *s)
>  goto fail;
>  
>  ast = s->streams[0]->priv_data;
> -av_freep(>streams[0]->codecpar->extradata);
> -av_freep(>streams[0]->codecpar);
> -#if FF_API_LAVF_AVCTX
> -FF_DISABLE_DEPRECATION_WARNINGS
> -av_freep(>streams[0]->codec);
> -FF_ENABLE_DEPRECATION_WARNINGS
> -#endif
> -if (s->streams[0]->info)
> -av_freep(>streams[0]->info->duration_error);
> -av_freep(>streams[0]->info);
> -if (s->streams[0]->internal)
> -av_freep(>streams[0]->internal->avctx);
> -av_freep(>streams[0]->internal);
> -av_freep(>streams[0]);
> -s->nb_streams = 0;
> +st->priv_data = NULL;
> +ff_free_stream(s, st);
>  if (CONFIG_DV_DEMUXER) {
>  avi->dv_demux = avpriv_dv_init_demux(s);
>  if (!avi->dv_demux)
> 
Any comments on this patchset? If there are no objections, I'll apply it
tomorrow.

- 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 v11 1/3] libavcodec/jpeg2000dec.c: Add support for PPT marker

2020-04-04 Thread gautamramk
From: Gautam Ramakrishnan 

This patch adds functional changes to support the
PPT marker.
---
 libavcodec/jpeg2000dec.c | 88 +++-
 1 file changed, 77 insertions(+), 11 deletions(-)

diff --git a/libavcodec/jpeg2000dec.c b/libavcodec/jpeg2000dec.c
index 7103cd6ceb..01509d62c1 100644
--- a/libavcodec/jpeg2000dec.c
+++ b/libavcodec/jpeg2000dec.c
@@ -83,6 +83,10 @@ typedef struct Jpeg2000Tile {
 Jpeg2000QuantStyle  qntsty[4];
 Jpeg2000POC poc;
 Jpeg2000TileParttile_part[32];
+uint8_t has_ppt;// whether this tile has a ppt 
marker
+uint8_t *packed_headers;// contains packed headers. 
Used only along with PPT marker
+int packed_headers_size;// size in bytes of the packed 
headers
+GetByteContext  packed_headers_stream;  // byte context corresponding 
to packed headers
 uint16_t tp_idx;// Tile-part index
 int coord[2][2];// border coordinates {{x0, x1}, {y0, 
y1}}
 } Jpeg2000Tile;
@@ -855,6 +859,37 @@ static int get_plt(Jpeg2000DecoderContext *s, int n)
 return 0;
 }
 
+static int get_ppt(Jpeg2000DecoderContext *s, int n)
+{
+Jpeg2000Tile *tile;
+
+if (s->curtileno < 0)
+return AVERROR_INVALIDDATA;
+
+tile = >tile[s->curtileno];
+if (tile->tp_idx != 0) {
+av_log(s->avctx, AV_LOG_ERROR,
+   "PPT marker can occur only on first tile part of a tile.\n");
+return AVERROR_INVALIDDATA;
+}
+
+tile->has_ppt = 1;  // this tile has a ppt marker
+/*Zppt = */ bytestream2_get_byte(>g); // Zppt is skipped and not used
+if (!tile->packed_headers)
+tile->packed_headers = av_malloc(n - 3);
+else
+tile->packed_headers = av_realloc(tile->packed_headers,
+  tile->packed_headers_size + n - 3);
+if (!tile->packed_headers)
+return AVERROR(ENOMEM);
+memcpy(tile->packed_headers + tile->packed_headers_size,
+   s->g.buffer, n - 3);
+tile->packed_headers_size += n - 3;
+bytestream2_skip(>g, n - 3);
+
+return 0;
+}
+
 static int init_tile(Jpeg2000DecoderContext *s, int tileno)
 {
 int compno;
@@ -927,6 +962,19 @@ static int getlblockinc(Jpeg2000DecoderContext *s)
 return res;
 }
 
+static inline void select_stream(Jpeg2000DecoderContext *s, Jpeg2000Tile *tile,
+ int *tp_index)
+{
+s->g = tile->tile_part[*tp_index].tpg;
+if (bytestream2_get_bytes_left(>g) == 0 && s->bit_index == 8) {
+if (*tp_index < FF_ARRAY_ELEMS(tile->tile_part) - 1) {
+s->g = tile->tile_part[++(*tp_index)].tpg;
+}
+}
+if (bytestream2_peek_be32(>g) == JPEG2000_SOP_FIXED_BYTES)
+bytestream2_skip(>g, JPEG2000_SOP_BYTE_LENGTH);
+}
+
 static int jpeg2000_decode_packet(Jpeg2000DecoderContext *s, Jpeg2000Tile 
*tile, int *tp_index,
   Jpeg2000CodingStyle *codsty,
   Jpeg2000ResLevel *rlevel, int precno,
@@ -938,19 +986,15 @@ static int jpeg2000_decode_packet(Jpeg2000DecoderContext 
*s, Jpeg2000Tile *tile,
 if (layno < rlevel->band[0].prec[precno].decoded_layers)
 return 0;
 rlevel->band[0].prec[precno].decoded_layers = layno + 1;
-
-if (bytestream2_get_bytes_left(>g) == 0 && s->bit_index == 8) {
-if (*tp_index < FF_ARRAY_ELEMS(tile->tile_part) - 1) {
-s->g = tile->tile_part[++(*tp_index)].tpg;
-}
-}
-
-if (bytestream2_peek_be32(>g) == JPEG2000_SOP_FIXED_BYTES)
-bytestream2_skip(>g, JPEG2000_SOP_BYTE_LENGTH);
+// Select stream to read from
+if (tile->has_ppt)
+s->g = tile->packed_headers_stream;
+else
+select_stream(s, tile, tp_index);
 
 if (!(ret = get_bits(s, 1))) {
 jpeg2000_flush(s);
-return 0;
+goto skip_data;
 } else if (ret < 0)
 return ret;
 
@@ -1056,6 +1100,11 @@ static int jpeg2000_decode_packet(Jpeg2000DecoderContext 
*s, Jpeg2000Tile *tile,
 av_log(s->avctx, AV_LOG_ERROR, "EPH marker not found. instead 
%X\n", bytestream2_peek_be32(>g));
 }
 
+// Save state of stream
+if (tile->has_ppt) {
+tile->packed_headers_stream = s->g;
+select_stream(s, tile, tp_index);
+}
 for (bandno = 0; bandno < rlevel->nbands; bandno++) {
 Jpeg2000Band *band = rlevel->band + bandno;
 Jpeg2000Prec *prec = band->prec + precno;
@@ -1097,6 +1146,15 @@ static int jpeg2000_decode_packet(Jpeg2000DecoderContext 
*s, Jpeg2000Tile *tile,
 av_freep(>lengthinc);
 }
 }
+// Save state of stream
+tile->tile_part[*tp_index].tpg = s->g;
+return 0;
+
+skip_data:
+if (tile->has_ppt)
+tile->packed_headers_stream = s->g;
+else
+tile->tile_part[*tp_index].tpg = s->g;
 return 0;
 }
 
@@ -1929,6 +1987,11 @@ static int 

[FFmpeg-devel] [PATCH v11 2/3] libavcodec/jpeg2000dec.c: Handle non EOC streams

2020-04-04 Thread gautamramk
From: Gautam Ramakrishnan 

This patch allows decoding of j2k streams which do
not have an EOC marker.
---
 libavcodec/jpeg2000dec.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/libavcodec/jpeg2000dec.c b/libavcodec/jpeg2000dec.c
index 01509d62c1..f2039fa8c1 100644
--- a/libavcodec/jpeg2000dec.c
+++ b/libavcodec/jpeg2000dec.c
@@ -2002,8 +2002,12 @@ static int 
jpeg2000_read_main_headers(Jpeg2000DecoderContext *s)
 
 len = bytestream2_get_be16(>g);
 if (len < 2 || bytestream2_get_bytes_left(>g) < len - 2) {
-av_log(s->avctx, AV_LOG_ERROR, "Invalid len %d left=%d\n", len, 
bytestream2_get_bytes_left(>g));
-return AVERROR_INVALIDDATA;
+if (s->avctx->strict_std_compliance >= FF_COMPLIANCE_STRICT) {
+av_log(s->avctx, AV_LOG_ERROR, "Invalid len %d left=%d\n", 
len, bytestream2_get_bytes_left(>g));
+return AVERROR_INVALIDDATA;
+}
+av_log(s->avctx, AV_LOG_WARNING, "Missing EOC Marker.\n");
+break;
 }
 
 switch (marker) {
-- 
2.17.1

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

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

[FFmpeg-devel] [PATCH v11 3/3] libavcodec/jpeg2000dec.c: Fix indentation

2020-04-04 Thread gautamramk
From: Gautam Ramakrishnan 

---
 libavcodec/jpeg2000dec.c | 16 
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/libavcodec/jpeg2000dec.c b/libavcodec/jpeg2000dec.c
index f2039fa8c1..7033417c65 100644
--- a/libavcodec/jpeg2000dec.c
+++ b/libavcodec/jpeg2000dec.c
@@ -1346,14 +1346,14 @@ static int 
jpeg2000_decode_packets_po_iteration(Jpeg2000DecoderContext *s, Jpeg2
 continue;
 }
 
-for (layno = 0; layno < LYEpoc; layno++) {
-if ((ret = jpeg2000_decode_packet(s, tile, 
tp_index,
-codsty, rlevel,
-precno, layno,
-qntsty->expn + 
(reslevelno ? 3 * (reslevelno - 1) + 1 : 0),
-
qntsty->nguardbits)) < 0)
-return ret;
-}
+for (layno = 0; layno < LYEpoc; layno++) {
+if ((ret = jpeg2000_decode_packet(s, tile, 
tp_index,
+  codsty, rlevel,
+  precno, layno,
+  qntsty->expn + 
(reslevelno ? 3 * (reslevelno - 1) + 1 : 0),
+  
qntsty->nguardbits)) < 0)
+return ret;
+}
 }
 }
 }
-- 
2.17.1

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

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

Re: [FFmpeg-devel] [PATCH] avformat/matroskaenc: add matroska subtitle muxer (.mks)

2020-04-04 Thread Andreas Rheinhardt
Jan Chren (rindeal):
> Signed-off-by: Jan Chren (rindeal) 
> ---
>  libavformat/matroskaenc.c | 28 
>  1 file changed, 28 insertions(+)
> 
> diff --git a/libavformat/matroskaenc.c b/libavformat/matroskaenc.c
> index 5dae53026d8..62127fe97f0 100644
> --- a/libavformat/matroskaenc.c
> +++ b/libavformat/matroskaenc.c
> @@ -2793,3 +2793,31 @@ AVOutputFormat ff_matroska_audio_muxer = {
>  .priv_class= _class,
>  };
>  #endif
> +
> +#if CONFIG_MATROSKA_SUBTITLE_MUXER
> +static const AVClass mks_class = {
> +.class_name = "matroska subtitle muxer",
> +.item_name  = av_default_item_name,
> +.option = options,
> +.version= LIBAVUTIL_VERSION_INT,
> +};
> +AVOutputFormat ff_matroska_subtitle_muxer = {
> +.name  = "matroska",
> +.long_name = NULL_IF_CONFIG_SMALL("Matroska Subtitles"),
> +.extensions= "mks",
> +.priv_data_size= sizeof(MatroskaMuxContext),
> +.subtitle_codec= AV_CODEC_ID_ASS,
> +.init  = mkv_init,
> +.deinit= mkv_deinit,
> +.write_header  = mkv_write_header,
> +.write_packet  = mkv_write_flush_packet,
> +.write_trailer = mkv_write_trailer,
> +.check_bitstream   = mkv_check_bitstream,
> +.flags = AVFMT_GLOBALHEADER | AVFMT_VARIABLE_FPS |
> + AVFMT_TS_NONSTRICT | AVFMT_ALLOW_FLUSH,
> +.codec_tag = (const AVCodecTag* const []){
> +additional_subtitle_tags, 0
> +},
> +.priv_class= _class,
> +};
> +#endif

Another base64 encoded email. I have therefore added the decoded mail
for everyone's convenience.

What is the aim of your patch? If it is simply making sure that using
the mks extension autoselects the Matroska muxer, then adding "mks" to
the list of extensions of the ordinary Matroska muxer would be enough.
(Notice that using mka for files with audio, but without video or mks
for subtitle-only files is just a convention; putting something else
than indicated by the extension in the files does not make them less
spec-compliant.)

And how did you test that your patch achieves your aim? Because again,
it shouldn't. You did not abide by the checklist [1] and therefore this
new muxer will never be used (in fact, it won't even be compiled by
default).

- Andreas

[1]: https://ffmpeg.org/developer.html#New-codecs-or-formats-checklist
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [PATCH] avformat/matroskaenc: remove MAX_TRACKS limit

2020-04-04 Thread Andreas Rheinhardt
Jan Chren (rindeal):
> RnJvbSA0M2U0Yjk2OTVhNDM0MjExMmIxMTE3ZGI2NTI2YmFmYTFmOWRhYjNlIE1vbiBTZXAgMTcg
> MDA6MDA6MDAgMjAwMQpGcm9tOiBKYW4gQ2hyZW4gKHJpbmRlYWwpIDxkZXYucmluZGVhbEBnbWFp
> bC5jb20+CkRhdGU6IFRodSwgMSBBcHIgMjAyMCAwMDowMDowMCArMDAwMApTdWJqZWN0OiBbUEFU
> Q0hdIGF2Zm9ybWF0L21hdHJvc2thZW5jOiByZW1vdmUgTUFYX1RSQUNLUyBsaW1pdAoKSXQgd2Fz
> IGludHJvZHVjZWQgaW4gN2JlMGY0OGEzMjE1NWVmOWY0NzFmZmM1YTFiNDFkNjYyZWEzMzdmMQp0
> byBzZXQgc2l6ZSBvZiBhbiBhcnJheSBzdHJ1Y3QgZmllbGQsIGJ1dCB0aGF0IGJhZCBkZXNpZ24g
> d2FzIGZpeGVkCmluIDY1ZWY3NGY3NDkwMDU5MGYxMzRiNGExMzBlOGY1NmU1MjcyZDE5MjUuCkFz
> IHN1Y2ggdGhpcyBhcnRpZmljaWFsIGxpbWl0IHNlcnZlcyBubyBwdXJwb3NlIGFueW1vcmUuCgpT
> aWduZWQtb2ZmLWJ5OiBKYW4gQ2hyZW4gKHJpbmRlYWwpIDxkZXYucmluZGVhbEBnbWFpbC5jb20+
> Ci0tLQogbGliYXZmb3JtYXQvbWF0cm9za2FlbmMuYyB8IDExIC0tLS0tLS0tLS0tCiAxIGZpbGUg
> Y2hhbmdlZCwgMTEgZGVsZXRpb25zKC0pCgpkaWZmIC0tZ2l0IGEvbGliYXZmb3JtYXQvbWF0cm9z
> a2FlbmMuYyBiL2xpYmF2Zm9ybWF0L21hdHJvc2thZW5jLmMKaW5kZXggNWRhZTUzMDI2ZDguLjNh
> ZjA1NDAzZDFkIDEwMDY0NAotLS0gYS9saWJhdmZvcm1hdC9tYXRyb3NrYWVuYy5jCisrKyBiL2xp
> YmF2Zm9ybWF0L21hdHJvc2thZW5jLmMKQEAgLTExNywxMCArMTE3LDYgQEAgdHlwZWRlZiBzdHJ1
> Y3QgbWt2X2F0dGFjaG1lbnRzIHsKICNkZWZpbmUgTU9ERV9NQVRST1NLQXYyIDB4MDEKICNkZWZp
> bmUgTU9ERV9XRUJNICAgICAgIDB4MDIKIAotLyoqIE1heGltdW0gbnVtYmVyIG9mIHRyYWNrcyBh
> bGxvd2VkIGluIGEgTWF0cm9za2EgZmlsZSAod2l0aCB0cmFjayBudW1iZXJzIGluCi0gKiByYW5n
> ZSAxIHRvIDEyNiAoaW5jbHVzaXZlKSAqLwotI2RlZmluZSBNQVhfVFJBQ0tTIDEyNgotCiB0eXBl
> ZGVmIHN0cnVjdCBNYXRyb3NrYU11eENvbnRleHQgewogICAgIGNvbnN0IEFWQ2xhc3MgICAqY2xh
> c3M7CiAgICAgaW50ICAgICAgICAgICAgIG1vZGU7CkBAIC0yNjA0LDEzICsyNjAwLDYgQEAgc3Rh
> dGljIGludCBta3ZfaW5pdChzdHJ1Y3QgQVZGb3JtYXRDb250ZXh0ICpzKQogewogICAgIGludCBp
> OwogCi0gICAgaWYgKHMtPm5iX3N0cmVhbXMgPiBNQVhfVFJBQ0tTKSB7Ci0gICAgICAgIGF2X2xv
> ZyhzLCBBVl9MT0dfRVJST1IsCi0gICAgICAgICAgICAgICAiQXQgbW9zdCAlZCBzdHJlYW1zIGFy
> ZSBzdXBwb3J0ZWQgZm9yIG11eGluZyBpbiBNYXRyb3NrYVxuIiwKLSAgICAgICAgICAgICAgIE1B
> WF9UUkFDS1MpOwotICAgICAgICByZXR1cm4gQVZFUlJPUihFSU5WQUwpOwotICAgIH0KLQogICAg
> IGZvciAoaSA9IDA7IGkgPCBzLT5uYl9zdHJlYW1zOyBpKyspIHsKICAgICAgICAgaWYgKHMtPnN0
> cmVhbXNbaV0tPmNvZGVjcGFyLT5jb2RlY19pZCA9PSBBVl9DT0RFQ19JRF9BVFJBQzMgfHwKICAg
> ICAgICAgICAgIHMtPnN0cmVhbXNbaV0tPmNvZGVjcGFyLT5jb2RlY19pZCA9PSBBVl9DT0RFQ19J
> RF9DT09LIHx8Cg==
First, the content of your mail is somehow base64 encoded.

Are you running into this limitation? If so, do the files that you
create with this patch that have more than 127 tracks work? They
shouldn't. The reason for this (and the reason that I didn't remove this
limit altogether in 65ef74f74900590f134b4a130e8f56e5272d1925) lies in
the way the TrackNumber is encoded in the (Simple)Blocks: They are
encoded as variable-length numbers, so that encoding small TrackNumbers
takes up less bytes than encoding bigger TrackNumbers. More precisely,
TrackNumbers in the range 1..127 are encodable on one byte. And the way
they are written in mkv_write_block() and mkv_write_vtt_blocks() relies
on this. If you simply remove said limit, the tracks with TrackNumbers >
127 will not have any (Simple)Blocks associated with them; instead the
encoded TrackNumber will be the desired TrackNumber modulo 128 and the
(Simple)Block will appear to belong to the track with the encoded
TrackNumber (if one exists).** The results will of course be catastrophic.

Notice that I have sent a patchset that slightly increases the number of
allowed tracks (without fixing the root cause though, because I didn't
know if there are really people who run into this): [1] makes
attachments no longer count towards the limit; [2] increases the limit
to 127. I will resend said patchset soon.

- Andreas

[1]: https://ffmpeg.org/pipermail/ffmpeg-devel/2019-November/253452.html
[2]: https://ffmpeg.org/pipermail/ffmpeg-devel/2019-November/252563.html

*: The reason for setting MAX_TRACKS to 126 instead of 127 is probably
that the encoding corresponding to the number 127 is special when
encoding lengths (which use the same variable-length number scheme):
Here it denotes an unknown length instead of a length of 127. But there
are no such values with a special meaning for encoded TrackNumbers.
**: Notice that a TrackNumber of 0 is invalid, so any (Simple)Block that
ought to belong to the tracks with TrackNumber 128, 256, 384, ... will
have no matching track at all. FFmpeg's Matroska demuxer treats
encountering such (Simple)Blocks as a sign of invalid data and it will
try to resync to the next level 1 element (typically the next Cluster).
Similar things can happen if you use attachments (in this case there may
be gaps in the used TrackNumbers).
___
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".