Re: [FFmpeg-devel] [PATCH] ansi: process ESC[3m italics attribute

[Paul B Mahol]

lgtm

On 2/18/20, Peter Ross  wrote:
> squelch unknown escape code warnings
> ---
>  libavcodec/ansi.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/libavcodec/ansi.c b/libavcodec/ansi.c
> index 5e1035ffd0..516d07db69 100644
> --- a/libavcodec/ansi.c
> +++ b/libavcodec/ansi.c
> @@ -34,6 +34,7 @@
>
>  #define ATTR_BOLD 0x01  /**< Bold/Bright-foreground (mode 1) */
>  #define ATTR_FAINT0x02  /**< Faint (mode 2) */
> +#define ATTR_ITALICS  0x04  /**< Italics (mode 3) */
>  #define ATTR_UNDERLINE0x08  /**< Underline (mode 4) */
>  #define ATTR_BLINK0x10  /**< Blink/Bright-background (mode 5) */
>  #define ATTR_REVERSE  0x40  /**< Reverse (mode 7) */
> @@ -308,7 +309,7 @@ static int execute_code(AVCodecContext * avctx, int c)
>  s->attributes = 0;
>  s->fg = DEFAULT_FG_COLOR;
>  s->bg = DEFAULT_BG_COLOR;
> -} else if (m == 1 || m == 2 || m == 4 || m == 5 || m == 7 || m
> == 8) {
> +} else if (m == 1 || m == 2 || m == 3 || m == 4 || m == 5 || m
> == 7 || m == 8) {
>  s->attributes |= 1 << (m - 1);
>  } else if (m >= 30 && m <= 37) {
>  s->fg = ansi_to_cga[m - 30];
> --
> 2.20.1
>
> -- Peter
> (A907 E02F A6E5 0CD2 34CD 20D2 6760 79C5 AC40 DD6B)
>
___
ffmpeg-devel mailing list
ffmpeg-devel@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] dvbsub.c, change segment order to be in line with spec

[Alen Vrečko]

Sure thing. I attached a new patch.

Thank you.

Alen

- Original Message -
From: "Carl Eugen Hoyos" 
To: "ffmpeg-devel" 
Sent: Monday, February 17, 2020 6:28:17 PM
Subject: Re: [FFmpeg-devel] dvbsub.c,   change segment order to be in line with 
spec

> Am 17.02.2020 um 16:10 schrieb Alen Vrečko :
> 
> Hello, everyone.
> 
> I'd like to request a change in order of DVB segments to be in line with ETSI 
> 300 743. Basically Region Composition Segment should come before CLUT 
> segment. This caused problems on legacy STBs namely Amino A110. 
> 
> In the ETSI EN 300 743 V1.6.1 (2018-10) section 4.4 it is written: 
> 
> The order of their listing here matches their ordering, when present, in a 
> display set: 
> display definition segment ... 
> page composition segment ... 
> region composition segment ... 
> disparity signalling segment ... 
> CLUT definition segment ... 
> alternative CLUT segment ... 
> object data segment ... 
> end of display set segment ...
> 
> It makes sense for this order to be implemented by ffmpeg.
> 
> I attached a patch, made using git format-patch.

This should really include a micro library version bump.

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".From 38e966fbbfa28e2ba6cbbaf3af54047f861e58d5 Mon Sep 17 00:00:00 2001
From: Alen Vrecko 
Date: Mon, 17 Feb 2020 15:47:05 +0100
Subject: [PATCH] Change Dvb segment order to be the same as in ETSI EN 300 743
 spec.

Having CLUT before Region Composition Segment caused problems on legacy STBs i.e. Amino A110.

In any case, the spec assumes an order. In section 4.4. It is written: "The order of their listing (referring to segment types) here matches their ordering, when present, in a display set". I think ffmpeg should match the order.

Mico version bump for changing Dvb Sub order.
---
 libavcodec/dvbsub.c  | 80 ++--
 libavcodec/version.h |  2 +-
 2 files changed, 41 insertions(+), 41 deletions(-)

diff --git a/libavcodec/dvbsub.c b/libavcodec/dvbsub.c
index a8d43d81d6..e76d3044b8 100644
--- a/libavcodec/dvbsub.c
+++ b/libavcodec/dvbsub.c
@@ -296,6 +296,46 @@ static int encode_dvb_subtitles(AVCodecContext *avctx,
 
 bytestream_put_be16(&pseg_len, q - pseg_len - 2);
 
+for (region_id = 0; region_id < h->num_rects; region_id++) {
+
+/* region composition segment */
+
+if (h->rects[region_id]->nb_colors <= 4) {
+/* 2 bpp, some decoders do not support it correctly */
+bpp_index = 0;
+} else if (h->rects[region_id]->nb_colors <= 16) {
+/* 4 bpp, standard encoding */
+bpp_index = 1;
+} else if (h->rects[region_id]->nb_colors <= 256) {
+/* 8 bpp, standard encoding */
+bpp_index = 2;
+} else {
+return -1;
+}
+
+*q++ = 0x0f; /* sync_byte */
+*q++ = 0x11; /* segment_type */
+bytestream_put_be16(&q, page_id);
+pseg_len = q;
+q += 2; /* segment length */
+*q++ = region_id;
+*q++ = (s->object_version << 4) | (0 << 3) | 0x07; /* version , no fill */
+bytestream_put_be16(&q, h->rects[region_id]->w); /* region width */
+bytestream_put_be16(&q, h->rects[region_id]->h); /* region height */
+*q++ = ((1 + bpp_index) << 5) | ((1 + bpp_index) << 2) | 0x03;
+*q++ = region_id; /* clut_id == region_id */
+*q++ = 0; /* 8 bit fill colors */
+*q++ = 0x03; /* 4 bit and 2 bit fill colors */
+
+bytestream_put_be16(&q, region_id); /* object_id == region_id */
+*q++ = (0 << 6) | (0 << 4);
+*q++ = 0;
+*q++ = 0xf0;
+*q++ = 0;
+
+bytestream_put_be16(&pseg_len, q - pseg_len - 2);
+}
+
 if (h->num_rects) {
 for (clut_id = 0; clut_id < h->num_rects; clut_id++) {
 
@@ -346,46 +386,6 @@ static int encode_dvb_subtitles(AVCodecContext *avctx,
 }
 }
 
-for (region_id = 0; region_id < h->num_rects; region_id++) {
-
-/* region composition segment */
-
-if (h->rects[region_id]->nb_colors <= 4) {
-/* 2 bpp, some decoders do not support it correctly */
-bpp_index = 0;
-} else if (h->rects[region_id]->nb_colors <= 16) {
-/* 4 bpp, standard encoding */
-bpp_index = 1;
-} else if (h->rects[region_id]->nb_colors <= 256) {
-/* 8 bpp, standard encoding */
-bpp_index = 2;
-} else {
-return -1;
-}
-
-*q++ = 0x0f; /* sync_byte */
-*q++ = 0x11; /* segment_type */
-bytestream_put_be16(&q, page_id);
-pseg_len = q;
-q += 2; /* segment length */
-*q++ = region_id;
-*q++ = (s->object_version << 4) | (0 << 3) | 0x07; /* version 

Re: [FFmpeg-devel] dvbsub.c, change segment order to be in line with spec

[Alen Vrečko]

On https://patchwork.ffmpeg.org/project/ffmpeg/list/ the new patch doesn't show 
up. I used the same filename as before.

Just in case sending it again with changed filename (and also changed commit 
message).

Sorry for the extra message.

Alen

- Original Message -
From: "Alen Vrečko" 
To: "ffmpeg-devel" 
Sent: Tuesday, February 18, 2020 11:15:04 AM
Subject: Re: [FFmpeg-devel] dvbsub.c, change segment order to be in line with 
spec

Sure thing. I attached a new patch.

Thank you.

Alen

- Original Message -
From: "Carl Eugen Hoyos" 
To: "ffmpeg-devel" 
Sent: Monday, February 17, 2020 6:28:17 PM
Subject: Re: [FFmpeg-devel] dvbsub.c,   change segment order to be in line with 
spec

> Am 17.02.2020 um 16:10 schrieb Alen Vrečko :
> 
> Hello, everyone.
> 
> I'd like to request a change in order of DVB segments to be in line with ETSI 
> 300 743. Basically Region Composition Segment should come before CLUT 
> segment. This caused problems on legacy STBs namely Amino A110. 
> 
> In the ETSI EN 300 743 V1.6.1 (2018-10) section 4.4 it is written: 
> 
> The order of their listing here matches their ordering, when present, in a 
> display set: 
> display definition segment ... 
> page composition segment ... 
> region composition segment ... 
> disparity signalling segment ... 
> CLUT definition segment ... 
> alternative CLUT segment ... 
> object data segment ... 
> end of display set segment ...
> 
> It makes sense for this order to be implemented by ffmpeg.
> 
> I attached a patch, made using git format-patch.

This should really include a micro library version bump.

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".From d3c475fa7ea0984b7f603b02d32eb59363f727f5 Mon Sep 17 00:00:00 2001
From: Alen Vrecko 
Date: Mon, 17 Feb 2020 15:47:05 +0100
Subject: [PATCH] Change Dvb segment order to be in line with ETSI EN 300 743.

Having CLUT before Region Composition Segment caused problems on legacy STBs i.e. Amino A110.

In the ETSI EN 300 743 V1.6.1 (2018-10) section 4.4 it is written:

The order of their listing here matches their ordering, when present, in a display set:
display definition segment ...
page composition segment ...
region composition segment ...
disparity signalling segment ...
CLUT definition segment ...
alternative CLUT segment ...
object data segment ...
end of display set segment ...

It makes sense for this order to be respected by ffmpeg.
---
 libavcodec/dvbsub.c  | 80 ++--
 libavcodec/version.h |  2 +-
 2 files changed, 41 insertions(+), 41 deletions(-)

diff --git a/libavcodec/dvbsub.c b/libavcodec/dvbsub.c
index a8d43d81d6..e76d3044b8 100644
--- a/libavcodec/dvbsub.c
+++ b/libavcodec/dvbsub.c
@@ -296,6 +296,46 @@ static int encode_dvb_subtitles(AVCodecContext *avctx,
 
 bytestream_put_be16(&pseg_len, q - pseg_len - 2);
 
+for (region_id = 0; region_id < h->num_rects; region_id++) {
+
+/* region composition segment */
+
+if (h->rects[region_id]->nb_colors <= 4) {
+/* 2 bpp, some decoders do not support it correctly */
+bpp_index = 0;
+} else if (h->rects[region_id]->nb_colors <= 16) {
+/* 4 bpp, standard encoding */
+bpp_index = 1;
+} else if (h->rects[region_id]->nb_colors <= 256) {
+/* 8 bpp, standard encoding */
+bpp_index = 2;
+} else {
+return -1;
+}
+
+*q++ = 0x0f; /* sync_byte */
+*q++ = 0x11; /* segment_type */
+bytestream_put_be16(&q, page_id);
+pseg_len = q;
+q += 2; /* segment length */
+*q++ = region_id;
+*q++ = (s->object_version << 4) | (0 << 3) | 0x07; /* version , no fill */
+bytestream_put_be16(&q, h->rects[region_id]->w); /* region width */
+bytestream_put_be16(&q, h->rects[region_id]->h); /* region height */
+*q++ = ((1 + bpp_index) << 5) | ((1 + bpp_index) << 2) | 0x03;
+*q++ = region_id; /* clut_id == region_id */
+*q++ = 0; /* 8 bit fill colors */
+*q++ = 0x03; /* 4 bit and 2 bit fill colors */
+
+bytestream_put_be16(&q, region_id); /* object_id == region_id */
+*q++ = (0 << 6) | (0 << 4);
+*q++ = 0;
+*q++ = 0xf0;
+*q++ = 0;
+
+bytestream_put_be16(&pseg_len, q - pseg_len - 2);
+}
+
 if (h->num_rects) {
 for (clut_id = 0; clut_id < h->num_rects; clut_id++) {
 
@@ -346,46 +386,6 @@ static int encode_dvb_subtitles(AVCodecContext *avctx,
 }
 }

[FFmpeg-devel] [PATCH v2 2/2] avformat: add demuxer for Rayman 2's APM format

[Zane van Iperen]

Adds support for the APM file format used by Ubisoft's Rayman 2.

Signed-off-by: Zane van Iperen 
---
 libavformat/Makefile |   1 +
 libavformat/allformats.c |   1 +
 libavformat/apm.c| 188 +++
 libavformat/version.h|   4 +-
 4 files changed, 192 insertions(+), 2 deletions(-)
 create mode 100644 libavformat/apm.c

diff --git a/libavformat/Makefile b/libavformat/Makefile
index a9972fd99a..e0681058a2 100644
--- a/libavformat/Makefile
+++ b/libavformat/Makefile
@@ -92,6 +92,7 @@ OBJS-$(CONFIG_AMRWB_DEMUXER) += amr.o
 OBJS-$(CONFIG_ANM_DEMUXER)   += anm.o
 OBJS-$(CONFIG_APC_DEMUXER)   += apc.o
 OBJS-$(CONFIG_APE_DEMUXER)   += ape.o apetag.o img2.o
+OBJS-$(CONFIG_APM_DEMUXER)   += apm.o
 OBJS-$(CONFIG_APNG_DEMUXER)  += apngdec.o
 OBJS-$(CONFIG_APNG_MUXER)+= apngenc.o
 OBJS-$(CONFIG_APTX_DEMUXER)  += aptxdec.o rawdec.o
diff --git a/libavformat/allformats.c b/libavformat/allformats.c
index 3ea4100e85..0209bf0e30 100644
--- a/libavformat/allformats.c
+++ b/libavformat/allformats.c
@@ -53,6 +53,7 @@ extern AVInputFormat  ff_amrwb_demuxer;
 extern AVInputFormat  ff_anm_demuxer;
 extern AVInputFormat  ff_apc_demuxer;
 extern AVInputFormat  ff_ape_demuxer;
+extern AVInputFormat  ff_apm_demuxer;
 extern AVInputFormat  ff_apng_demuxer;
 extern AVOutputFormat ff_apng_muxer;
 extern AVInputFormat  ff_aptx_demuxer;
diff --git a/libavformat/apm.c b/libavformat/apm.c
new file mode 100644
index 00..3fbf6107c8
--- /dev/null
+++ b/libavformat/apm.c
@@ -0,0 +1,188 @@
+/*
+ * Rayman 2 APM Demuxer
+ *
+ * Copyright (C) 2020 Zane van Iperen (z...@zanevaniperen.com)
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+#include "avformat.h"
+#include "internal.h"
+#include "riff.h"
+#include "libavutil/internal.h"
+#include "libavutil/intreadwrite.h"
+
+#define APM_FILE_HEADER_SIZE20
+#define APM_VS12_CHUNK_SIZE 76
+#define APM_MAX_READ_SIZE   4096
+
+#define APM_TAG_VS12MKTAG('v', 's', '1', '2')
+#define APM_TAG_DATAMKTAG('D', 'A', 'T', 'A')
+
+typedef struct APMState {
+int32_t has_saved;
+int32_t predictor_r;
+int32_t step_index_r;
+int32_t saved_r;
+int32_t predictor_l;
+int32_t step_index_l;
+int32_t saved_l;
+} APMState;
+
+typedef struct APMVS12Chunk {
+uint32_tmagic;
+uint32_tfile_size;
+uint32_tdata_size;
+uint32_tunk1;
+uint32_tunk2;
+APMStatestate;
+uint32_tpad[7];
+} APMVS12Chunk;
+
+static void apm_parse_vs12(APMVS12Chunk *vs12, const uint8_t *buf)
+{
+vs12->magic = AV_RL32(buf + 0);
+vs12->file_size = AV_RL32(buf + 4);
+vs12->data_size = AV_RL32(buf + 8);
+vs12->unk1  = AV_RL32(buf + 12);
+vs12->unk2  = AV_RL32(buf + 16);
+
+vs12->state.has_saved   = AV_RL32(buf + 20);
+vs12->state.predictor_r = AV_RL32(buf + 24);
+vs12->state.step_index_r= AV_RL32(buf + 28);
+vs12->state.saved_r = AV_RL32(buf + 32);
+vs12->state.predictor_l = AV_RL32(buf + 36);
+vs12->state.step_index_l= AV_RL32(buf + 40);
+vs12->state.saved_l = AV_RL32(buf + 44);
+
+for (int i = 0; i < FF_ARRAY_ELEMS(vs12->pad); i++)
+vs12->pad[i]= AV_RL32(buf + 48 + (i * 4));
+}
+
+static int apm_probe(const AVProbeData *p)
+{
+if (p->buf_size < 100)
+return 0;
+
+if (AV_RL32(p->buf + 20) != APM_TAG_VS12)
+return 0;
+
+if (AV_RL32(p->buf + 96) != APM_TAG_DATA)
+return 0;
+
+return AVPROBE_SCORE_MAX - 1;
+}
+
+static int apm_read_header(AVFormatContext *s)
+{
+int64_t ret;
+AVStream *st;
+APMVS12Chunk vs12;
+uint8_t buf[APM_VS12_CHUNK_SIZE];
+
+if (!(st = avformat_new_stream(s, NULL)))
+return AVERROR(ENOMEM);
+
+/* The header starts with a WAVEFORMATEX */
+if ((ret = ff_get_wav_header(s, s->pb, st->codecpar, APM_FILE_HEADER_SIZE, 
0)) < 0)
+return ret;
+
+if (st->codecpar->bits_per_coded_sample != 4)
+return AVERROR_INVALIDDATA;
+
+if (st->codecpar->codec_tag != 0x2000)
+ 

[FFmpeg-devel] [PATCH v2 1/2] avcodec: add decoder for Rayman 2's ADPCM variant

[Zane van Iperen]

Adds support for the ADPCM variant used in Rayman 2's files.

Signed-off-by: Zane van Iperen 
---
 libavcodec/Makefile |  1 +
 libavcodec/adpcm.c  | 24 
 libavcodec/allcodecs.c  |  1 +
 libavcodec/avcodec.h|  1 +
 libavcodec/codec_desc.c |  7 +++
 libavcodec/version.h|  2 +-
 6 files changed, 35 insertions(+), 1 deletion(-)

diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index 46da42570f..f2facab652 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -834,6 +834,7 @@ OBJS-$(CONFIG_ADPCM_G726LE_DECODER)   += g726.o
 OBJS-$(CONFIG_ADPCM_G726LE_ENCODER)   += g726.o
 OBJS-$(CONFIG_ADPCM_IMA_AMV_DECODER)  += adpcm.o adpcm_data.o
 OBJS-$(CONFIG_ADPCM_IMA_APC_DECODER)  += adpcm.o adpcm_data.o
+OBJS-$(CONFIG_ADPCM_IMA_APM_DECODER)  += adpcm.o adpcm_data.o
 OBJS-$(CONFIG_ADPCM_IMA_DAT4_DECODER) += adpcm.o adpcm_data.o
 OBJS-$(CONFIG_ADPCM_IMA_DK3_DECODER)  += adpcm.o adpcm_data.o
 OBJS-$(CONFIG_ADPCM_IMA_DK4_DECODER)  += adpcm.o adpcm_data.o
diff --git a/libavcodec/adpcm.c b/libavcodec/adpcm.c
index f5d20ddd81..c85b68b2ba 100644
--- a/libavcodec/adpcm.c
+++ b/libavcodec/adpcm.c
@@ -14,6 +14,7 @@
  * THP ADPCM decoder by Marco Gerards (mgera...@xs4all.nl)
  * Argonaut Games ADPCM decoder by Zane van Iperen (z...@zanevaniperen.com)
  * Simon & Schuster Interactive ADPCM decoder by Zane van Iperen 
(z...@zanevaniperen.com)
+ * Ubisoft ADPCM decoder by Zane van Iperen (z...@zanevaniperen.com)
  *
  * This file is part of FFmpeg.
  *
@@ -150,6 +151,14 @@ static av_cold int adpcm_decode_init(AVCodecContext * 
avctx)
 c->status[1].predictor = av_clip_intp2(AV_RL32(avctx->extradata + 
4), 18);
 }
 break;
+case AV_CODEC_ID_ADPCM_IMA_APM:
+if (avctx->extradata && avctx->extradata_size >= 16) {
+c->status[0].predictor  = AV_RL32(avctx->extradata +  0);
+c->status[0].step_index = AV_RL32(avctx->extradata +  4);
+c->status[1].predictor  = AV_RL32(avctx->extradata +  8);
+c->status[1].step_index = AV_RL32(avctx->extradata + 12);
+}
+break;
 case AV_CODEC_ID_ADPCM_IMA_WS:
 if (avctx->extradata && avctx->extradata_size >= 2)
 c->vqa_version = AV_RL16(avctx->extradata);
@@ -168,6 +177,7 @@ static av_cold int adpcm_decode_init(AVCodecContext * avctx)
 
 switch(avctx->codec->id) {
 case AV_CODEC_ID_ADPCM_AICA:
+case AV_CODEC_ID_ADPCM_IMA_APM:
 case AV_CODEC_ID_ADPCM_IMA_DAT4:
 case AV_CODEC_ID_ADPCM_IMA_QT:
 case AV_CODEC_ID_ADPCM_IMA_WAV:
@@ -665,6 +675,7 @@ static int get_nb_samples(AVCodecContext *avctx, 
GetByteContext *gb,
 case AV_CODEC_ID_ADPCM_YAMAHA:
 case AV_CODEC_ID_ADPCM_AICA:
 case AV_CODEC_ID_ADPCM_IMA_SSI:
+case AV_CODEC_ID_ADPCM_IMA_APM:
 nb_samples = buf_size * 2 / ch;
 break;
 }
@@ -1227,6 +1238,18 @@ static int adpcm_decode_frame(AVCodecContext *avctx, 
void *data,
 *samples++ = adpcm_ima_qt_expand_nibble(&c->status[st], v & 0x0F, 
3);
 }
 break;
+case AV_CODEC_ID_ADPCM_IMA_APM:
+for (channel = 0; bytestream2_get_bytes_left(&gb) > 0;) {
+int v = bytestream2_get_byteu(&gb);
+*samples_p[channel]++ = 
adpcm_ima_qt_expand_nibble(&c->status[channel], v >> 4, 3);
+*samples_p[channel]++ = 
adpcm_ima_qt_expand_nibble(&c->status[channel], v & 0x0F, 3);
+channel = (channel + 1) % avctx->channels;
+}
+
+/* Changing samples_p changes the frame itself. Undo any damage. */
+for (channel = 0; channel < avctx->channels; channel++)
+samples_p[channel] -= nb_samples;
+break;
 case AV_CODEC_ID_ADPCM_IMA_OKI:
 while (bytestream2_get_bytes_left(&gb) > 0) {
 int v = bytestream2_get_byteu(&gb);
@@ -1965,6 +1988,7 @@ ADPCM_DECODER(AV_CODEC_ID_ADPCM_EA_R3,   
sample_fmts_s16p, adpcm_ea_r3,
 ADPCM_DECODER(AV_CODEC_ID_ADPCM_EA_XAS,  sample_fmts_s16p, adpcm_ea_xas,   
   "ADPCM Electronic Arts XAS");
 ADPCM_DECODER(AV_CODEC_ID_ADPCM_IMA_AMV, sample_fmts_s16,  adpcm_ima_amv,  
   "ADPCM IMA AMV");
 ADPCM_DECODER(AV_CODEC_ID_ADPCM_IMA_APC, sample_fmts_s16,  adpcm_ima_apc,  
   "ADPCM IMA CRYO APC");
+ADPCM_DECODER(AV_CODEC_ID_ADPCM_IMA_APM, sample_fmts_s16p, adpcm_ima_apm,  
   "ADPCM IMA Ubisoft APM");
 ADPCM_DECODER(AV_CODEC_ID_ADPCM_IMA_DAT4,sample_fmts_s16,  adpcm_ima_dat4, 
   "ADPCM IMA Eurocom DAT4");
 ADPCM_DECODER(AV_CODEC_ID_ADPCM_IMA_DK3, sample_fmts_s16,  adpcm_ima_dk3,  
   "ADPCM IMA Duck DK3");
 ADPCM_DECODER(AV_CODEC_ID_ADPCM_IMA_DK4, sample_fmts_s16,  adpcm_ima_dk4,  
   "ADPCM IMA Duck DK4");
diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
index 103f34fd32..6f543ea96f 100644
--- a/libavcodec/allcodecs.c
+++ b/libavcodec/allcodecs.c
@@ -599,6 +599,7 @@ extern AVCodec ff_adpcm_g726le_encoder;
 extern AVCodec ff_adpcm_g726le_decoder;
 e

[FFmpeg-devel] [PATCH v2 0/2] Ubisoft Rayman 2 APM demuxer + decoder.

[Zane van Iperen]

Hi all,

This patchset adds support for the APM files used by Rayman 2.

It has been tested against all *.apm files in the game folder.

v2:
  - Change extradata to use AV_{W,R}L32 instead of AV_{W,R}N32
  - fix version
  - add probe function
  - removed an unnecessary `n = 0`

Zane

Zane van Iperen (2):
  avcodec: add decoder for Rayman 2's ADPCM variant
  avformat: add demuxer for Rayman 2's APM format

 libavcodec/Makefile  |   1 +
 libavcodec/adpcm.c   |  24 +
 libavcodec/allcodecs.c   |   1 +
 libavcodec/avcodec.h |   1 +
 libavcodec/codec_desc.c  |   7 ++
 libavcodec/version.h |   2 +-
 libavformat/Makefile |   1 +
 libavformat/allformats.c |   1 +
 libavformat/apm.c| 188 +++
 libavformat/version.h|   4 +-
 10 files changed, 227 insertions(+), 3 deletions(-)
 create mode 100644 libavformat/apm.c

-- 
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 1/2] avformat/wtvdec: Forward errors when reading packet

[Andreas Rheinhardt]

Andreas Rheinhardt:
> wtvfile_read_packet did not abide by the requirements of an
> AVIOContext's read_packet-function: If it did not read anything,
> it returned zero, which currently leads to a warning in read_packet_wrapper
> in aviobuf.c. Said warning will be an av_assert2 as soon as
> FF_API_OLD_AVIO_EOF_0 is zero (probably the next major version bump).
> So instead forward the error code from the underlying protocol.
> 
> This error/assert is triggered in the wtv-demux FATE test.
> 
> Signed-off-by: Andreas Rheinhardt 
> ---
> This patch supersedes [1]. The difference to the previous version is
> that I have changed the return value from "nread ? nread : n ? :
> AVERROR_EOF" to "nread ? nread : n". This can only make a difference if
> buf_size (the size of the data to be read) is zero and I now think that
> this should simply not happen: It would be possible by calling
> avio_read_partial with a desired size of 0 and if the AVIOContext's
> write_flag is set, but avio_read_partial is not called with one of
> wtvdec's custom AVIOContexts (not to mention that if this were a
> problem, it should probably be fixed in avio_read_partial).
> 
> [1]: 
> https://patchwork.ffmpeg.org/project/ffmpeg/patch/20190821090438.10260-4-andreas.rheinha...@gmail.com/
> 
>  libavformat/wtvdec.c | 5 ++---
>  1 file changed, 2 insertions(+), 3 deletions(-)
> 
> diff --git a/libavformat/wtvdec.c b/libavformat/wtvdec.c
> index 67d934f074..83f510b92f 100644
> --- a/libavformat/wtvdec.c
> +++ b/libavformat/wtvdec.c
> @@ -71,7 +71,7 @@ static int wtvfile_read_packet(void *opaque, uint8_t *buf, 
> int buf_size)
>  {
>  WtvFile *wf = opaque;
>  AVIOContext *pb = wf->pb_filesystem;
> -int nread = 0;
> +int nread = 0, n = 0;
>  
>  if (wf->error || pb->error)
>  return -1;
> @@ -80,7 +80,6 @@ static int wtvfile_read_packet(void *opaque, uint8_t *buf, 
> int buf_size)
>  
>  buf_size = FFMIN(buf_size, wf->length - wf->position);
>  while(nread < buf_size) {
> -int n;
>  int remaining_in_sector = (1 << wf->sector_bits) - (wf->position & 
> ((1 << wf->sector_bits) - 1));
>  int read_request= FFMIN(buf_size - nread, 
> remaining_in_sector);
>  
> @@ -100,7 +99,7 @@ static int wtvfile_read_packet(void *opaque, uint8_t *buf, 
> int buf_size)
>  }
>  }
>  }
> -return nread;
> +return nread ? nread : n;
>  }
>  
>  /**
> 

Ping.

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

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

Re: [FFmpeg-devel] [PATCH 1/3] avutil/frame: add use_last_roi

[Anton Khirnov]

Quoting Guo, Yejun (2020-02-14 04:32:05)
> For some cases, the regions of interest do not change, it is not
> convenient to always prepare the roi data for every frame. So, add
> use_last_roi to show it uses the same roi data as last frame.
> 
> Since a new flag is added into AVFrame, the major version number of
> lavu is changed.

Why is this even necessary at all? I believe the convention for the
other side data types is that it applies from the frame it is attached
to onwards.

-- 
Anton Khirnov
___
ffmpeg-devel mailing list
ffmpeg-devel@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 2/4] avc/avcodec: add AV_CODEC_CAP_VARIABLE_DIMENSIONS flag

[Anton Khirnov]

Quoting Michael Niedermayer (2020-02-17 23:38:31)
> On Mon, Feb 17, 2020 at 06:28:23PM +, Fu, Linjie wrote:
> 
> > > > > https://patchwork.ffmpeg.org/patch/14122/
> 
> iam hesitating because it feeds encoders with changing resolution resulting
> in potentially undefined behavior ...
> 
> 
> > > > > https://patchwork.ffmpeg.org/patch/14139/
> 
> long discussion here its not immedeatly clear if anyone was against it
> 
> Also there is the question about the API, is there anything in the API
> documentation that restricts the user app from changing the encoder
> input frame dimensions?
> This should be documented somewhere if its not ...
> 
> If a flag is added that affects this, it would have to
> be documented so someone writing a user app using the encoders
> would know if they are allowed to change the resolution.
> With just the flag and its documentation a developer could miss
> the flag entirely

Is there even a sufficiently strong use case for this? Why not just
create a new encoder instance?

-- 
Anton Khirnov
___
ffmpeg-devel mailing list
ffmpeg-devel@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] Setting default G0 character set for teletext decoder

[k.savkov]

Some providers don't send info about character set, so default (latin) 
is used when decoding. I added option to force desired language with 
function vbi_teletext_set_default_region. You can see what character set 
code maps to what language in Table 32 ETS 300 706,  Section 15.


>From 1c5c903d893c74025f2e8f62050755eb11b74be8 Mon Sep 17 00:00:00 2001
From: Kirill Savkov 
Date: Tue, 18 Feb 2020 16:53:34 +0300
Subject: [PATCH] libavcodec/libzvbi-teletextdec.c: added option to set default
 G0 character set for decoding

Signed-off-by: Kirill Savkov 
---
 libavcodec/libzvbi-teletextdec.c | 30 ++
 1 file changed, 18 insertions(+), 12 deletions(-)

diff --git a/libavcodec/libzvbi-teletextdec.c b/libavcodec/libzvbi-teletextdec.c
index 3515f33924..b243c69293 100644
--- a/libavcodec/libzvbi-teletextdec.c
+++ b/libavcodec/libzvbi-teletextdec.c
@@ -55,6 +55,7 @@ typedef struct TeletextContext
 {
 AVClass*class;
 char   *pgno;
+int default_region;
 int x_offset;
 int y_offset;
 int format_id; /* 0 = bitmap, 1 = text/ass, 2 = ass */
@@ -645,6 +646,10 @@ static int teletext_decode_frame(AVCodecContext *avctx, void *data, int *data_si
 if (!ctx->vbi) {
 if (!(ctx->vbi = vbi_decoder_new()))
 return AVERROR(ENOMEM);
+if (ctx->default_region != -1) {
+av_log(avctx, AV_LOG_INFO, "Setting default zvbi region to %i\n", ctx->default_region);
+vbi_teletext_set_default_region(ctx->vbi, ctx->default_region);
+}
 if (!vbi_event_handler_register(ctx->vbi, VBI_EVENT_TTX_PAGE, handler, ctx)) {
 vbi_decoder_delete(ctx->vbi);
 ctx->vbi = NULL;
@@ -791,18 +796,19 @@ static void teletext_flush(AVCodecContext *avctx)
 #define OFFSET(x) offsetof(TeletextContext, x)
 #define SD AV_OPT_FLAG_SUBTITLE_PARAM | AV_OPT_FLAG_DECODING_PARAM
 static const AVOption options[] = {
-{"txt_page","page numbers to decode, subtitle for subtitles, * for all", OFFSET(pgno),   AV_OPT_TYPE_STRING, {.str = "*"},  0, 0,SD},
-{"txt_chop_top","discards the top teletext line",OFFSET(chop_top),   AV_OPT_TYPE_INT,{.i64 = 1},0, 1,SD},
-{"txt_format",  "format of the subtitles (bitmap or text or ass)",   OFFSET(format_id),  AV_OPT_TYPE_INT,{.i64 = 0},0, 2,SD,  "txt_format"},
-{"bitmap",  NULL,0,  AV_OPT_TYPE_CONST,  {.i64 = 0},0, 0,SD,  "txt_format"},
-{"text",NULL,0,  AV_OPT_TYPE_CONST,  {.i64 = 1},0, 0,SD,  "txt_format"},
-{"ass", NULL,0,  AV_OPT_TYPE_CONST,  {.i64 = 2},0, 0,SD,  "txt_format"},
-{"txt_left","x offset of generated bitmaps", OFFSET(x_offset),   AV_OPT_TYPE_INT,{.i64 = 0},0, 65535,SD},
-{"txt_top", "y offset of generated bitmaps", OFFSET(y_offset),   AV_OPT_TYPE_INT,{.i64 = 0},0, 65535,SD},
-{"txt_chop_spaces", "chops leading and trailing spaces from text",   OFFSET(chop_spaces),AV_OPT_TYPE_INT,{.i64 = 1},0, 1,SD},
-{"txt_duration","display duration of teletext pages in msecs",   OFFSET(sub_duration),   AV_OPT_TYPE_INT,{.i64 = -1},  -1, 8640, SD},
-{"txt_transparent", "force transparent background of the teletext",  OFFSET(transparent_bg), AV_OPT_TYPE_INT,{.i64 = 0},0, 1,SD},
-{"txt_opacity", "set opacity of the transparent background", OFFSET(opacity),AV_OPT_TYPE_INT,{.i64 = -1},  -1, 255,  SD},
+{"txt_page",   "page numbers to decode, subtitle for subtitles, * for all", OFFSET(pgno),   AV_OPT_TYPE_STRING, {.str = "*"},  0, 0,SD},
+{"txt_default_region", "default G0 character set used for decoding",OFFSET(default_region), AV_OPT_TYPE_INT,{.i64 = -1},  -1, 80,   SD},
+{"txt_chop_top",   "discards the top teletext line",OFFSET(chop_top),   AV_OPT_TYPE_INT,{.i64 = 1},0, 1,SD},
+{"txt_format", "format of the subtitles (bitmap or text or ass)",   OFFSET(format_id),  AV_OPT_TYPE_INT,{.i64 = 0},0, 2,SD,  "txt_format"},
+{"bitmap", NULL,0,  AV_OPT_TYPE_CONST,  {.i64 = 0},0, 0,SD,  "txt_format"},
+{"text",   NULL,0,  AV_OPT_TYPE_CONST,  {.i64 = 1},0, 0,SD,  "txt_format"},
+{"ass",NULL,   

Re: [FFmpeg-devel] [PATCH] hwcontext_vaapi: Only accept a render node when deriving from DRM device

[Anton Khirnov]

Quoting Mark Thompson (2020-02-16 21:59:54)
> If we are given a non-render node, try to find the matching render node and
> fail if that isn't possible.
> 
> libva will not accept a non-render device which is not DRM master, because
> it requires legacy DRM authentication to succeed in that case:
> .  This
> is annoying for kmsgrab because in most recording situations DRM master is
> already held by something else (such as a windowing system), leading to
> device derivation not working and forcing the user to create the target
> VAAPI device separately.
> ---
> Fixes a longstanding annoyance with -vf hwmap=derive_device=vaapi.
> 
> (E.g. .)

Looks reasonable.

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

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

Re: [FFmpeg-devel] [PATCH 1/6] avformat/format: add av_demuxer_find_by_ext

[Anton Khirnov]

Quoting Gyan Doshi (2020-02-01 06:15:30)
> 
> 
> On 31-01-2020 10:41 pm, Andreas Rheinhardt wrote:
> > Gyan Doshi:
> >> Allows selecting demuxer by extension which are more widely recognized
> >> by users.
> >>
> >> Conditional cast added since this function will usually be called after
> >> av_find_input_format, and so matches its return type.
> > That's not a good point. av_demuxer_find_by_ext() already always
> > returns const AVInputFormat *, so you casting the const away when
> > returning is pointless. Furthermore, any caller that wants to use this
> > new function can simply use a pointer to const AVInputFormat to work
> > with both av_find_input_format() and av_demuxer_find_by_ext(). And
> > after all, adding const makes the code more future-proof
> > (av_find_input_format() will return const AVInputFormat * after the
> > next major bump).
> 
> Ok, I don't think I should add const to the pointers at the receiving 
> end (fftools) since they are global variables and may not be acceptable 
> as const. So I'll cast away the const when receiving and remove the 
> conditional cast.

Why not? Nothing can conceivably modify the content of those structs, so
simply adding const to all their uses should work.

-- 
Anton Khirnov
___
ffmpeg-devel mailing list
ffmpeg-devel@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 2/4] avc/avcodec: add AV_CODEC_CAP_VARIABLE_DIMENSIONS flag

[Fu, Linjie]

> -Original Message-
> From: ffmpeg-devel  On Behalf Of
> Anton Khirnov
> Sent: Tuesday, February 18, 2020 21:32
> To: FFmpeg development discussions and patches  de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH, v2 2/4] avc/avcodec: add
> AV_CODEC_CAP_VARIABLE_DIMENSIONS flag
> 
> Quoting Michael Niedermayer (2020-02-17 23:38:31)
> > On Mon, Feb 17, 2020 at 06:28:23PM +, Fu, Linjie wrote:
> >
> > > > > > https://patchwork.ffmpeg.org/patch/14122/
> >
> > iam hesitating because it feeds encoders with changing resolution resulting
> > in potentially undefined behavior ...
> >

Any suggestions?

> > > > > > https://patchwork.ffmpeg.org/patch/14139/
> >
> > long discussion here its not immedeatly clear if anyone was against it

Please help to give some inputs if this would leads to some unexpected
results from your point of view.

> > Also there is the question about the API, is there anything in the API
> > documentation that restricts the user app from changing the encoder
> > input frame dimensions?
> > This should be documented somewhere if its not ...
> >
> > If a flag is added that affects this, it would have to
> > be documented so someone writing a user app using the encoders
> > would know if they are allowed to change the resolution.
> > With just the flag and its documentation a developer could miss
> > the flag entirely

Since I didn't find the descriptions in doxygen:
https://ffmpeg.org/doxygen/trunk/group__lavc__encoding.html#ga4fde50e2cad4cf3d66d882a7078aeab4

The things should be done seem to be:

[1]. Documentation in API, to declare that encoders require input frame to 
be in constant dimensions, unless the encoders have the capability of
dynamic resolution encoding [2].

[2]. Documentation in API, to declare this codec flag would affect the restrict 
in [1].

If it's ok, I'll update the patch with the documentations added.


> Is there even a sufficiently strong use case for this? Why not just

Like transcoding reinit-large_420_8-to-small_420_8.h264 (from 352x288 to 
240x196)
and prefer to keep the resolution changing in the output stream. 

IMHO not modifying the resolution unless it's required by user is kind of 
natural.

> create a new encoder instance?

Would you please help to elaborate more about "create a new encoder instance?"

What I intended to do is to flush and close the encoder when resolution 
changing,
and reinit/recreate a new one.


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

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

[FFmpeg-devel] [PATCH] crash fixed: live stream.

[Mostafa Namazi fard]

---
 libavformat/hls.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavformat/hls.c b/libavformat/hls.c
index 1f58e745a7..97b1a1db52 100644
--- a/libavformat/hls.c
+++ b/libavformat/hls.c
@@ -2110,7 +2110,7 @@ static int hls_read_packet(AVFormatContext *s,
AVPacket *pkt)
 /* Make sure we've got one buffered packet from each open playlist
  * stream */
 if (pls->needed && !pls->pkt.data) {
-while (1) {
+while (pls->ctx) {
 int64_t ts_diff;
 AVRational tb;
 ret = av_read_frame(pls->ctx, &pls->pkt);
-- 
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 1/6] avformat/format: add av_demuxer_find_by_ext

[Andreas Rheinhardt]

Anton Khirnov:
> Quoting Gyan Doshi (2020-02-01 06:15:30)
>>
>>
>> On 31-01-2020 10:41 pm, Andreas Rheinhardt wrote:
>>> Gyan Doshi:
 Allows selecting demuxer by extension which are more widely recognized
 by users.

 Conditional cast added since this function will usually be called after
 av_find_input_format, and so matches its return type.
>>> That's not a good point. av_demuxer_find_by_ext() already always
>>> returns const AVInputFormat *, so you casting the const away when
>>> returning is pointless. Furthermore, any caller that wants to use this
>>> new function can simply use a pointer to const AVInputFormat to work
>>> with both av_find_input_format() and av_demuxer_find_by_ext(). And
>>> after all, adding const makes the code more future-proof
>>> (av_find_input_format() will return const AVInputFormat * after the
>>> next major bump).
>>
>> Ok, I don't think I should add const to the pointers at the receiving 
>> end (fftools) since they are global variables and may not be acceptable 
>> as const. So I'll cast away the const when receiving and remove the 
>> conditional cast.
> 
> Why not? Nothing can conceivably modify the content of those structs, so
> simply adding const to all their uses should work.
> 
Then avformat_open_input() would have to be modified to accept a const
AVInputFormat *, otherwise one would get compiler warnings. And then
one would have to cast the const away in avformat_open_input() (should
probably already have been made in 3aa6208d to allow users to write
future-proof-code).
But the av_opt-API seems to be based around non-const structures which
may be a problem with the av_opt_find()-calls in open_input_file() in
ffmpeg_opt.c.

- 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] new patch

[Mostafa Namazi fard]

I found this patch useful for prevent crash in http live stream.
I'm using ffmpeg in my application for show http live when remote address
send invalid data ffmpeg crash in this part and after my change it was
fixed.
From 73c61670d6e65ad9f7a354a785f73ff9ad5ffc12 Mon Sep 17 00:00:00 2001
From: Mostafa Namazi 
Date: Tue, 18 Feb 2020 16:14:16 +0330
Subject: [PATCH] crash fixed: live stream.

---
 libavformat/hls.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavformat/hls.c b/libavformat/hls.c
index 1f58e745a7..97b1a1db52 100644
--- a/libavformat/hls.c
+++ b/libavformat/hls.c
@@ -2110,7 +2110,7 @@ static int hls_read_packet(AVFormatContext *s, AVPacket *pkt)
 /* Make sure we've got one buffered packet from each open playlist
  * stream */
 if (pls->needed && !pls->pkt.data) {
-while (1) {
+while (pls->ctx) {
 int64_t ts_diff;
 AVRational tb;
 ret = av_read_frame(pls->ctx, &pls->pkt);
-- 
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/3] avformat/dashenc: write the styp box when the first frame of a segment is ready

[James Almer]

This ensures it's written at the beginning of a segment in non streaming mode
when segment duration differs from fragment duration.

Signed-off-by: James Almer 
---
 libavformat/dashenc.c | 10 +++---
 1 file changed, 3 insertions(+), 7 deletions(-)

diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c
index c89aa3a32c..5c1d24d3e2 100644
--- a/libavformat/dashenc.c
+++ b/libavformat/dashenc.c
@@ -1911,12 +1911,8 @@ static int dash_flush(AVFormatContext *s, int final, int 
stream)
 continue;
 }
 
-if (!c->single_file) {
-if (os->segment_type == SEGMENT_TYPE_MP4 && !os->written_len)
-write_styp(os->ctx->pb);
-} else {
+if (c->single_file)
 snprintf(os->full_path, sizeof(os->full_path), "%s%s", c->dirname, 
os->initfile);
-}
 
 ret = flush_dynbuf(c, os, &range_length);
 if (ret < 0)
@@ -2188,6 +2184,8 @@ static int dash_write_packet(AVFormatContext *s, AVPacket 
*pkt)
 AVDictionary *opts = NULL;
 const char *proto = avio_find_protocol_name(s->url);
 int use_rename = proto && !strcmp(proto, "file");
+if (os->segment_type == SEGMENT_TYPE_MP4)
+write_styp(os->ctx->pb);
 os->filename[0] = os->full_path[0] = os->temp_path[0] = '\0';
 ff_dash_fill_tmpl_params(os->filename, sizeof(os->filename),
  os->media_seg_name, pkt->stream_index,
@@ -2212,8 +2210,6 @@ static int dash_write_packet(AVFormatContext *s, AVPacket 
*pkt)
 if (c->streaming && os->segment_type == SEGMENT_TYPE_MP4) {
 int len = 0;
 uint8_t *buf = NULL;
-if (!os->written_len)
-write_styp(os->ctx->pb);
 avio_flush(os->ctx->pb);
 len = avio_get_dyn_buf (os->ctx->pb, &buf);
 if (os->out) {
-- 
2.25.0

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

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

[FFmpeg-devel] [PATCH 2/3] avformat/dashenc: write a capture time Producer Reference Time element when none is provided by the encoder

[James Almer]

This way, the element will be present in any scenario when the write_prft 
option is used.

Signed-off-by: James Almer 
---
 libavformat/dashenc.c | 46 +--
 1 file changed, 36 insertions(+), 10 deletions(-)

diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c
index 5c1d24d3e2..b910cc22d0 100644
--- a/libavformat/dashenc.c
+++ b/libavformat/dashenc.c
@@ -129,6 +129,7 @@ typedef struct OutputStream {
 char temp_path[1024];
 double availability_time_offset;
 int64_t producer_reference_time;
+int producer_reference_time_flags;
 char producer_reference_time_str[100];
 int total_pkt_size;
 int64_t total_pkt_duration;
@@ -864,8 +865,8 @@ static int write_adaptation_set(AVFormatContext *s, 
AVIOContext *out, int as_ind
 s->streams[i]->codecpar->channels);
 }
 if (!final && c->write_prft && os->producer_reference_time_str[0]) {
-avio_printf(out, "\t\t\t\t\n",
-i, os->producer_reference_time_str, 
c->presentation_time_offset);
+avio_printf(out, "\t\t\t\t\n",
+i, os->producer_reference_time_flags ? "captured" : 
"encoder", os->producer_reference_time_str, c->presentation_time_offset);
 avio_printf(out, "\t\t\t\t\t\n", 
c->utc_timing_url);
 avio_printf(out, "\t\t\t\t\n");
 }
@@ -2002,6 +2003,35 @@ static int dash_flush(AVFormatContext *s, int final, int 
stream)
 return ret;
 }
 
+static int dash_parse_prft(DASHContext *c, AVPacket *pkt)
+{
+OutputStream *os = &c->streams[pkt->stream_index];
+int side_data_size;
+AVProducerReferenceTime *prft;
+
+if (!c->write_prft)
+return 0;
+
+prft = (AVProducerReferenceTime *)av_packet_get_side_data(pkt, 
AV_PKT_DATA_PRFT, &side_data_size);
+if (!prft || side_data_size != sizeof(AVProducerReferenceTime) || 
prft->flags) {
+// No encoder generated AVProducerReferenceTime side data. Instead of 
letting the mov muxer
+// generate a capture-time one for the first packet, do it here so we 
can also use it for the
+// manifest.
+prft = (AVProducerReferenceTime *)av_packet_new_side_data(pkt, 
AV_PKT_DATA_PRFT,
+  
sizeof(AVProducerReferenceTime));
+if (!prft)
+return AVERROR(ENOMEM);
+prft->wallclock = av_gettime();
+prft->flags = 24;
+}
+os->producer_reference_time = prft->wallclock;
+os->producer_reference_time_flags = prft->flags;
+if (c->target_latency_refid < 0)
+c->target_latency_refid = pkt->stream_index;
+
+return 0;
+}
+
 static int dash_write_packet(AVFormatContext *s, AVPacket *pkt)
 {
 DASHContext *c = s->priv_data;
@@ -2034,15 +2064,11 @@ static int dash_write_packet(AVFormatContext *s, 
AVPacket *pkt)
 }
 
 if (os->first_pts == AV_NOPTS_VALUE) {
-int side_data_size;
-AVProducerReferenceTime *prft = (AVProducerReferenceTime 
*)av_packet_get_side_data(pkt, AV_PKT_DATA_PRFT,
-   
&side_data_size);
-if (prft && side_data_size == sizeof(AVProducerReferenceTime) && 
!prft->flags) {
-os->producer_reference_time = prft->wallclock;
-if (c->target_latency_refid < 0)
-c->target_latency_refid = pkt->stream_index;
-}
 os->first_pts = pkt->pts;
+
+ret = dash_parse_prft(c, pkt);
+if (ret > 0)
+return ret;
 }
 os->last_pts = pkt->pts;
 
-- 
2.25.0

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

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

Re: [FFmpeg-devel] [PATCH 1/6] avformat/format: add av_demuxer_find_by_ext

[Anton Khirnov]

Quoting Andreas Rheinhardt (2020-02-18 16:01:00)
> Anton Khirnov:
> > Quoting Gyan Doshi (2020-02-01 06:15:30)
> >>
> >>
> >> On 31-01-2020 10:41 pm, Andreas Rheinhardt wrote:
> >>> Gyan Doshi:
>  Allows selecting demuxer by extension which are more widely recognized
>  by users.
> 
>  Conditional cast added since this function will usually be called after
>  av_find_input_format, and so matches its return type.
> >>> That's not a good point. av_demuxer_find_by_ext() already always
> >>> returns const AVInputFormat *, so you casting the const away when
> >>> returning is pointless. Furthermore, any caller that wants to use this
> >>> new function can simply use a pointer to const AVInputFormat to work
> >>> with both av_find_input_format() and av_demuxer_find_by_ext(). And
> >>> after all, adding const makes the code more future-proof
> >>> (av_find_input_format() will return const AVInputFormat * after the
> >>> next major bump).
> >>
> >> Ok, I don't think I should add const to the pointers at the receiving 
> >> end (fftools) since they are global variables and may not be acceptable 
> >> as const. So I'll cast away the const when receiving and remove the 
> >> conditional cast.
> > 
> > Why not? Nothing can conceivably modify the content of those structs, so
> > simply adding const to all their uses should work.
> > 
> Then avformat_open_input() would have to be modified to accept a const
> AVInputFormat *, otherwise one would get compiler warnings. And then
> one would have to cast the const away in avformat_open_input() (should
> probably already have been made in 3aa6208d to allow users to write
> future-proof-code).

It's already been modified to be const on the next bump, so the warning
would only be temporary. And we are planning to do a bump pretty soon
IIUC.

And I'm not sure if changing a function parameter from pointer to
pointer-to-const is actually an API break. It's merely an extra
constraint on what a function is allowed to do.

And besides, those structs are actually constant. They must not be
modified from the outside. So compiler warnings would be entirely
appropriate to remind us about invalid code.

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

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

[FFmpeg-devel] [PATCH 3/3] avformat/dashenc: always attempt to enable prft on ldash mode

[James Almer]

Signed-off-by: James Almer 
---
 libavformat/dashenc.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c
index b910cc22d0..045d2f4df6 100644
--- a/libavformat/dashenc.c
+++ b/libavformat/dashenc.c
@@ -1395,6 +1395,11 @@ static int dash_init(AVFormatContext *s)
 c->frag_type = FRAG_TYPE_EVERY_FRAME;
 }
 
+if (c->ldash && !c->write_prft) {
+av_log(s, AV_LOG_INFO, "Enabling Producer Reference Time element for 
Low Latency mode\n");
+c->write_prft = 1;
+}
+
 if (c->write_prft && !c->utc_timing_url) {
 av_log(s, AV_LOG_WARNING, "Producer Reference Time element option will 
be ignored as utc_timing_url is not set\n");
 c->write_prft = 0;
-- 
2.25.0

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

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

Re: [FFmpeg-devel] [PATCH, v2 2/4] avc/avcodec: add AV_CODEC_CAP_VARIABLE_DIMENSIONS flag

[Anton Khirnov]

Quoting Fu, Linjie (2020-02-18 16:06:10)
> > Is there even a sufficiently strong use case for this? Why not just
> 
> Like transcoding reinit-large_420_8-to-small_420_8.h264 (from 352x288 to 
> 240x196)
> and prefer to keep the resolution changing in the output stream. 
> 
> IMHO not modifying the resolution unless it's required by user is kind of 
> natural.
> 
> > create a new encoder instance?
> 
> Would you please help to elaborate more about "create a new encoder instance?"
> 
> What I intended to do is to flush and close the encoder when resolution 
> changing,
> and reinit/recreate a new one.

Yes, that's what I mean. Flush and destroy an AVCodecContext and open a
new one. But then why is there a need for this flag?

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

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

Re: [FFmpeg-devel] [PATCH 1/6] avformat/format: add av_demuxer_find_by_ext

[Andreas Rheinhardt]

Anton Khirnov:
> Quoting Andreas Rheinhardt (2020-02-18 16:01:00)
>> Anton Khirnov:
>>> Quoting Gyan Doshi (2020-02-01 06:15:30)


 On 31-01-2020 10:41 pm, Andreas Rheinhardt wrote:
> Gyan Doshi:
>> Allows selecting demuxer by extension which are more widely recognized
>> by users.
>>
>> Conditional cast added since this function will usually be called after
>> av_find_input_format, and so matches its return type.
> That's not a good point. av_demuxer_find_by_ext() already always
> returns const AVInputFormat *, so you casting the const away when
> returning is pointless. Furthermore, any caller that wants to use this
> new function can simply use a pointer to const AVInputFormat to work
> with both av_find_input_format() and av_demuxer_find_by_ext(). And
> after all, adding const makes the code more future-proof
> (av_find_input_format() will return const AVInputFormat * after the
> next major bump).

 Ok, I don't think I should add const to the pointers at the receiving 
 end (fftools) since they are global variables and may not be acceptable 
 as const. So I'll cast away the const when receiving and remove the 
 conditional cast.
>>>
>>> Why not? Nothing can conceivably modify the content of those structs, so
>>> simply adding const to all their uses should work.
>>>
>> Then avformat_open_input() would have to be modified to accept a const
>> AVInputFormat *, otherwise one would get compiler warnings. And then
>> one would have to cast the const away in avformat_open_input() (should
>> probably already have been made in 3aa6208d to allow users to write
>> future-proof-code).
> 
> It's already been modified to be const on the next bump, so the warning
> would only be temporary. And we are planning to do a bump pretty soon
> IIUC.

The intention is to allow users to write future-proof code now. And
also to test whether further changes are necessary (e.g. to the
av_opt-API).
> 
> And I'm not sure if changing a function parameter from pointer to
> pointer-to-const is actually an API break. It's merely an extra
> constraint on what a function is allowed to do.
> 
Adding const to avformat_open_input() would be both API- as well as
ABI-compatible (that's also why I said that it should already have
been done in 3aa6208d).

> And besides, those structs are actually constant. They must not be
> modified from the outside. So compiler warnings would be entirely
> appropriate to remind us about invalid code.
> 
I agree. (E.g. I have proposed [1] to make avio_enum_protocols()
const-correct.)

- Andreas

[1]: https://ffmpeg.org/pipermail/ffmpeg-devel/2019-August/248675.html
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [PATCH 1/6] avformat/format: add av_demuxer_find_by_ext

[Gyan Doshi]

On 18-02-2020 10:22 pm, Andreas Rheinhardt wrote:

Anton Khirnov:

Quoting Andreas Rheinhardt (2020-02-18 16:01:00)

Anton Khirnov:

Quoting Gyan Doshi (2020-02-01 06:15:30)


On 31-01-2020 10:41 pm, Andreas Rheinhardt wrote:

Gyan Doshi:

Allows selecting demuxer by extension which are more widely recognized
by users.

Conditional cast added since this function will usually be called after
av_find_input_format, and so matches its return type.

That's not a good point. av_demuxer_find_by_ext() already always
returns const AVInputFormat *, so you casting the const away when
returning is pointless. Furthermore, any caller that wants to use this
new function can simply use a pointer to const AVInputFormat to work
with both av_find_input_format() and av_demuxer_find_by_ext(). And
after all, adding const makes the code more future-proof
(av_find_input_format() will return const AVInputFormat * after the
next major bump).

Ok, I don't think I should add const to the pointers at the receiving
end (fftools) since they are global variables and may not be acceptable
as const. So I'll cast away the const when receiving and remove the
conditional cast.

Why not? Nothing can conceivably modify the content of those structs, so
simply adding const to all their uses should work.


Then avformat_open_input() would have to be modified to accept a const
AVInputFormat *, otherwise one would get compiler warnings. And then
one would have to cast the const away in avformat_open_input() (should
probably already have been made in 3aa6208d to allow users to write
future-proof-code).

It's already been modified to be const on the next bump, so the warning
would only be temporary. And we are planning to do a bump pretty soon
IIUC.

The intention is to allow users to write future-proof code now. And
also to test whether further changes are necessary (e.g. to the
av_opt-API).

And I'm not sure if changing a function parameter from pointer to
pointer-to-const is actually an API break. It's merely an extra
constraint on what a function is allowed to do.


Adding const to avformat_open_input() would be both API- as well as
ABI-compatible (that's also why I said that it should already have
been done in 3aa6208d).


And besides, those structs are actually constant. They must not be
modified from the outside. So compiler warnings would be entirely
appropriate to remind us about invalid code.


I agree. (E.g. I have proposed [1] to make avio_enum_protocols()
const-correct.)


Since the major bump is meant to be soon, I'll just wait till then.

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 1/6] avformat/format: add av_demuxer_find_by_ext

[Anton Khirnov]

Quoting Andreas Rheinhardt (2020-02-18 17:52:00)
> Anton Khirnov:
> > Quoting Andreas Rheinhardt (2020-02-18 16:01:00)
> >> Anton Khirnov:
> >>> Quoting Gyan Doshi (2020-02-01 06:15:30)
> 
> 
>  On 31-01-2020 10:41 pm, Andreas Rheinhardt wrote:
> > Gyan Doshi:
> >> Allows selecting demuxer by extension which are more widely recognized
> >> by users.
> >>
> >> Conditional cast added since this function will usually be called after
> >> av_find_input_format, and so matches its return type.
> > That's not a good point. av_demuxer_find_by_ext() already always
> > returns const AVInputFormat *, so you casting the const away when
> > returning is pointless. Furthermore, any caller that wants to use this
> > new function can simply use a pointer to const AVInputFormat to work
> > with both av_find_input_format() and av_demuxer_find_by_ext(). And
> > after all, adding const makes the code more future-proof
> > (av_find_input_format() will return const AVInputFormat * after the
> > next major bump).
> 
>  Ok, I don't think I should add const to the pointers at the receiving 
>  end (fftools) since they are global variables and may not be acceptable 
>  as const. So I'll cast away the const when receiving and remove the 
>  conditional cast.
> >>>
> >>> Why not? Nothing can conceivably modify the content of those structs, so
> >>> simply adding const to all their uses should work.
> >>>
> >> Then avformat_open_input() would have to be modified to accept a const
> >> AVInputFormat *, otherwise one would get compiler warnings. And then
> >> one would have to cast the const away in avformat_open_input() (should
> >> probably already have been made in 3aa6208d to allow users to write
> >> future-proof-code).
> > 
> > It's already been modified to be const on the next bump, so the warning
> > would only be temporary. And we are planning to do a bump pretty soon
> > IIUC.
> 
> The intention is to allow users to write future-proof code now. And
> also to test whether further changes are necessary (e.g. to the
> av_opt-API).
> > 
> > And I'm not sure if changing a function parameter from pointer to
> > pointer-to-const is actually an API break. It's merely an extra
> > constraint on what a function is allowed to do.
> > 
> Adding const to avformat_open_input() would be both API- as well as
> ABI-compatible (that's also why I said that it should already have
> been done in 3aa6208d).
> 
> > And besides, those structs are actually constant. They must not be
> > modified from the outside. So compiler warnings would be entirely
> > appropriate to remind us about invalid code.
> > 
> I agree. (E.g. I have proposed [1] to make avio_enum_protocols()
> const-correct.)

Hmm, then it's not clear to me what from my original email did you
disagree with. My point was that any changes to fftools can be done
right now in a very straightforward manner. It will add new compiler
warnings, but that's a good thing since the current code is already
suspect and SHOULD trigger warnings.

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

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

Re: [FFmpeg-devel] [PATCH 1/6] avformat/format: add av_demuxer_find_by_ext

[Andreas Rheinhardt]

Anton Khirnov:
> Quoting Andreas Rheinhardt (2020-02-18 17:52:00)
>> Anton Khirnov:
>>> Quoting Andreas Rheinhardt (2020-02-18 16:01:00)
 Anton Khirnov:
> Quoting Gyan Doshi (2020-02-01 06:15:30)
>>
>>
>> On 31-01-2020 10:41 pm, Andreas Rheinhardt wrote:
>>> Gyan Doshi:
 Allows selecting demuxer by extension which are more widely recognized
 by users.

 Conditional cast added since this function will usually be called after
 av_find_input_format, and so matches its return type.
>>> That's not a good point. av_demuxer_find_by_ext() already always
>>> returns const AVInputFormat *, so you casting the const away when
>>> returning is pointless. Furthermore, any caller that wants to use this
>>> new function can simply use a pointer to const AVInputFormat to work
>>> with both av_find_input_format() and av_demuxer_find_by_ext(). And
>>> after all, adding const makes the code more future-proof
>>> (av_find_input_format() will return const AVInputFormat * after the
>>> next major bump).
>>
>> Ok, I don't think I should add const to the pointers at the receiving 
>> end (fftools) since they are global variables and may not be acceptable 
>> as const. So I'll cast away the const when receiving and remove the 
>> conditional cast.
>
> Why not? Nothing can conceivably modify the content of those structs, so
> simply adding const to all their uses should work.
>
 Then avformat_open_input() would have to be modified to accept a const
 AVInputFormat *, otherwise one would get compiler warnings. And then
 one would have to cast the const away in avformat_open_input() (should
 probably already have been made in 3aa6208d to allow users to write
 future-proof-code).
>>>
>>> It's already been modified to be const on the next bump, so the warning
>>> would only be temporary. And we are planning to do a bump pretty soon
>>> IIUC.
>>
>> The intention is to allow users to write future-proof code now. And
>> also to test whether further changes are necessary (e.g. to the
>> av_opt-API).
>>>
>>> And I'm not sure if changing a function parameter from pointer to
>>> pointer-to-const is actually an API break. It's merely an extra
>>> constraint on what a function is allowed to do.
>>>
>> Adding const to avformat_open_input() would be both API- as well as
>> ABI-compatible (that's also why I said that it should already have
>> been done in 3aa6208d).
>>
>>> And besides, those structs are actually constant. They must not be
>>> modified from the outside. So compiler warnings would be entirely
>>> appropriate to remind us about invalid code.
>>>
>> I agree. (E.g. I have proposed [1] to make avio_enum_protocols()
>> const-correct.)
> 
> Hmm, then it's not clear to me what from my original email did you
> disagree with. My point was that any changes to fftools can be done
> right now in a very straightforward manner. It will add new compiler
> warnings, but that's a good thing since the current code is already
> suspect and SHOULD trigger warnings.
> 
I do not really disagree with you; I actually wanted to suggest to
bring forward the changes to avformat_open_input() in order not to
trigger new compiler warnings and to allow users to write future-proof
code now.

- 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] Update HDR10+ metadata structure.

[Mohammad Izadi]

Hello,

What's the status of the cl review? Is it good to submit?
--
Best,
Mohammad


On Mon, Feb 10, 2020 at 11:44 AM Mohammad Izadi  wrote:

> From: Mohammad Izadi 
>
> Trying to read HDR10+ metadata from HEVC/SEI and pass it to packet side
> data in the follow-up CLs.
> ---
>  libavutil/hdr_dynamic_metadata.c | 165 +++
>  libavutil/hdr_dynamic_metadata.h |  13 ++-
>  libavutil/version.h  |   2 +-
>  3 files changed, 178 insertions(+), 2 deletions(-)
>
> diff --git a/libavutil/hdr_dynamic_metadata.c
> b/libavutil/hdr_dynamic_metadata.c
> index 0fa1ee82de..f24bcb40f5 100644
> --- a/libavutil/hdr_dynamic_metadata.c
> +++ b/libavutil/hdr_dynamic_metadata.c
> @@ -19,8 +19,17 @@
>   */
>
>  #include "hdr_dynamic_metadata.h"
> +#include "libavcodec/get_bits.h"
>  #include "mem.h"
>
> +static const int32_t luminance_den = 1;
> +static const int32_t peak_luminance_den = 15;
> +static const int32_t rgb_den = 10;
> +static const int32_t fraction_pixel_den = 1000;
> +static const int32_t knee_point_den = 4095;
> +static const int32_t bezier_anchor_den = 1023;
> +static const int32_t saturation_weight_den = 8;
> +
>  AVDynamicHDRPlus *av_dynamic_hdr_plus_alloc(size_t *size)
>  {
>  AVDynamicHDRPlus *hdr_plus = av_mallocz(sizeof(AVDynamicHDRPlus));
> @@ -45,3 +54,159 @@ AVDynamicHDRPlus
> *av_dynamic_hdr_plus_create_side_data(AVFrame *frame)
>
>  return (AVDynamicHDRPlus *)side_data->data;
>  }
> +
> +int av_dynamic_hdr_plus_decode(const uint8_t *data, size_t size,
> +  AVDynamicHDRPlus *s)
> +{
> +int w, i, j;
> +GetBitContext gb;
> +if (!data)
> +return AVERROR_INVALIDDATA;
> +
> +int ret = init_get_bits8(&gb, data, size);
> +if (ret < 0)
> +return AVERROR_INVALIDDATA;
> +
> +if (get_bits_left(&gb) < 2)
> +return AVERROR_INVALIDDATA;
> +s->num_windows = get_bits(&gb, 2);
> +
> +if (s->num_windows < 1 || s->num_windows > 3)
> +return AVERROR_INVALIDDATA;
> +
> +if (get_bits_left(&gb) < ((19 * 8 + 1) * (s->num_windows - 1)))
> +return AVERROR_INVALIDDATA;
> +for (w = 1; w < s->num_windows; w++) {
> +s->params[w].window_upper_left_corner_x.num = get_bits(&gb, 16);
> +s->params[w].window_upper_left_corner_y.num = get_bits(&gb, 16);
> +s->params[w].window_lower_right_corner_x.num = get_bits(&gb, 16);
> +s->params[w].window_lower_right_corner_y.num = get_bits(&gb, 16);
> +// The corners are set to absolute coordinates here. They should
> be
> +// converted to the relative coordinates (in [0, 1]) in the
> decoder.
> +s->params[w].window_upper_left_corner_x.den = 1;
> +s->params[w].window_upper_left_corner_y.den = 1;
> +s->params[w].window_lower_right_corner_x.den = 1;
> +s->params[w].window_lower_right_corner_y.den = 1;
> +
> +s->params[w].center_of_ellipse_x = get_bits(&gb, 16);
> +s->params[w].center_of_ellipse_y = get_bits(&gb, 16);
> +s->params[w].rotation_angle = get_bits(&gb, 8);
> +s->params[w].semimajor_axis_internal_ellipse = get_bits(&gb, 16);
> +s->params[w].semimajor_axis_external_ellipse = get_bits(&gb, 16);
> +s->params[w].semiminor_axis_external_ellipse = get_bits(&gb, 16);
> +s->params[w].overlap_process_option = get_bits1(&gb);
> +}
> +
> +if (get_bits_left(&gb) < 28)
> +return AVERROR_INVALIDDATA;
> +s->targeted_system_display_maximum_luminance.num = get_bits(&gb, 27);
> +s->targeted_system_display_maximum_luminance.den = luminance_den;
> +s->targeted_system_display_actual_peak_luminance_flag =
> get_bits1(&gb);
> +
> +if (s->targeted_system_display_actual_peak_luminance_flag) {
> +int rows, cols;
> +if (get_bits_left(&gb) < 10)
> +return AVERROR_INVALIDDATA;
> +rows = get_bits(&gb, 5);
> +cols = get_bits(&gb, 5);
> +if (((rows < 2) || (rows > 25)) || ((cols < 2) || (cols > 25)))
> +return AVERROR_INVALIDDATA;
> +
> +s->num_rows_targeted_system_display_actual_peak_luminance = rows;
> +s->num_cols_targeted_system_display_actual_peak_luminance = cols;
> +
> +if (get_bits_left(&gb) < (rows * cols * 4))
> +return AVERROR_INVALIDDATA;
> +
> +for (i = 0; i < rows; i++) {
> +for (j = 0; j < cols; j++) {
> +
> s->targeted_system_display_actual_peak_luminance[i][j].num = get_bits(&gb,
> 4);
> +
> s->targeted_system_display_actual_peak_luminance[i][j].den =
> peak_luminance_den;
> +}
> +}
> +}
> +for (w = 0; w < s->num_windows; w++) {
> +if (get_bits_left(&gb) < (3 * 17 + 17 + 4))
> +return AVERROR_INVALIDDATA;
> +for (i = 0; i < 3; i++) {
> +s->params[w].maxscl[i].num = get_bits(&gb, 17);
> +s->params[w].maxscl[i].den = rgb_den;
> +}
> +s->params[w].average_maxrgb.num = get_bits(

Re: [FFmpeg-devel] dvbsub.c, change segment order to be in line with spec

[Andriy Gelman]

On Tue, 18. Feb 11:27, Alen Vrečko wrote:
> On https://patchwork.ffmpeg.org/project/ffmpeg/list/ the new patch doesn't 
> show up. I used the same filename as before.
> 
> Just in case sending it again with changed filename (and also changed commit 
> message).
> 

Hello Alen,

New patches are ignored by patchwork if the subject line contains "Re:"

I removed the prefix and added a "v2". The link to your updated patch is
https://patchwork.ffmpeg.org/project/ffmpeg/patch/1901993192.202425.1582021627225.javamail.zim...@fora.si/

In the future, you could use git send-email which properly formats the patch.
(you could always test by addressing the patch to yourself)

Also try to avoid top-posting :) It makes the email thread more difficult to
follow.

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] Setting default G0 character set for teletext decoder

[Marton Balint]

On Tue, 18 Feb 2020, k.savkov wrote:

Some providers don't send info about character set, so default (latin) is 
used when decoding. I added option to force desired language with function 
vbi_teletext_set_default_region. You can see what character set code maps to 
what language in Table 32 ETS 300 706,  Section 15.


docs/decoders.texi update is missing.

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 001/244] Add a new channel layout API

[Anton Khirnov]

Quoting Marton Balint (2020-02-05 19:55:24)
> 
> 
> On Tue, 7 Jan 2020, Anton Khirnov wrote:
> 
> > Quoting Nicolas George (2019-12-31 16:17:49)
> >> Anton Khirnov (12019-12-29):
> 
> >> > I do not agree. Duplicated channels in a layout are expected to be a
> >> > fringe thing and how you handle them highly depends on the specific use
> >> > case. I expect a typical caller will want to disregard that possibility
> >> > and just take the first channel of each semantics.
> >> > So I do not believe a dedicated function for this makes sense. We could
> >> > always add something later though, if it turns out to be necessary.
> >> 
> >> I think you are making a mistake. I think that as soon as it will be
> >> technically possible, we will see cases with duplicated channels. And I
> >> know that some filters will do exactly that as soon as they are ported
> >> to this new API.
> 
> Quicktime also allows duplicated channels in a single audio track, this is 
> unfortunately a commonly used feature. So if a new API is introduced to 
> overcome the limitations of the existing one, supporting this should be 
> seriously considered.

Can you provide a link to more information about this? I'd like to know
the specifics about how it's handled by quicktime. And do note that this
API does have some ammount of support for duplicated channels (though I
still consider streams containing them to be broken).

-- 
Anton Khirnov
___
ffmpeg-devel mailing list
ffmpeg-devel@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] crash fixed: live stream.

[Andriy Gelman]

On Tue, 18. Feb 18:52, Mostafa Namazi fard wrote:
> ---
>  libavformat/hls.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/libavformat/hls.c b/libavformat/hls.c
> index 1f58e745a7..97b1a1db52 100644
> --- a/libavformat/hls.c
> +++ b/libavformat/hls.c
> @@ -2110,7 +2110,7 @@ static int hls_read_packet(AVFormatContext *s,
> AVPacket *pkt)
>  /* Make sure we've got one buffered packet from each open playlist
>   * stream */
>  if (pls->needed && !pls->pkt.data) {
> -while (1) {
> +while (pls->ctx) {
>  int64_t ts_diff;
>  AVRational tb;
>  ret = av_read_frame(pls->ctx, &pls->pkt);

Hello Mostafa, 

It looks that your inlined version doesn't apply with git am. If
you simply paste in the patch, your email client may corrupt it.

I recommend to use git send-email which handles the formatting.

If you have a gmail account and want to use it with git send-email, then follow
the steps at the end of this page (in the examples section) 
http://web.mit.edu/git/www/git-send-email.html

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

[FFmpeg-devel] build/fate fail

[ffmpeg . patchworks]

Hello, 

Thank you for submitting a patch to ffmpeg-devel.
 
An error occurred during an automated build/fate test. Please review the 
following link for more details:
https://patchwork.ffmpeg.org/project/ffmpeg/patch/cagsmwna53lfupmnavgiax9waoysvhcyacsqi7mfcrvcgszy...@mail.gmail.com/

Thank you, 
ffmpeg-devel
___
ffmpeg-devel mailing list
ffmpeg-devel@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 001/244] Add a new channel layout API

[Marton Balint]

On Tue, 18 Feb 2020, Anton Khirnov wrote:


Quoting Marton Balint (2020-02-05 19:55:24)



On Tue, 7 Jan 2020, Anton Khirnov wrote:

> Quoting Nicolas George (2019-12-31 16:17:49)
>> Anton Khirnov (12019-12-29):

>> > I do not agree. Duplicated channels in a layout are expected to be a
>> > fringe thing and how you handle them highly depends on the specific use
>> > case. I expect a typical caller will want to disregard that possibility
>> > and just take the first channel of each semantics.
>> > So I do not believe a dedicated function for this makes sense. We could
>> > always add something later though, if it turns out to be necessary.
>> 
>> I think you are making a mistake. I think that as soon as it will be

>> technically possible, we will see cases with duplicated channels. And I
>> know that some filters will do exactly that as soon as they are ported
>> to this new API.

Quicktime also allows duplicated channels in a single audio track, this is 
unfortunately a commonly used feature. So if a new API is introduced to 
overcome the limitations of the existing one, supporting this should be 
seriously considered.


Can you provide a link to more information about this? I'd like to know
the specifics about how it's handled by quicktime. And do note that this
API does have some ammount of support for duplicated channels (though I
still consider streams containing them to be broken).


The 'chan' atom can hold this information:

https://developer.apple.com/library/archive/documentation/QuickTime/QTFF/QTFFChap3/qtff3.html#//apple_ref/doc/uid/TP4939-CH205-SW53

It holds an AudioChannelLayout structure as defined in CoreAudioTypes.h:

https://developer.apple.com/documentation/coreaudiotypes/audiochannellayout
https://github.com/phracker/MacOSX-SDKs/blob/master/MacOSX10.15.sdk/System/Library/Frameworks/CoreAudioTypes.framework/Versions/A/Headers/CoreAudioBaseTypes.h#L1353

Which can hold an AudioChannelDescription array of channel descriptions 
for each channel:


https://developer.apple.com/documentation/coreaudiotypes/audiochannellayout
https://github.com/phracker/MacOSX-SDKs/blob/master/MacOSX10.15.sdk/System/Library/Frameworks/CoreAudioTypes.framework/Versions/A/Headers/CoreAudioBaseTypes.h#L1335

Which can signal the same AudioChannelLabel for every channel in a track 
if needed.


There is some support for it in libavformat/mov_chan.c.

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] donotapply: Test automated email for build fail

[Andriy Gelman]

From: Andriy Gelman 

---
 libavformat/libzmq.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavformat/libzmq.c b/libavformat/libzmq.c
index 8c8b294c921..7d9b13ad64c 100644
--- a/libavformat/libzmq.c
+++ b/libavformat/libzmq.c
@@ -159,7 +159,7 @@ static int zmq_proto_write(URLContext *h, const unsigned 
char *buf, int size)
 static int zmq_proto_read(URLContext *h, unsigned char *buf, int size)
 {
 int ret;
-ZMQContext *s = h->priv_data;
+AMQContext *s = h->priv_data;
 
 ret = zmq_proto_wait_timeout(h, s->socket, 0, h->rw_timeout, 
&h->interrupt_callback);
 if (ret)
-- 
2.25.0

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

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

Re: [FFmpeg-devel] build/fate fail

[Patchwork]

Hello, 

Thank you for submitting a patch to ffmpeg-devel.
 
An error occurred during an automated build/fate test. Please review the 
following link for more details:
https://patchwork.ffmpeg.org/project/ffmpeg/patch/20200218224926.23103-1-andriy.gel...@gmail.com/

Thank you, 
ffmpeg-devel
___
ffmpeg-devel mailing list
ffmpeg-devel@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] build/fate fail

[Lou Logan]

On Tue, Feb 18, 2020, at 2:00 PM, Patchwork wrote:
> Hello, 
> 
> Thank you for submitting a patch to ffmpeg-devel.
>  
> An error occurred during an automated build/fate test. Please review 
> the following link for more details:
> https://patchwork.ffmpeg.org/project/ffmpeg/patch/20200218224926.23103-1-andriy.gel...@gmail.com/
> 
> Thank you, 
> ffmpeg-devel

What is this message from?

Perhaps these messages should be sent to the patch author only. Otherwise it 
may create too much noise on ffmpeg-devel.
___
ffmpeg-devel mailing list
ffmpeg-devel@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] FFmpeg dev work

[Ryan Gilligan]

Hi,

I'm looking for a quote for some dev work involving FFmpeg. If anyone
thinks they can help with this, please let me know. Happy to connect you
with my lead developer to clarify anything and provide more details.

Looking for the following:


   1. Turning FFmpeg into a DLL that can run on Android and iOS. Must be
   able to be imported into Unity to be used in a mobile app for Android and
   iOS.
   2. A working example of live streaming from one device to another over
   local wifi. Mac/PC as server and Android/iOS as client - using TCP as
   protocol. Also showcase what parameters can be adjusted, what those
   parameters do, and how to adjust them.

Bonus:

   1. Working example of live streaming the desktop from Mac/PC.
   2. The above working examples directly running in Unity.


Thank you!
Ryan
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

[FFmpeg-devel] [PATCH 3/4] avcodec/svq1dec: Check that there is data left after the hader

[Michael Niedermayer]

Fixes: Timeout (21sec -> 255ms)
Fixes: 
20709/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_SVQ1_fuzzer-5085075089915904

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

diff --git a/libavcodec/svq1dec.c b/libavcodec/svq1dec.c
index d3e60c3a4a..b61ae348d2 100644
--- a/libavcodec/svq1dec.c
+++ b/libavcodec/svq1dec.c
@@ -602,6 +602,8 @@ static int svq1_decode_frame_header(AVCodecContext *avctx, 
AVFrame *frame)
 if (skip_1stop_8data_bits(bitbuf) < 0)
 return AVERROR_INVALIDDATA;
 }
+if (get_bits_left(bitbuf) <= 0)
+return AVERROR_INVALIDDATA;
 
 s->width  = width;
 s->height = height;
-- 
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/4] avcodec/qdm2: Check fft_coefs_index

[Michael Niedermayer]

Fixes: out of array access
Fixes: 
20660/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_QDM2_fuzzer-5658290216501248

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

diff --git a/libavcodec/qdm2.c b/libavcodec/qdm2.c
index 7b9d50b234..657b2da64d 100644
--- a/libavcodec/qdm2.c
+++ b/libavcodec/qdm2.c
@@ -1334,6 +1334,9 @@ static void qdm2_fft_decode_tones(QDM2Context *q, int 
duration,
 if (q->frequency_range > (local_int_14 + 1)) {
 int sub_packet = (local_int_20 + local_int_28);
 
+if (q->fft_coefs_index + stereo >= FF_ARRAY_ELEMS(q->fft_coefs))
+return;
+
 qdm2_fft_init_coefficient(q, sub_packet, offset, duration,
   channel, exp, phase);
 if (stereo)
-- 
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/4] libavcodec/svq: Remove ff_svq1_packet_checksum()

[Michael Niedermayer]

Signed-off-by: Michael Niedermayer 
---
 libavcodec/Makefile  |  4 +--
 libavcodec/svq1.h|  3 --
 libavcodec/svq13.c   | 69 
 libavcodec/svq1dec.c |  6 ++--
 libavcodec/svq3.c|  5 +++-
 5 files changed, 9 insertions(+), 78 deletions(-)
 delete mode 100644 libavcodec/svq13.c

diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index 46da42570f..71eeb60901 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -610,10 +610,10 @@ OBJS-$(CONFIG_SUNRAST_ENCODER) += sunrastenc.o
 OBJS-$(CONFIG_LIBRSVG_DECODER) += librsvgdec.o
 OBJS-$(CONFIG_SBC_DECODER) += sbcdec.o sbcdec_data.o sbc.o
 OBJS-$(CONFIG_SBC_ENCODER) += sbcenc.o sbc.o sbcdsp.o sbcdsp_data.o
-OBJS-$(CONFIG_SVQ1_DECODER)+= svq1dec.o svq1.o svq13.o h263data.o
+OBJS-$(CONFIG_SVQ1_DECODER)+= svq1dec.o svq1.o h263data.o
 OBJS-$(CONFIG_SVQ1_ENCODER)+= svq1enc.o svq1.o  h263data.o  \
   h263.o ituh263enc.o
-OBJS-$(CONFIG_SVQ3_DECODER)+= svq3.o svq13.o mpegutils.o h264data.o
+OBJS-$(CONFIG_SVQ3_DECODER)+= svq3.o mpegutils.o h264data.o
 OBJS-$(CONFIG_TEXT_DECODER)+= textdec.o ass.o
 OBJS-$(CONFIG_TEXT_ENCODER)+= srtenc.o ass_split.o
 OBJS-$(CONFIG_TAK_DECODER) += takdec.o tak.o takdsp.o
diff --git a/libavcodec/svq1.h b/libavcodec/svq1.h
index 63c0479329..0ebc73a933 100644
--- a/libavcodec/svq1.h
+++ b/libavcodec/svq1.h
@@ -42,9 +42,6 @@
 #define SVQ1_BLOCK_INTER_4V 2
 #define SVQ1_BLOCK_INTRA3
 
-uint16_t ff_svq1_packet_checksum(const uint8_t *data,
- const int length, int value);
-
 extern const int8_t *const ff_svq1_inter_codebooks[6];
 extern const int8_t *const ff_svq1_intra_codebooks[6];
 
diff --git a/libavcodec/svq13.c b/libavcodec/svq13.c
deleted file mode 100644
index b821a446d6..00
--- a/libavcodec/svq13.c
+++ /dev/null
@@ -1,69 +0,0 @@
-/*
- * SVQ1/SVQ3 decoder common code
- *
- * This file is part of FFmpeg.
- *
- * FFmpeg is free software; you can redistribute it and/or
- * modify it under the terms of the GNU Lesser General Public
- * License as published by the Free Software Foundation; either
- * version 2.1 of the License, or (at your option) any later version.
- *
- * FFmpeg is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
- * Lesser General Public License for more details.
- *
- * You should have received a copy of the GNU Lesser General Public
- * License along with FFmpeg; if not, write to the Free Software
- * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
- */
-
-#include 
-
-#include "svq1.h"
-
-static const uint16_t checksum_table[256] = {
-0x, 0x1021, 0x2042, 0x3063, 0x4084, 0x50A5, 0x60C6, 0x70E7,
-0x8108, 0x9129, 0xA14A, 0xB16B, 0xC18C, 0xD1AD, 0xE1CE, 0xF1EF,
-0x1231, 0x0210, 0x3273, 0x2252, 0x52B5, 0x4294, 0x72F7, 0x62D6,
-0x9339, 0x8318, 0xB37B, 0xA35A, 0xD3BD, 0xC39C, 0xF3FF, 0xE3DE,
-0x2462, 0x3443, 0x0420, 0x1401, 0x64E6, 0x74C7, 0x44A4, 0x5485,
-0xA56A, 0xB54B, 0x8528, 0x9509, 0xE5EE, 0xF5CF, 0xC5AC, 0xD58D,
-0x3653, 0x2672, 0x1611, 0x0630, 0x76D7, 0x66F6, 0x5695, 0x46B4,
-0xB75B, 0xA77A, 0x9719, 0x8738, 0xF7DF, 0xE7FE, 0xD79D, 0xC7BC,
-0x48C4, 0x58E5, 0x6886, 0x78A7, 0x0840, 0x1861, 0x2802, 0x3823,
-0xC9CC, 0xD9ED, 0xE98E, 0xF9AF, 0x8948, 0x9969, 0xA90A, 0xB92B,
-0x5AF5, 0x4AD4, 0x7AB7, 0x6A96, 0x1A71, 0x0A50, 0x3A33, 0x2A12,
-0xDBFD, 0xCBDC, 0xFBBF, 0xEB9E, 0x9B79, 0x8B58, 0xBB3B, 0xAB1A,
-0x6CA6, 0x7C87, 0x4CE4, 0x5CC5, 0x2C22, 0x3C03, 0x0C60, 0x1C41,
-0xEDAE, 0xFD8F, 0xCDEC, 0xDDCD, 0xAD2A, 0xBD0B, 0x8D68, 0x9D49,
-0x7E97, 0x6EB6, 0x5ED5, 0x4EF4, 0x3E13, 0x2E32, 0x1E51, 0x0E70,
-0xFF9F, 0xEFBE, 0xDFDD, 0xCFFC, 0xBF1B, 0xAF3A, 0x9F59, 0x8F78,
-0x9188, 0x81A9, 0xB1CA, 0xA1EB, 0xD10C, 0xC12D, 0xF14E, 0xE16F,
-0x1080, 0x00A1, 0x30C2, 0x20E3, 0x5004, 0x4025, 0x7046, 0x6067,
-0x83B9, 0x9398, 0xA3FB, 0xB3DA, 0xC33D, 0xD31C, 0xE37F, 0xF35E,
-0x02B1, 0x1290, 0x22F3, 0x32D2, 0x4235, 0x5214, 0x6277, 0x7256,
-0xB5EA, 0xA5CB, 0x95A8, 0x8589, 0xF56E, 0xE54F, 0xD52C, 0xC50D,
-0x34E2, 0x24C3, 0x14A0, 0x0481, 0x7466, 0x6447, 0x5424, 0x4405,
-0xA7DB, 0xB7FA, 0x8799, 0x97B8, 0xE75F, 0xF77E, 0xC71D, 0xD73C,
-0x26D3, 0x36F2, 0x0691, 0x16B0, 0x6657, 0x7676, 0x4615, 0x5634,
-0xD94C, 0xC96D, 0xF90E, 0xE92F, 0x99C8, 0x89E9, 0xB98A, 0xA9AB,
-0x5844, 0x4865, 0x7806, 0x6827, 0x18C0, 0x08E1, 0x3882, 0x28A3,
-0xCB7D, 0xDB5C, 0xEB3F, 0xFB1E, 0x8BF9, 0x9BD8, 0xABBB, 0xBB9A,
-0x4A75, 0x5A54, 0x6A37, 0x7A16, 0x0AF1, 0x1AD0, 0x2AB3, 0x3A92,
-0xFD2E, 0xED0F, 0xDD6C, 0xCD4D, 0xBDAA, 0xAD8B, 0x9DE8, 0x8DC9,
-0x7C26, 0x6C07, 0x5C64, 0x4C45, 0x3CA2, 0x2C83, 0x1CE0, 0x0CC1,
-0xEF1F, 0xF

[FFmpeg-devel] [PATCH 2/4] avcodec/txd: Check for input size against the header size.

[Michael Niedermayer]

Fixes: Timeout (21sec -> 80ms)
Fixes: 
20673/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_TXD_fuzzer-5177453863763968

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

diff --git a/libavcodec/txd.c b/libavcodec/txd.c
index 8b20475d39..f00ba89e82 100644
--- a/libavcodec/txd.c
+++ b/libavcodec/txd.c
@@ -43,6 +43,9 @@ static int txd_decode_frame(AVCodecContext *avctx, void 
*data, int *got_frame,
 int i, j;
 int ret;
 
+if (avpkt->size < 88)
+return AVERROR_INVALIDDATA;
+
 ff_texturedsp_init(&dxtc);
 
 bytestream2_init(&gb, avpkt->data, avpkt->size);
-- 
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/3] lavf: add read_flush function to AVInputFormat vtable

[rcombs]

---
 libavformat/avformat.h | 6 ++
 libavformat/utils.c| 4 
 libavformat/version.h  | 4 ++--
 3 files changed, 12 insertions(+), 2 deletions(-)

diff --git a/libavformat/avformat.h b/libavformat/avformat.h
index 9b9b634ec3..1412119342 100644
--- a/libavformat/avformat.h
+++ b/libavformat/avformat.h
@@ -780,6 +780,12 @@ typedef struct AVInputFormat {
  * @see avdevice_capabilities_free() for more details.
  */
 int (*free_device_capabilities)(struct AVFormatContext *s, struct 
AVDeviceCapabilitiesQuery *caps);
+
+/**
+ * Flush demuxer-internal buffers ahead of a discontinuity in the input 
byte stream.
+ * @see avformat_flush() for more details.
+ */
+void (*read_flush)(struct AVFormatContext *s);
 } AVInputFormat;
 /**
  * @}
diff --git a/libavformat/utils.c b/libavformat/utils.c
index 123d67800b..c5fbe74c54 100644
--- a/libavformat/utils.c
+++ b/libavformat/utils.c
@@ -2611,6 +2611,10 @@ int avformat_seek_file(AVFormatContext *s, int 
stream_index, int64_t min_ts,
 int avformat_flush(AVFormatContext *s)
 {
 ff_read_frame_flush(s);
+
+if (s->iformat->read_flush)
+s->iformat->read_flush(s);
+
 return 0;
 }
 
diff --git a/libavformat/version.h b/libavformat/version.h
index 94fa57614d..741f2e30c5 100644
--- a/libavformat/version.h
+++ b/libavformat/version.h
@@ -32,8 +32,8 @@
 // Major bumping may affect Ticket5467, 5421, 5451(compatibility with Chromium)
 // Also please add any ticket numbers that you believe might be affected here
 #define LIBAVFORMAT_VERSION_MAJOR  58
-#define LIBAVFORMAT_VERSION_MINOR  38
-#define LIBAVFORMAT_VERSION_MICRO 101
+#define LIBAVFORMAT_VERSION_MINOR  39
+#define LIBAVFORMAT_VERSION_MICRO 100
 
 #define LIBAVFORMAT_VERSION_INT AV_VERSION_INT(LIBAVFORMAT_VERSION_MAJOR, \
LIBAVFORMAT_VERSION_MINOR, \
-- 
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 2/3] lavf/hlsdec: use public avformat_flush function

[rcombs]

---
 libavformat/hls.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavformat/hls.c b/libavformat/hls.c
index 1f58e745a7..8181a631b6 100644
--- a/libavformat/hls.c
+++ b/libavformat/hls.c
@@ -2295,7 +2295,7 @@ static int hls_read_seek(AVFormatContext *s, int 
stream_index,
 /* Reset the pos, to let the mpegts demuxer know we've seeked. */
 pls->pb.pos = 0;
 /* Flush the packet queue of the subdemuxer. */
-ff_read_frame_flush(pls->ctx);
+avformat_flush(pls->ctx);
 
 pls->seek_timestamp = seek_timestamp;
 pls->seek_flags = flags;
-- 
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 3/3] lavf/matroskadec: add read_flush function

[rcombs]

---
 libavformat/matroskadec.c | 23 +--
 1 file changed, 17 insertions(+), 6 deletions(-)

diff --git a/libavformat/matroskadec.c b/libavformat/matroskadec.c
index 4d7fdab99f..68e424992a 100644
--- a/libavformat/matroskadec.c
+++ b/libavformat/matroskadec.c
@@ -3703,6 +3703,21 @@ static int matroska_read_packet(AVFormatContext *s, 
AVPacket *pkt)
 return 0;
 }
 
+static void matroska_read_flush(AVFormatContext *s)
+{
+MatroskaDemuxContext *matroska = s->priv_data;
+int i;
+
+matroska_reset_status(matroska, 0, -1);
+matroska->resync_pos = -1;
+matroska_clear_queue(matroska);
+matroska->skip_to_keyframe = 0;
+matroska->done = 0;
+
+for (i = 0; i < s->nb_streams; i++)
+s->streams[i]->skip_to_keyframe = 0;
+}
+
 static int matroska_read_seek(AVFormatContext *s, int stream_index,
   int64_t timestamp, int flags)
 {
@@ -3758,12 +3773,7 @@ static int matroska_read_seek(AVFormatContext *s, int 
stream_index,
 err:
 // slightly hackish but allows proper fallback to
 // the generic seeking code.
-matroska_reset_status(matroska, 0, -1);
-matroska->resync_pos = -1;
-matroska_clear_queue(matroska);
-st->skip_to_keyframe =
-matroska->skip_to_keyframe = 0;
-matroska->done = 0;
+matroska_read_flush(s);
 return -1;
 }
 
@@ -4200,6 +4210,7 @@ AVInputFormat ff_matroska_demuxer = {
 .read_packet= matroska_read_packet,
 .read_close = matroska_read_close,
 .read_seek  = matroska_read_seek,
+.read_flush = matroska_read_flush,
 .mime_type  = "audio/webm,audio/x-matroska,video/webm,video/x-matroska"
 };
 
-- 
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 1/3] lavf: add read_flush function to AVInputFormat vtable

[James Almer]

On 2/18/2020 9:21 PM, rcombs wrote:
> ---
>  libavformat/avformat.h | 6 ++
>  libavformat/utils.c| 4 
>  libavformat/version.h  | 4 ++--
>  3 files changed, 12 insertions(+), 2 deletions(-)
> 
> diff --git a/libavformat/avformat.h b/libavformat/avformat.h
> index 9b9b634ec3..1412119342 100644
> --- a/libavformat/avformat.h
> +++ b/libavformat/avformat.h
> @@ -780,6 +780,12 @@ typedef struct AVInputFormat {
>   * @see avdevice_capabilities_free() for more details.
>   */
>  int (*free_device_capabilities)(struct AVFormatContext *s, struct 
> AVDeviceCapabilitiesQuery *caps);
> +
> +/**
> + * Flush demuxer-internal buffers ahead of a discontinuity in the input 
> byte stream.
> + * @see avformat_flush() for more details.
> + */
> +void (*read_flush)(struct AVFormatContext *s);
>  } AVInputFormat;
>  /**
>   * @}
> diff --git a/libavformat/utils.c b/libavformat/utils.c
> index 123d67800b..c5fbe74c54 100644
> --- a/libavformat/utils.c
> +++ b/libavformat/utils.c
> @@ -2611,6 +2611,10 @@ int avformat_seek_file(AVFormatContext *s, int 
> stream_index, int64_t min_ts,
>  int avformat_flush(AVFormatContext *s)
>  {
>  ff_read_frame_flush(s);
> +
> +if (s->iformat->read_flush)
> +s->iformat->read_flush(s);
> +
>  return 0;
>  }
>  
> diff --git a/libavformat/version.h b/libavformat/version.h
> index 94fa57614d..741f2e30c5 100644
> --- a/libavformat/version.h
> +++ b/libavformat/version.h
> @@ -32,8 +32,8 @@
>  // Major bumping may affect Ticket5467, 5421, 5451(compatibility with 
> Chromium)
>  // Also please add any ticket numbers that you believe might be affected here
>  #define LIBAVFORMAT_VERSION_MAJOR  58
> -#define LIBAVFORMAT_VERSION_MINOR  38
> -#define LIBAVFORMAT_VERSION_MICRO 101
> +#define LIBAVFORMAT_VERSION_MINOR  39
> +#define LIBAVFORMAT_VERSION_MICRO 100

You added a field in the non-public part of AVInputFormat, so no need to
bump lavf version.

>  
>  #define LIBAVFORMAT_VERSION_INT AV_VERSION_INT(LIBAVFORMAT_VERSION_MAJOR, \
> LIBAVFORMAT_VERSION_MINOR, \
> 

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

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

Re: [FFmpeg-devel] [PATCH 3/3] lavf/matroskadec: add read_flush function

[Andreas Rheinhardt]

rcombs:
> ---
>  libavformat/matroskadec.c | 23 +--
>  1 file changed, 17 insertions(+), 6 deletions(-)
> 
> diff --git a/libavformat/matroskadec.c b/libavformat/matroskadec.c
> index 4d7fdab99f..68e424992a 100644
> --- a/libavformat/matroskadec.c
> +++ b/libavformat/matroskadec.c
> @@ -3703,6 +3703,21 @@ static int matroska_read_packet(AVFormatContext *s, 
> AVPacket *pkt)
>  return 0;
>  }
>  
> +static void matroska_read_flush(AVFormatContext *s)
> +{
> +MatroskaDemuxContext *matroska = s->priv_data;
> +int i;
> +
> +matroska_reset_status(matroska, 0, -1);
> +matroska->resync_pos = -1;
> +matroska_clear_queue(matroska);
> +matroska->skip_to_keyframe = 0;
> +matroska->done = 0;
> +
> +for (i = 0; i < s->nb_streams; i++)

AVFormatContext.nb_streams is actually unsigned, so maybe i should be,
too? (It is nevertheless not dangerous, as it is checked that
nb_streams is in the range of int. (And strangely AVStream.index is
int, too.))

> +s->streams[i]->skip_to_keyframe = 0;
> +}
> +
>  static int matroska_read_seek(AVFormatContext *s, int stream_index,
>int64_t timestamp, int flags)
>  {
> @@ -3758,12 +3773,7 @@ static int matroska_read_seek(AVFormatContext *s, int 
> stream_index,
>  err:
>  // slightly hackish but allows proper fallback to
>  // the generic seeking code.
> -matroska_reset_status(matroska, 0, -1);
> -matroska->resync_pos = -1;
> -matroska_clear_queue(matroska);
> -st->skip_to_keyframe =
> -matroska->skip_to_keyframe = 0;
> -matroska->done = 0;

I just noticed that the resetting of the RealAudio stuff (see the loop
above) doesn't happen when falling back to the generic seeking code.
You should add code for it in matroska_read_flush().

> +matroska_read_flush(s);
>  return -1;
>  }
>  
> @@ -4200,6 +4210,7 @@ AVInputFormat ff_matroska_demuxer = {
>  .read_packet= matroska_read_packet,
>  .read_close = matroska_read_close,
>  .read_seek  = matroska_read_seek,
> +.read_flush = matroska_read_flush,
>  .mime_type  = 
> "audio/webm,audio/x-matroska,video/webm,video/x-matroska"
>  };
>  
> 

___
ffmpeg-devel mailing list
ffmpeg-devel@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] configure: unmark FDKAAC as nonfree

[rcombs]

Red Hat legal believes the FDK license to be free when using their stripped
version (https://github.com/UnitedRPMs/fdk-aac-free/releases), as the patent
clause is a no-op now that the relevant patents on that version are expired:
https://bugzilla.redhat.com/show_bug.cgi?id=1501522

Plex legal believes that the license is GPL-compatible in general:
> I see no issue under GPL here. The reference to patent licenses is advisory
> and not a limitation on use. In essence, it says, "you can get a license here
> if you want one [implicitly, if you don't, you are at your peril], but you
> may not need one because most Android hardware makers already have one that
> covers you."

There remains some disagreement over which (if any) versions of the FDK SDK
are GPL-compatible, but I see no reason for ffmpeg to assert the position that
builds linking to it and to GPL code are nonredistributable. The source is
available under a license widely understood to fulfill some definition of
"free", and the contention around it largely comes down to a technicality.
If a user or packager wants to redistribute builds with it at their own risk,
I don't believe doing so would cause harm to ffmpeg's developers or community
(in contrast with closed-source libraries like NDI and Decklink).
---
 configure | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/configure b/configure
index ab761c7183..f590f30093 100755
--- a/configure
+++ b/configure
@@ -1727,7 +1727,6 @@ EXTERNAL_LIBRARY_GPL_LIST="
 
 EXTERNAL_LIBRARY_NONFREE_LIST="
 decklink
-libfdk_aac
 openssl
 libtls
 "
@@ -1768,6 +1767,7 @@ EXTERNAL_LIBRARY_LIST="
 libdav1d
 libdc1394
 libdrm
+libfdk_aac
 libflite
 libfontconfig
 libfreetype
-- 
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] configure: unmark FDKAAC as nonfree

[Carl Eugen Hoyos]

> Am 19.02.2020 um 01:46 schrieb rcombs :
> 
> Plex legal believes that the license is GPL-compatible in general

Instead please get a comment from the fsf.

I object to this patch for the time being.

Carl Eugen

PS: This could be unrelated but please note that plex was or is a violator of 
the copyrights of the FFmpeg developers.
___
ffmpeg-devel mailing list
ffmpeg-devel@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: unmark FDKAAC as nonfree

[Carl Eugen Hoyos]

> Am 19.02.2020 um 03:00 schrieb Carl Eugen Hoyos :
> 
> PS: This could be unrelated but please note that plex was or is a violator of 
> the copyrights of the FFmpeg developers.

As reported by you...
___
ffmpeg-devel mailing list
ffmpeg-devel@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] Setting default G0 character set for teletext decoder

[Carl Eugen Hoyos]

> Am 18.02.2020 um 15:23 schrieb k.savkov :
> 
> Some providers don't send info about character set, so default (latin) is 
> used when decoding. I added option to force desired language with function 
> vbi_teletext_set_default_region.

Please remove the re-indentation from your patch (assuming there is, I cannot 
day for sure).

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

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

Re: [FFmpeg-devel] [PATCH 2/3] lavf/hlsdec: use public avformat_flush function

[Steven Liu]

> 2020年2月19日 上午8:21，rcombs  写道：
> 
> ---
> libavformat/hls.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/libavformat/hls.c b/libavformat/hls.c
> index 1f58e745a7..8181a631b6 100644
> --- a/libavformat/hls.c
> +++ b/libavformat/hls.c
> @@ -2295,7 +2295,7 @@ static int hls_read_seek(AVFormatContext *s, int 
> stream_index,
> /* Reset the pos, to let the mpegts demuxer know we've seeked. */
> pls->pb.pos = 0;
> /* Flush the packet queue of the subdemuxer. */
> -ff_read_frame_flush(pls->ctx);
> +avformat_flush(pls->ctx);
> 
> pls->seek_timestamp = seek_timestamp;
> pls->seek_flags = flags;
> -- 
> 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”.
LGTM


Thanks
Steven



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

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

Re: [FFmpeg-devel] [PATCH 2/3] libavcodec/libx264.c: refine code to extract function x264_encode_set_roi

[Guo, Yejun]

> -Original Message-
> From: Guo, Yejun
> Sent: Friday, February 14, 2020 11:32 AM
> To: ffmpeg-devel@ffmpeg.org
> Cc: Guo, Yejun 
> Subject: [PATCH 2/3] libavcodec/libx264.c: refine code to extract function
> x264_encode_set_roi
> 
> Signed-off-by: Guo, Yejun 
> ---
>  libavcodec/libx264.c | 148 
> ---
>  1 file changed, 80 insertions(+), 68 deletions(-)
> 
> diff --git a/libavcodec/libx264.c b/libavcodec/libx264.c
> index ca8f6c0..bad9351 100644
> --- a/libavcodec/libx264.c
> +++ b/libavcodec/libx264.c
> @@ -289,6 +289,83 @@ static void reconfig_encoder(AVCodecContext *ctx,
> const AVFrame *frame)
>  }
>  }
> 
> +static int x264_encode_set_roi(const AVFrame *frame, AVCodecContext *ctx,
> int bit_depth)
> +{

hi, please ignore the other two patches of this patch set, while this patch to 
refine
the code in libv264.c is valuable and ask for review, thanks.

Yejun
___
ffmpeg-devel mailing list
ffmpeg-devel@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: unmark FDKAAC as nonfree

[Jean-Baptiste Kempf]

On Wed, Feb 19, 2020, at 01:46, rcombs wrote:
> Red Hat legal believes the FDK license to be free when using their stripped
> version (https://github.com/UnitedRPMs/fdk-aac-free/releases), as the patent
> clause is a no-op now that the relevant patents on that version are expired:
> https://bugzilla.redhat.com/show_bug.cgi?id=1501522

Their version removes a large part of the encoder and soo much of the decoder:
https://cgit.freedesktop.org/~wtay/fdk-aac/commit/?h=fedora&id=8dcaebbdb5112d5930b6202a8880f89aeabb3722
to the point that this library is almost unusable:
- a worse decoder than the normal AAC one inside libavcodec. It notably does 
not even decode SBR! See [1]
- a stripped down encoder that removes sooo much, that noone has any idea of 
the quality, because never benched.

So, what's the point?

Also, I _really_ doubt that their decoder removed all the patents related to 
AAC that have not expired, and notably they have no proof for it.
The AAC list of patents is not public https://www.via-corp.com/licensing/aac/ 
and there are many other patents outside of the main pool. Notably I really 
doubt the DRC and PS part are un-patented.

So, they have done their own analysis, that they keep private and we should 
just hope they are right?
Because the argument from the linked page that is "I removed SBR decoder" and 
that is absolutely not complete. There are wayyy many more patents on AAC, 
including ones on PS and DRC (IIRC, PS is from 2004 for example, that means 
patented until 2024).

So, they removed some code and say  "we removed all patents" and we should 
believe them, without proof and analysis?
(Since when was a MPEG codec without patents???) 

> Plex legal believes that the license is GPL-compatible in general:

Plex is not a trusted legal member of the community for numerous reasons.

> builds linking to it and to GPL code are nonredistributable. The source is
> available under a license widely understood to fulfill some definition of
> "free", and the contention around it largely comes down to a technicality.
> If a user or packager wants to redistribute builds with it at their own risk,

Why even do that?

We have a decoder inside libavcodec that is good and supports a lot of AAC 
cases, we have an encoder that is not ridiculous, while not the best, but 
because some RedHat people did a version stripping everything to a point that 
it does decodes less streams than the normal decoder and an encoder whose 
quality was never tested, we should drop everything and supports that instead?

(not even discussing the fact you cannot detect which version is "free" and 
which is "non-free", nor the fact that the legal analysis from Redhat is not 
public)

So unless there is, an answer from FSF (who never answered to RedHat), a list 
of all patents from the licensors and the detail explanation from RedHat of 
what they did exactly to work-around the patents, I would say total no.


Let me suggest something else: remove fdk-aac from the codebase.
Supporting fdk-aac in the codebase just gives incentives from not improving the 
rare cases where the decoder does not work, or improving the encoder quality, 
and just is a bait for licensing violations.

Best,

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1501522#c22

-- 
Jean-Baptiste Kempf -  President
+33 672 704 734
___
ffmpeg-devel mailing list
ffmpeg-devel@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] crash fixed: live stream.

[mostafa namazi]

 Hello Andriyyou can see my patch in below link. please review that. thanks.
[FFmpeg-devel] new patch - Patchwork

| 
| 
|  | 
[FFmpeg-devel] new patch - Patchwork


 |

 |

 |



On Wednesday, February 19, 2020, 1:01:21 AM GMT+3:30, Andriy Gelman 
 wrote:  
 
 On Tue, 18. Feb 18:52, Mostafa Namazi fard wrote:
> ---
>  libavformat/hls.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/libavformat/hls.c b/libavformat/hls.c
> index 1f58e745a7..97b1a1db52 100644
> --- a/libavformat/hls.c
> +++ b/libavformat/hls.c
> @@ -2110,7 +2110,7 @@ static int hls_read_packet(AVFormatContext *s,
> AVPacket *pkt)
>          /* Make sure we've got one buffered packet from each open playlist
>          * stream */
>          if (pls->needed && !pls->pkt.data) {
> -            while (1) {
> +            while (pls->ctx) {
>                  int64_t ts_diff;
>                  AVRational tb;
>                  ret = av_read_frame(pls->ctx, &pls->pkt);

Hello Mostafa, 

It looks that your inlined version doesn't apply with git am. If
you simply paste in the patch, your email client may corrupt it.

I recommend to use git send-email which handles the formatting.

If you have a gmail account and want to use it with git send-email, then follow
the steps at the end of this page (in the examples section) 
http://web.mit.edu/git/www/git-send-email.html

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

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

Re: [FFmpeg-devel] [PATCH 3/3] avformat/dashenc: always attempt to enable prft on ldash mode

[Jeyapal, Karthick]

On 2/18/20 9:43 PM, James Almer wrote:
> Signed-off-by: James Almer 
> ---
>  libavformat/dashenc.c | 5 +
>  1 file changed, 5 insertions(+)
>
> diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c
> index b910cc22d0..045d2f4df6 100644
> --- a/libavformat/dashenc.c
> +++ b/libavformat/dashenc.c
> @@ -1395,6 +1395,11 @@ static int dash_init(AVFormatContext *s)
>  c->frag_type = FRAG_TYPE_EVERY_FRAME;
>  }
>  
> +if (c->ldash && !c->write_prft) {
> +av_log(s, AV_LOG_INFO, "Enabling Producer Reference Time element for 
> Low Latency mode\n");
> +c->write_prft = 1;
> +}
> +
PRFT elements has a significant bitrate overhead, especially in streaming mode 
when each frame is a moof fragment.
In terms of percentage of stream's bitrate this overhead will be a significant 
% for lower bitrate streams(such as audio streams).
For any application which does not need PRFT this is an unnecessary wastage of 
bits. 
Hence, I would advise against enabling PRFT without user control.

>  if (c->write_prft && !c->utc_timing_url) {
>  av_log(s, AV_LOG_WARNING, "Producer Reference Time element option 
> will be ignored as utc_timing_url is not set\n");
>  c->write_prft = 0;

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

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

Re: [FFmpeg-devel] build/fate fail

[Andriy Gelman]

On Tue, 18. Feb 14:33, Lou Logan wrote:
> On Tue, Feb 18, 2020, at 2:00 PM, Patchwork wrote:
> > Hello, 
> > 
> > Thank you for submitting a patch to ffmpeg-devel.
> >  
> > An error occurred during an automated build/fate test. Please review 
> > the following link for more details:
> > https://patchwork.ffmpeg.org/project/ffmpeg/patch/20200218224926.23103-1-andriy.gel...@gmail.com/
> > 
> > Thank you, 
> > ffmpeg-devel

> 
> What is this message from?
> 

It's from a Jenkins server that's running the build and fate tests.

> Perhaps these messages should be sent to the patch author only. Otherwise it 
> may create too much noise on ffmpeg-devel.

I'll update to only send the email to patch authors. 

-- 
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] Setting default G0 character set for teletext decoder

[k.savkov]

I can also provide sample files, for which this option is needed, where 
can I upload them?


On 18.02.2020 23:48, Marton Balint wrote:



On Tue, 18 Feb 2020, k.savkov wrote:

Some providers don't send info about character set, so default 
(latin) is used when decoding. I added option to force desired 
language with function vbi_teletext_set_default_region. You can see 
what character set code maps to what language in Table 32 ETS 300 
706,  Section 15.


docs/decoders.texi update is missing.

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".
>From 7097df262b780978fc0a5c94ac52a93031e32cc6 Mon Sep 17 00:00:00 2001
From: Kirill Savkov 
Date: Wed, 19 Feb 2020 09:44:00 +0300
Subject: [PATCH] libavcodec/libzvbi-teletext-dec.c: added option to set
 default G0 character set

Signed-off-by: Kirill Savkov 
---
 doc/decoders.texi| 4 
 libavcodec/libzvbi-teletextdec.c | 6 ++
 2 files changed, 10 insertions(+)

diff --git a/doc/decoders.texi b/doc/decoders.texi
index 9094c55e24..96931c72f9 100644
--- a/doc/decoders.texi
+++ b/doc/decoders.texi
@@ -316,6 +316,10 @@ List of teletext page numbers to decode. Pages that do not match the specified
 list are dropped. You may use the special @code{*} string to match all pages,
 or @code{subtitle} to match all subtitle pages.
 Default value is *.
+@item txt_default_region
+Set default G0 character set used for decoding, a value between 0 and 80
+(ETS 300 706, Section 15, Table 32).
+Default value is -1, don't override VBI's decoder default.
 @item txt_chop_top
 Discards the top teletext line. Default value is 1.
 @item txt_format
diff --git a/libavcodec/libzvbi-teletextdec.c b/libavcodec/libzvbi-teletextdec.c
index 3515f33924..fe6504ff8a 100644
--- a/libavcodec/libzvbi-teletextdec.c
+++ b/libavcodec/libzvbi-teletextdec.c
@@ -55,6 +55,7 @@ typedef struct TeletextContext
 {
 AVClass*class;
 char   *pgno;
+int default_region;
 int x_offset;
 int y_offset;
 int format_id; /* 0 = bitmap, 1 = text/ass, 2 = ass */
@@ -645,6 +646,10 @@ static int teletext_decode_frame(AVCodecContext *avctx, void *data, int *data_si
 if (!ctx->vbi) {
 if (!(ctx->vbi = vbi_decoder_new()))
 return AVERROR(ENOMEM);
+if (ctx->default_region != -1) {
+av_log(avctx, AV_LOG_INFO, "Setting default zvbi region to %i\n", ctx->default_region);
+vbi_teletext_set_default_region(ctx->vbi, ctx->default_region);
+}
 if (!vbi_event_handler_register(ctx->vbi, VBI_EVENT_TTX_PAGE, handler, ctx)) {
 vbi_decoder_delete(ctx->vbi);
 ctx->vbi = NULL;
@@ -792,6 +797,7 @@ static void teletext_flush(AVCodecContext *avctx)
 #define SD AV_OPT_FLAG_SUBTITLE_PARAM | AV_OPT_FLAG_DECODING_PARAM
 static const AVOption options[] = {
 {"txt_page","page numbers to decode, subtitle for subtitles, * for all", OFFSET(pgno),   AV_OPT_TYPE_STRING, {.str = "*"},  0, 0,SD},
+{"txt_default_region", "default G0 character set used for decoding", OFFSET(default_region), AV_OPT_TYPE_INT,{.i64 = -1},  -1, 80,   SD},
 {"txt_chop_top","discards the top teletext line",OFFSET(chop_top),   AV_OPT_TYPE_INT,{.i64 = 1},0, 1,SD},
 {"txt_format",  "format of the subtitles (bitmap or text or ass)",   OFFSET(format_id),  AV_OPT_TYPE_INT,{.i64 = 0},0, 2,SD,  "txt_format"},
 {"bitmap",  NULL,0,  AV_OPT_TYPE_CONST,  {.i64 = 0},0, 0,SD,  "txt_format"},
-- 
2.25.0

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

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