[FFmpeg-devel] [PATCH 1/3] movenc: use similar logic to DASH when writing bit rate to ISML

[Jan Ekström]

This way, in case of bit rate not being set, max_rate will be used
instead. This enables, for example, remuxing of MPEG-TS to ISMV+ISML
without losing general bit rate information.
---
 libavformat/movenc.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/libavformat/movenc.c b/libavformat/movenc.c
index 9af44e3..16b044a 100644
--- a/libavformat/movenc.c
+++ b/libavformat/movenc.c
@@ -3323,6 +3323,8 @@ static int mov_write_isml_manifest(AVIOContext *pb, 
MOVMuxContext *mov)
 {
 int64_t pos = avio_tell(pb);
 int i;
+int64_t manifest_bit_rate = 0;
+
 static const uint8_t uuid[] = {
 0xa5, 0xd4, 0x0b, 0x30, 0xe8, 0x14, 0x11, 0xdd,
 0xba, 0x2f, 0x08, 0x00, 0x20, 0x0c, 0x9a, 0x66
@@ -3356,9 +3358,11 @@ static int mov_write_isml_manifest(AVIOContext *pb, 
MOVMuxContext *mov)
 } else {
 continue;
 }
+
+manifest_bit_rate = track->enc->bit_rate ? track->enc->bit_rate : 
track->enc->rc_max_rate;
 avio_printf(pb, "<%s systemBitrate=\"%"PRId64"\">\n", type,
-(int64_t)track->enc->bit_rate);
-param_write_int(pb, "systemBitrate", track->enc->bit_rate);
+(int64_t)manifest_bit_rate);
+param_write_int(pb, "systemBitrate", manifest_bit_rate);
 param_write_int(pb, "trackID", track_id);
 if (track->enc->codec_type == AVMEDIA_TYPE_VIDEO) {
 if (track->enc->codec_id == AV_CODEC_ID_H264) {
-- 
2.5.0

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

[FFmpeg-devel] [PATCH 2/3] movenc: Add support for writing language codes into ISML manifests

[Jan Ekström]

Streaming servers appear to ignore all other language metadata.
---
 libavformat/movenc.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/libavformat/movenc.c b/libavformat/movenc.c
index 16b044a..11c8275 100644
--- a/libavformat/movenc.c
+++ b/libavformat/movenc.c
@@ -3351,6 +3351,9 @@ static int mov_write_isml_manifest(AVIOContext *pb, 
MOVMuxContext *mov)
  * here yet */
 int track_id = i + 1;
 
+AVStream *st = track->st;
+AVDictionaryEntry *lang = av_dict_get(st->metadata, "language", 
NULL,0);
+
 if (track->enc->codec_type == AVMEDIA_TYPE_VIDEO) {
 type = "video";
 } else if (track->enc->codec_type == AVMEDIA_TYPE_AUDIO) {
@@ -3364,6 +3367,7 @@ static int mov_write_isml_manifest(AVIOContext *pb, 
MOVMuxContext *mov)
 (int64_t)manifest_bit_rate);
 param_write_int(pb, "systemBitrate", manifest_bit_rate);
 param_write_int(pb, "trackID", track_id);
+param_write_string(pb, "systemLanguage", lang ? lang->value : "und");
 if (track->enc->codec_type == AVMEDIA_TYPE_VIDEO) {
 if (track->enc->codec_id == AV_CODEC_ID_H264) {
 uint8_t *ptr;
-- 
2.5.0

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

[FFmpeg-devel] [PATCH 3/3] movenc: simplify the 'tfxd' fragment start timestamps

[Jan Ekström]

As far as can be seen, this value is supposed to be the DTS of a
fragment in smooth streaming. Thus, don't take b-picture delay and
such into mention when calculating the start timestamp. The duration
calculation requires PTS values, so it is not touched.
---
 libavformat/movenc.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/libavformat/movenc.c b/libavformat/movenc.c
index 11c8275..77f28b0 100644
--- a/libavformat/movenc.c
+++ b/libavformat/movenc.c
@@ -3565,8 +3565,7 @@ static int mov_write_tfxd_tag(AVIOContext *pb, MOVTrack 
*track)
 avio_write(pb, uuid, sizeof(uuid));
 avio_w8(pb, 1);
 avio_wb24(pb, 0);
-avio_wb64(pb, track->start_dts + track->frag_start +
-  track->cluster[0].cts);
+avio_wb64(pb, track->start_dts + track->frag_start);
 avio_wb64(pb, track->end_pts -
   (track->cluster[0].dts + track->cluster[0].cts));
 
-- 
2.5.0

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

[FFmpeg-devel] [PATCH 0/3] Various improvements to movenc's smooth streaming support

[Jan Ekström]

Enables writing a bit rate field into the ISML manifest when bit rate is not
set but maxrate is, adds support for language codes in the smooth streaming
manifest as well as makes the tfxd timestamps be the DTS of the fragment
instead of PTS, which seems to what the the specification means by "absolute"
timestamp.

Jan Ekström (3):
  movenc: use similar logic to DASH when writing bit rate to ISML
  movenc: Add support for writing language codes into ISML manifests
  movenc: simplify the 'tfxd' fragment start timestamps

 libavformat/movenc.c | 15 +++
 1 file changed, 11 insertions(+), 4 deletions(-)

-- 
2.5.0

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

[FFmpeg-devel] [PATCH v2] pgssubdec: fix subpicture output colorspace and range

[Jan Ekström]

Functionality used before didn't widen the values from limited to
full range. Additionally, now the decoder uses BT.709 where it
should be used according to the video resolution.

Default for not yet set colorimetry is BT.709 due to most observed
HDMV content being HD.

BT.709 coefficients were gathered from the first two parts of BT.709
to BT.2020 conversion guide in ARIB STD-B62 (Pt. 1, Chapter 6.2.2).
They were additionally confirmed by manually calculating values.

Fixes #4637
---
 libavcodec/pgssubdec.c | 10 --
 libavutil/colorspace.h | 10 ++
 2 files changed, 18 insertions(+), 2 deletions(-)

diff --git a/libavcodec/pgssubdec.c b/libavcodec/pgssubdec.c
index 07a2a78..133d08b 100644
--- a/libavcodec/pgssubdec.c
+++ b/libavcodec/pgssubdec.c
@@ -354,8 +354,14 @@ static int parse_palette_segment(AVCodecContext *avctx,
 cb= bytestream_get_byte();
 alpha = bytestream_get_byte();
 
-YUV_TO_RGB1(cb, cr);
-YUV_TO_RGB2(r, g, b, y);
+/* Default to BT.709 colorimetry. In case of <= 576 height use BT.601 
*/
+if (avctx->height <= 0 || avctx->height > 576) {
+YUV_TO_RGB1_CCIR_BT709(cb, cr);
+} else {
+YUV_TO_RGB1_CCIR(cb, cr);
+}
+
+YUV_TO_RGB2_CCIR(r, g, b, y);
 
 ff_dlog(avctx, "Color %d := (%d,%d,%d,%d)\n", color_id, r, g, b, 
alpha);
 
diff --git a/libavutil/colorspace.h b/libavutil/colorspace.h
index 826ffd5..7d3f711 100644
--- a/libavutil/colorspace.h
+++ b/libavutil/colorspace.h
@@ -41,6 +41,16 @@
 b_add = FIX(1.77200*255.0/224.0) * cb + ONE_HALF;\
 }
 
+#define YUV_TO_RGB1_CCIR_BT709(cb1, cr1)\
+{\
+cb = (cb1) - 128;\
+cr = (cr1) - 128;\
+r_add = FIX(1.5747*255.0/224.0) * cr + ONE_HALF;\
+g_add = - FIX(0.1873*255.0/224.0) * cb - FIX(0.4682*255.0/224.0) * cr + \
+ONE_HALF;\
+b_add = FIX(1.8556*255.0/224.0) * cb + ONE_HALF;\
+}
+
 #define YUV_TO_RGB2_CCIR(r, g, b, y1)\
 {\
 y = ((y1) - 16) * FIX(255.0/219.0);\
-- 
2.5.5

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

[FFmpeg-devel] [PATCH] pgssubdec: fix subpicture output colorspace and range

[Jan Ekström]

Functionality used before didn't widen the values from limited to
full range. Additionally, now the decoder uses BT.709 where it
should be used according to the video resolution.

Default for not yet set colorimetry is BT.709 due to most observed
HDMV content being HD.

BT.709 coefficients were gathered from the first two parts of BT.709
to BT.2020 conversion guide in ARIB STD-B62 (Pt. 1, Chapter 6.2.2).

Based on a patch by Carl Eugen Hoyos.
---
 libavcodec/pgssubdec.c | 20 ++--
 libavutil/colorspace.h | 10 ++
 2 files changed, 28 insertions(+), 2 deletions(-)

diff --git a/libavcodec/pgssubdec.c b/libavcodec/pgssubdec.c
index 07a2a78..4145f1c 100644
--- a/libavcodec/pgssubdec.c
+++ b/libavcodec/pgssubdec.c
@@ -96,6 +96,7 @@ typedef struct PGSSubContext {
 PGSSubPalettes palettes;
 PGSSubObjects  objects;
 int forced_subs_only;
+int hdtv;
 } PGSSubContext;
 
 static void flush_cache(AVCodecContext *avctx)
@@ -136,6 +137,9 @@ static PGSSubPalette * find_palette(int id, PGSSubPalettes 
*palettes)
 
 static av_cold int init_decoder(AVCodecContext *avctx)
 {
+PGSSubContext *ctx = avctx->priv_data;
+ctx->hdtv  = -1;
+
 avctx->pix_fmt = AV_PIX_FMT_PAL8;
 
 return 0;
@@ -354,8 +358,14 @@ static int parse_palette_segment(AVCodecContext *avctx,
 cb= bytestream_get_byte();
 alpha = bytestream_get_byte();
 
-YUV_TO_RGB1(cb, cr);
-YUV_TO_RGB2(r, g, b, y);
+/* Default to HDTV (-1 or 1) */
+if (ctx->hdtv) {
+YUV_TO_RGB1_CCIR_BT709(cb, cr);
+} else {
+YUV_TO_RGB1_CCIR(cb, cr);
+}
+
+YUV_TO_RGB2_CCIR(r, g, b, y);
 
 ff_dlog(avctx, "Color %d := (%d,%d,%d,%d)\n", color_id, r, g, b, 
alpha);
 
@@ -388,6 +398,12 @@ static int parse_presentation_segment(AVCodecContext 
*avctx,
 int w = bytestream_get_be16();
 int h = bytestream_get_be16();
 
+// Set colorimetry according to resolution
+if (h > 576)
+ctx->hdtv = 1;
+else
+ctx->hdtv = 0;
+
 ctx->presentation.pts = pts;
 
 ff_dlog(avctx, "Video Dimensions %dx%d\n",
diff --git a/libavutil/colorspace.h b/libavutil/colorspace.h
index 826ffd5..7d3f711 100644
--- a/libavutil/colorspace.h
+++ b/libavutil/colorspace.h
@@ -41,6 +41,16 @@
 b_add = FIX(1.77200*255.0/224.0) * cb + ONE_HALF;\
 }
 
+#define YUV_TO_RGB1_CCIR_BT709(cb1, cr1)\
+{\
+cb = (cb1) - 128;\
+cr = (cr1) - 128;\
+r_add = FIX(1.5747*255.0/224.0) * cr + ONE_HALF;\
+g_add = - FIX(0.1873*255.0/224.0) * cb - FIX(0.4682*255.0/224.0) * cr + \
+ONE_HALF;\
+b_add = FIX(1.8556*255.0/224.0) * cb + ONE_HALF;\
+}
+
 #define YUV_TO_RGB2_CCIR(r, g, b, y1)\
 {\
 y = ((y1) - 16) * FIX(255.0/219.0);\
-- 
2.5.5

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

[FFmpeg-devel] [PATCH] movenc: add support for track names in ISML manifests

[Jan Ekström]

This enables having multiple tracks of the same type which would
be treated as different things by the media server (as opposed to
different bit rate versions of the same track). According to the
smooth streaming specification, just setting the systemLanguage
tag is not enough to note that a track with the same attributes
differs from another one.
---
 libavformat/movenc.c | 18 ++
 1 file changed, 18 insertions(+)

diff --git a/libavformat/movenc.c b/libavformat/movenc.c
index a58b6a4..a286210 100644
--- a/libavformat/movenc.c
+++ b/libavformat/movenc.c
@@ -3645,6 +3645,7 @@ static int mov_write_isml_manifest(AVIOContext *pb, 
MOVMuxContext *mov, AVFormat
 MOVTrack *track = >tracks[i];
 const char *type;
 int track_id = track->track_id;
+char track_name_buf[32] = { 0 };
 
 AVStream *st = track->st;
 AVDictionaryEntry *lang = av_dict_get(st->metadata, "language", 
NULL,0);
@@ -3670,6 +3671,23 @@ static int mov_write_isml_manifest(AVIOContext *pb, 
MOVMuxContext *mov, AVFormat
 param_write_int(pb, "systemBitrate", manifest_bit_rate);
 param_write_int(pb, "trackID", track_id);
 param_write_string(pb, "systemLanguage", lang ? lang->value : "und");
+
+/* Build track name piece by piece: */
+/* 1. track type */
+av_strlcat(track_name_buf, type, sizeof(track_name_buf));
+/* 2. track language, if available */
+if (lang)
+av_strlcatf(track_name_buf, sizeof(track_name_buf),
+"_%s", lang->value);
+/* 3. special type suffix */
+/* "_cc" = closed captions, "_ad" = audio_description */
+if (st->disposition & AV_DISPOSITION_HEARING_IMPAIRED)
+av_strlcat(track_name_buf, "_cc", sizeof(track_name_buf));
+else if (st->disposition & AV_DISPOSITION_VISUAL_IMPAIRED)
+av_strlcat(track_name_buf, "_ad", sizeof(track_name_buf));
+
+param_write_string(pb, "trackName", track_name_buf);
+
 if (track->par->codec_type == AVMEDIA_TYPE_VIDEO) {
 if (track->par->codec_id == AV_CODEC_ID_H264) {
 uint8_t *ptr;
-- 
2.9.3

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

[FFmpeg-devel] [PATCH 1/2] lavf/mxfdec: add support for all of the picture size and offset fields

[Jan Ekström]

* Renames the `width` and `height` entries to `stored_{width,height}`
  according to the specification's naming.
* Switches the data type of widths and heights to uint32_t according
  to specification, adds additional checks to make sure we don't
  overflow INT_MAX as codecpar->{width,height} are signed integers.
* Adds and parses the sampled and display width and height entries.
* Adds and parses the sampled and display X/Y offsets. These together
  with the additional widths and heights enable future support for
  container cropping if and when there will be generic tooling for
  it within FFmpeg.

Signed-off-by: Jan Ekström <jee...@gmail.com>
---
 libavformat/mxfdec.c | 60 ++--
 1 file changed, 54 insertions(+), 6 deletions(-)

diff --git a/libavformat/mxfdec.c b/libavformat/mxfdec.c
index 1939761..54fc6fb 100644
--- a/libavformat/mxfdec.c
+++ b/libavformat/mxfdec.c
@@ -170,8 +170,17 @@ typedef struct MXFDescriptor {
 UID codec_ul;
 AVRational sample_rate;
 AVRational aspect_ratio;
-int width;
-int height; /* Field height, not frame height */
+/* In case of frame_layout == SeparateFields or SegmentedFrame, height is 
of field, not frame */
+uint32_t stored_width;
+uint32_t stored_height;
+uint32_t sampled_width;
+uint32_t sampled_height;
+int32_t  sampled_x_offset;
+int32_t  sampled_y_offset;
+uint32_t display_width;
+uint32_t display_height;
+int32_t  display_x_offset;
+int32_t  display_y_offset;
 int frame_layout; /* See MXFFrameLayout enum */
 #define MXF_TFF 1
 #define MXF_BFF 2
@@ -988,10 +997,34 @@ static int mxf_read_generic_descriptor(void *arg, 
AVIOContext *pb, int tag, int
 avio_read(pb, descriptor->essence_codec_ul, 16);
 break;
 case 0x3203:
-descriptor->width = avio_rb32(pb);
+descriptor->stored_width = avio_rb32(pb);
 break;
 case 0x3202:
-descriptor->height = avio_rb32(pb);
+descriptor->stored_height = avio_rb32(pb);
+break;
+case 0x3205:
+descriptor->sampled_width = avio_rb32(pb);
+break;
+case 0x3204:
+descriptor->sampled_height = avio_rb32(pb);
+break;
+case 0x3206:
+descriptor->sampled_x_offset = avio_rb32(pb);
+break;
+case 0x3207:
+descriptor->sampled_y_offset = avio_rb32(pb);
+break;
+case 0x3209:
+descriptor->display_width = avio_rb32(pb);
+break;
+case 0x3208:
+descriptor->display_height = avio_rb32(pb);
+break;
+case 0x320A:
+descriptor->display_x_offset = avio_rb32(pb);
+break;
+case 0x320B:
+descriptor->display_y_offset = avio_rb32(pb);
 break;
 case 0x320C:
 descriptor->frame_layout = avio_r8(pb);
@@ -2027,8 +2060,16 @@ static int mxf_parse_structural_metadata(MXFContext *mxf)
 container_ul = mxf_get_codec_ul(mxf_picture_essence_container_uls, 
essence_container_ul);
 if (st->codecpar->codec_id == AV_CODEC_ID_NONE)
 st->codecpar->codec_id = container_ul->id;
-st->codecpar->width = descriptor->width;
-st->codecpar->height = descriptor->height; /* Field height, not 
frame height */
+
+if (descriptor->stored_width > INT_MAX || 
descriptor->stored_height > INT_MAX) {
+av_log(mxf->fc, AV_LOG_ERROR,
+   "One or both of the descriptor's storage width/height 
values does not fit within an integer! "
+   "(width=%"PRIu32", height=%"PRIu32")\n", 
descriptor->stored_width, descriptor->stored_height);
+ret = AVERROR(AVERROR_PATCHWELCOME);
+goto fail_and_free;
+}
+st->codecpar->width = descriptor->stored_width;
+st->codecpar->height = descriptor->stored_height; /* Field height, 
not frame height */
 switch (descriptor->frame_layout) {
 case FullFrame:
 st->codecpar->field_order = AV_FIELD_PROGRESSIVE;
@@ -2058,6 +2099,13 @@ static int mxf_parse_structural_metadata(MXFContext *mxf)
 case 0: // we already have many samples with 
field_dominance == unknown
 break;
 }
+if ((st->codecpar->height * 2) > INT_MAX) {
+av_log(mxf->fc, AV_LOG_ERROR,
+   "Field height duplicated does not fit within an 
integer! (height*2=%"PRIu64")\n",
+   ((uint64_t)st->codecpar->height) * 2);
+ret = AVERROR(AVERROR_PATCHWELCOME);
+goto fail_and_free;
+}
 /* Tur

[FFmpeg-devel] [PATCH 2/2] lavf/mxfdec: begin utilizing the newly parsed widths and heights

[Jan Ekström]

* Updates the width/height sanity check to check all values against
  INT_MAX.
* Correctly utilizes the stored width or height by default, and if
  sampled or display values are available they are utilized.

Signed-off-by: Jan Ekström <jee...@gmail.com>
---
 libavformat/mxfdec.c | 30 +++---
 1 file changed, 27 insertions(+), 3 deletions(-)

diff --git a/libavformat/mxfdec.c b/libavformat/mxfdec.c
index 54fc6fb..f90a85c 100644
--- a/libavformat/mxfdec.c
+++ b/libavformat/mxfdec.c
@@ -2061,15 +2061,39 @@ static int mxf_parse_structural_metadata(MXFContext 
*mxf)
 if (st->codecpar->codec_id == AV_CODEC_ID_NONE)
 st->codecpar->codec_id = container_ul->id;
 
-if (descriptor->stored_width > INT_MAX || 
descriptor->stored_height > INT_MAX) {
+if (descriptor->stored_width > INT_MAX || 
descriptor->stored_height > INT_MAX ||
+descriptor->sampled_width > INT_MAX || 
descriptor->sampled_height > INT_MAX ||
+descriptor->display_width > INT_MAX || 
descriptor->display_height > INT_MAX) {
 av_log(mxf->fc, AV_LOG_ERROR,
-   "One or both of the descriptor's storage width/height 
values does not fit within an integer! "
-   "(width=%"PRIu32", height=%"PRIu32")\n", 
descriptor->stored_width, descriptor->stored_height);
+   "One or more of the descriptor's storage width/height 
values does not fit within an integer:\n"
+   "(stored_width=%"PRIu32", stored_height=%"PRIu32")\n"
+   "(sampled_width=%"PRIu32", sampled_height=%"PRIu32")\n"
+   "(display_width=%"PRIu32", display_height=%"PRIu32")\n",
+   descriptor->stored_width, descriptor->stored_height,
+   descriptor->sampled_width, descriptor->sampled_height,
+   descriptor->display_width, descriptor->display_height);
 ret = AVERROR(AVERROR_PATCHWELCOME);
 goto fail_and_free;
 }
 st->codecpar->width = descriptor->stored_width;
 st->codecpar->height = descriptor->stored_height; /* Field height, 
not frame height */
+
+/*
+   Widths and heights get overridden storage->sampled->display.
+   In case of an unset value the previous value shall be used.
+*/
+if (descriptor->sampled_width)
+st->codecpar->width = descriptor->sampled_width;
+
+if (descriptor->display_width)
+st->codecpar->width = descriptor->display_width;
+
+if (descriptor->sampled_height)
+st->codecpar->height = descriptor->sampled_height;
+
+if (descriptor->display_height)
+st->codecpar->height = descriptor->display_height;
+
 switch (descriptor->frame_layout) {
 case FullFrame:
 st->codecpar->field_order = AV_FIELD_PROGRESSIVE;
-- 
2.7.4

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

[FFmpeg-devel] [PATCH 1/2 v2] movenc: use similar logic to DASH when writing bit rate to ISML

[Jan Ekström]

This way, in case of bit rate not being set, max_bitrate will be
used instead. This enables, for example, re-using max_bitrate
information from the input or doing transcoding with a rate
control mode that is not bit rate based.

Signed-off-by: Jan Ekström <jee...@gmail.com>
---
 libavformat/movenc.c | 16 ++--
 1 file changed, 14 insertions(+), 2 deletions(-)

diff --git a/libavformat/movenc.c b/libavformat/movenc.c
index 449d0b5..8992782 100644
--- a/libavformat/movenc.c
+++ b/libavformat/movenc.c
@@ -3581,6 +3581,9 @@ static int mov_write_isml_manifest(AVIOContext *pb, 
MOVMuxContext *mov, AVFormat
 {
 int64_t pos = avio_tell(pb);
 int i;
+int64_t manifest_bit_rate = 0;
+AVCPBProperties *props = NULL;
+
 static const uint8_t uuid[] = {
 0xa5, 0xd4, 0x0b, 0x30, 0xe8, 0x14, 0x11, 0xdd,
 0xba, 0x2f, 0x08, 0x00, 0x20, 0x0c, 0x9a, 0x66
@@ -3615,9 +3618,18 @@ static int mov_write_isml_manifest(AVIOContext *pb, 
MOVMuxContext *mov, AVFormat
 } else {
 continue;
 }
+
+props = (AVCPBProperties*)av_stream_get_side_data(track->st, 
AV_PKT_DATA_CPB_PROPERTIES, NULL);
+
+if (track->par->bit_rate) {
+manifest_bit_rate = track->par->bit_rate;
+} else if (props) {
+manifest_bit_rate = props->max_bitrate;
+}
+
 avio_printf(pb, "<%s systemBitrate=\"%"PRId64"\">\n", type,
-(int64_t)track->par->bit_rate);
-param_write_int(pb, "systemBitrate", track->par->bit_rate);
+manifest_bit_rate);
+param_write_int(pb, "systemBitrate", manifest_bit_rate);
 param_write_int(pb, "trackID", track_id);
 if (track->par->codec_type == AVMEDIA_TYPE_VIDEO) {
 if (track->par->codec_id == AV_CODEC_ID_H264) {
-- 
2.7.4

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

[FFmpeg-devel] [PATCH 0/2 v2] Various improvements to movenc's smooth streaming support

[Jan Ekström]

Enables writing a bit rate field into the ISML manifest when bit rate is not
set but maxrate is, adds support for language codes in the smooth streaming
manifest.

Updated to work with post-codecpar. Timestamp patch was dropped since there
is a patch available to be tested which enables the usage of negative
CTS offsets, leading to the initial sample's CTS and DTS to match. If that
patch works, smooth streaming output should rather be locked to that mode.

Jan Ekström (2):
  movenc: use similar logic to DASH when writing bit rate to ISML
  movenc: Add support for writing language codes into ISML manifests

 libavformat/movenc.c | 19 +--
 1 file changed, 17 insertions(+), 2 deletions(-)

-- 
2.7.4

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

[FFmpeg-devel] [PATCH 2/2] movenc: Add support for writing language codes into ISML manifests

[Jan Ekström]

Streaming servers appear to ignore all other language metadata.

Signed-off-by: Jan Ekström <jee...@gmail.com>
---
 libavformat/movenc.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/libavformat/movenc.c b/libavformat/movenc.c
index d5ed1dd..28edb18 100644
--- a/libavformat/movenc.c
+++ b/libavformat/movenc.c
@@ -3611,6 +3611,9 @@ static int mov_write_isml_manifest(AVIOContext *pb, 
MOVMuxContext *mov, AVFormat
 const char *type;
 int track_id = track->track_id;
 
+AVStream *st = track->st;
+AVDictionaryEntry *lang = av_dict_get(st->metadata, "language", 
NULL,0);
+
 if (track->par->codec_type == AVMEDIA_TYPE_VIDEO) {
 type = "video";
 } else if (track->par->codec_type == AVMEDIA_TYPE_AUDIO) {
@@ -3630,6 +3633,7 @@ static int mov_write_isml_manifest(AVIOContext *pb, 
MOVMuxContext *mov, AVFormat
 (int64_t)manifest_bit_rate);
 param_write_int(pb, "systemBitrate", manifest_bit_rate);
 param_write_int(pb, "trackID", track_id);
+param_write_string(pb, "systemLanguage", lang ? lang->value : "und");
 if (track->par->codec_type == AVMEDIA_TYPE_VIDEO) {
 if (track->par->codec_id == AV_CODEC_ID_H264) {
 uint8_t *ptr;
-- 
2.7.4

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

[FFmpeg-devel] [PATCH 1/2] movenc: use similar logic to DASH when writing bit rate to ISML

[Jan Ekström]

This way, in case of bit rate not being set, max_bitrate will be
used instead. This enables, for example, re-using max_bitrate
information from the input or doing transcoding with a rate
control mode that is not bit rate based.

Signed-off-by: Jan Ekström <jee...@gmail.com>
---
 libavformat/movenc.c | 15 +--
 1 file changed, 13 insertions(+), 2 deletions(-)

diff --git a/libavformat/movenc.c b/libavformat/movenc.c
index 449d0b5..d5ed1dd 100644
--- a/libavformat/movenc.c
+++ b/libavformat/movenc.c
@@ -3581,6 +3581,9 @@ static int mov_write_isml_manifest(AVIOContext *pb, 
MOVMuxContext *mov, AVFormat
 {
 int64_t pos = avio_tell(pb);
 int i;
+int64_t manifest_bit_rate = 0;
+AVCPBProperties *props = NULL;
+
 static const uint8_t uuid[] = {
 0xa5, 0xd4, 0x0b, 0x30, 0xe8, 0x14, 0x11, 0xdd,
 0xba, 0x2f, 0x08, 0x00, 0x20, 0x0c, 0x9a, 0x66
@@ -3615,9 +3618,17 @@ static int mov_write_isml_manifest(AVIOContext *pb, 
MOVMuxContext *mov, AVFormat
 } else {
 continue;
 }
+
+props = (AVCPBProperties*)av_stream_get_side_data(track->st, 
AV_PKT_DATA_CPB_PROPERTIES, NULL);
+
+if (track->par->bit_rate)
+manifest_bit_rate = track->par->bit_rate;
+else if (props)
+manifest_bit_rate = props->max_bitrate;
+
 avio_printf(pb, "<%s systemBitrate=\"%"PRId64"\">\n", type,
-(int64_t)track->par->bit_rate);
-param_write_int(pb, "systemBitrate", track->par->bit_rate);
+(int64_t)manifest_bit_rate);
+param_write_int(pb, "systemBitrate", manifest_bit_rate);
 param_write_int(pb, "trackID", track_id);
 if (track->par->codec_type == AVMEDIA_TYPE_VIDEO) {
 if (track->par->codec_id == AV_CODEC_ID_H264) {
-- 
2.7.4

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

[FFmpeg-devel] [RFC] Removal of the "x264opts" libx264 wrapper AVOption

[Jan Ekström]

Hi,

I am not sure what the correct order of things to remove an AVOption is,
but I would like to propose that the "x264opts" AVOption be removed, as it
duplicates "x264-params", which has a matching pair over at the libx265
wrapper.

Also, this way we would get rid of one in a group of similar features we
have a duplicate of in our code base.

Jan Ekström (2):
  libx264: remove the "x264opts" AVOption
  doc/encoders: remove mentions of the x264opts AVOption

 doc/encoders.texi| 25 ++---
 libavcodec/libx264.c | 29 -
 2 files changed, 6 insertions(+), 48 deletions(-)

-- 
2.9.3

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

[FFmpeg-devel] [PATCH 2/2] doc/encoders: remove mentions of the x264opts AVOption

[Jan Ekström]

---
 doc/encoders.texi | 25 ++---
 1 file changed, 6 insertions(+), 19 deletions(-)

diff --git a/doc/encoders.texi b/doc/encoders.texi
index 594c612..ee28b9b 100644
--- a/doc/encoders.texi
+++ b/doc/encoders.texi
@@ -1762,9 +1762,9 @@ for detail retention (adaptive quantization, psy-RD, 
psy-trellis).
 
 Many libx264 encoder options are mapped to FFmpeg global codec
 options, while unique encoder options are provided through private
-options. Additionally the @option{x264opts} and @option{x264-params}
-private options allows one to pass a list of key=value tuples as accepted
-by the libx264 @code{x264_param_parse} function.
+options. Additionally the @option{x264-params} private option allows one
+to pass a list of key=value tuples as accepted by the libx264
+@code{x264_param_parse} function.
 
 The x264 project website is at
 @url{http://www.videolan.org/developers/x264.html}.
@@ -2094,19 +2094,6 @@ Variable bit rate.
 Constant bit rate (not allowed in MP4 container).
 @end table
 
-@item x264opts (N.A.)
-Set any x264 option, see @command{x264 --fullhelp} for a list.
-
-Argument is a list of @var{key}=@var{value} couples separated by
-":". In @var{filter} and @var{psy-rd} options that use ":" as a separator
-themselves, use "," instead. They accept it as well since long ago but this
-is kept undocumented for some reason.
-
-For example to specify libx264 encoding options with @command{ffmpeg}:
-@example
-ffmpeg -i foo.mpg -vcodec libx264 -x264opts keyint=123:min-keyint=20 -an 
out.mkv
-@end example
-
 @item a53cc @var{boolean}
 Import closed captions (which must be ATSC compatible format) into output.
 Only the mpeg2 and h264 decoders provide these. Default is 1 (on).
@@ -2115,11 +2102,11 @@ Only the mpeg2 and h264 decoders provide these. Default 
is 1 (on).
 Override the x264 configuration using a :-separated list of key=value
 parameters.
 
-This option is functionally the same as the @option{x264opts}, but is
-duplicated for compatibility with the Libav fork.
-
 For example to specify libx264 encoding options with @command{ffmpeg}:
 @example
+ffmpeg -i foo.mpg -vcodec libx264 -x264opts keyint=123:min-keyint=20 -an 
out.mkv
+@end example
+@example
 ffmpeg -i INPUT -c:v libx264 -x264-params level=30:bframes=0:weightp=0:\
 cabac=0:ref=1:vbv-maxrate=768:vbv-bufsize=2000:analyse=all:me=umh:\
 no-fast-pskip=1:subq=6:8x8dct=0:trellis=0 OUTPUT
-- 
2.9.3

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

[FFmpeg-devel] [PATCH 1/2] libx264: remove the "x264opts" AVOption

[Jan Ekström]

x264-params does the same thing and this leaves us with a single
option that is name-matched with x265-params available in the
libx265 wrapper.
---
 libavcodec/libx264.c | 29 -
 1 file changed, 29 deletions(-)

diff --git a/libavcodec/libx264.c b/libavcodec/libx264.c
index b11ede6..5cbc376 100644
--- a/libavcodec/libx264.c
+++ b/libavcodec/libx264.c
@@ -53,7 +53,6 @@ typedef struct X264Context {
 char *level;
 int fastfirstpass;
 char *wpredp;
-char *x264opts;
 float crf;
 float crf_max;
 int cqp;
@@ -396,20 +395,6 @@ static av_cold int X264_close(AVCodecContext *avctx)
 return 0;
 }
 
-#define OPT_STR(opt, param)   \
-do {  \
-int ret;  \
-if ((ret = x264_param_parse(>params, opt, param)) < 0) { \
-if(ret == X264_PARAM_BAD_NAME)\
-av_log(avctx, AV_LOG_ERROR,   \
-"bad option '%s': '%s'\n", opt, param);   \
-else  \
-av_log(avctx, AV_LOG_ERROR,   \
-"bad value for '%s': '%s'\n", opt, param);\
-return -1;\
-} \
-} while (0)
-
 static int convert_pix_fmt(enum AVPixelFormat pix_fmt)
 {
 switch (pix_fmt) {
@@ -774,19 +759,6 @@ FF_ENABLE_DEPRECATION_WARNINGS
 if (avctx->flags & AV_CODEC_FLAG_GLOBAL_HEADER)
 x4->params.b_repeat_headers = 0;
 
-if(x4->x264opts){
-const char *p= x4->x264opts;
-while(p){
-char param[4096]={0}, val[4096]={0};
-if(sscanf(p, "%4095[^:=]=%4095[^:]", param, val) == 1){
-OPT_STR(param, "1");
-}else
-OPT_STR(param, val);
-p= strchr(p, ':');
-p+=!!p;
-}
-}
-
 if (x4->x264_params) {
 AVDictionary *dict= NULL;
 AVDictionaryEntry *en = NULL;
@@ -908,7 +880,6 @@ static const AVOption options[] = {
 {"passlogfile", "Filename for 2 pass stats", OFFSET(stats), 
AV_OPT_TYPE_STRING, {.str=NULL}, 0, 0, VE},
 {"wpredp", "Weighted prediction for P-frames", OFFSET(wpredp), 
AV_OPT_TYPE_STRING, {.str=NULL}, 0, 0, VE},
 {"a53cc",  "Use A53 Closed Captions (if available)",  
OFFSET(a53_cc),AV_OPT_TYPE_BOOL,   {.i64 = 1}, 0, 1, VE},
-{"x264opts", "x264 options", OFFSET(x264opts), AV_OPT_TYPE_STRING, 
{.str=NULL}, 0, 0, VE},
 { "crf",   "Select the quality for constant quality mode",
OFFSET(crf),   AV_OPT_TYPE_FLOAT,  {.dbl = -1 }, -1, FLT_MAX, VE },
 { "crf_max",   "In CRF mode, prevents VBV from lowering quality beyond 
this point.",OFFSET(crf_max), AV_OPT_TYPE_FLOAT, {.dbl = -1 }, -1, FLT_MAX, VE 
},
 { "qp","Constant quantization parameter rate control 
method",OFFSET(cqp),AV_OPT_TYPE_INT,{ .i64 = -1 }, -1, INT_MAX, VE 
},
-- 
2.9.3

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

[FFmpeg-devel] [PATCH 2/2] movenc-test: Add tests for negative cts offsets

[Jan Ekström]

From: Martin Storsjö 

Signed-off-by: Martin Storsjö 
---
 libavformat/tests/movenc.c | 19 +++
 tests/ref/fate/movenc  | 11 +++
 2 files changed, 30 insertions(+)

diff --git a/libavformat/tests/movenc.c b/libavformat/tests/movenc.c
index 7a66395efd..8e59b74259 100644
--- a/libavformat/tests/movenc.c
+++ b/libavformat/tests/movenc.c
@@ -766,6 +766,25 @@ int main(int argc, char **argv)
 clear_duration = 0;
 do_interleave = 0;
 
+// Write a fragmented file with b-frames and audio preroll,
+// with negative cts values, removing the edit list for the
+// video track.
+init_out("delay-moov-elst-neg-cts");
+av_dict_set(, "movflags", 
"frag_keyframe+delay_moov+negative_cts_offsets", 0);
+init(1, 1);
+mux_gops(2);
+finish();
+close_out();
+
+// Write a fragmented file with b-frames without audio preroll,
+// with negative cts values, avoiding any edit lists, allowing
+// to use empty_moov instead of delay_moov.
+init_out("empty-moov-neg-cts");
+av_dict_set(, "movflags", 
"frag_keyframe+empty_moov+negative_cts_offsets", 0);
+init(1, 0);
+mux_gops(2);
+finish();
+close_out();
 
 av_free(md5);
 
diff --git a/tests/ref/fate/movenc b/tests/ref/fate/movenc
index 47bcf9d515..872796ebce 100644
--- a/tests/ref/fate/movenc
+++ b/tests/ref/fate/movenc
@@ -140,3 +140,14 @@ write_data len 668, time 157, type sync atom moof
 write_data len 440, time 223, type boundary atom moof
 write_data len 262, time nopts, type trailer atom -
 edd19deae2b70afcf2cd744b89b7013d 4209 vfr-noduration-interleave
+write_data len 1231, time nopts, type header atom ftyp
+write_data len 916, time 0, type sync atom moof
+write_data len 908, time 100, type sync atom moof
+write_data len 148, time nopts, type trailer atom -
+781dbfd228f36903178e29faa727d78b 3203 delay-moov-elst-neg-cts
+write_data len 36, time nopts, type header atom ftyp
+write_data len 1123, time nopts, type header atom -
+write_data len 1188, time 0, type sync atom moof
+write_data len 908, time 103, type sync atom moof
+write_data len 148, time nopts, type trailer atom -
+7630fdf358e02c79e88f312f82a260b7 3403 empty-moov-neg-cts
-- 
2.13.5

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

[FFmpeg-devel] [PATCH 1/2] movenc: Add an option for enabling negative CTS offsets

[Jan Ekström]

From: Martin Storsjö 

This reduces the need for an edit list; streams that start with
e.g. dts=-1, pts=0 can be encoded as dts=0, pts=0 (which is valid
in mov/mp4) by shifting the dts values of all packets forward.
This avoids the need for edit lists for such streams (while they
still are needed for audio streams with encoder delay).

This eases conformance with the DASH-IF interoperability guidelines.

Signed-off-by: Martin Storsjö 
---
 libavformat/movenc.c | 28 
 libavformat/movenc.h |  2 ++
 2 files changed, 26 insertions(+), 4 deletions(-)

diff --git a/libavformat/movenc.c b/libavformat/movenc.c
index 10b959ad02..917486384a 100644
--- a/libavformat/movenc.c
+++ b/libavformat/movenc.c
@@ -77,6 +77,7 @@ static const AVOption options[] = {
 { "write_gama", "Write deprecated gama atom", 0, AV_OPT_TYPE_CONST, {.i64 
= FF_MOV_FLAG_WRITE_GAMA}, INT_MIN, INT_MAX, AV_OPT_FLAG_ENCODING_PARAM, 
"movflags" },
 { "use_metadata_tags", "Use mdta atom for metadata.", 0, 
AV_OPT_TYPE_CONST, {.i64 = FF_MOV_FLAG_USE_MDTA}, INT_MIN, INT_MAX, 
AV_OPT_FLAG_ENCODING_PARAM, "movflags" },
 { "skip_trailer", "Skip writing the mfra/tfra/mfro trailer for fragmented 
files", 0, AV_OPT_TYPE_CONST, {.i64 = FF_MOV_FLAG_SKIP_TRAILER}, INT_MIN, 
INT_MAX, AV_OPT_FLAG_ENCODING_PARAM, "movflags" },
+{ "negative_cts_offsets", "Use negative CTS offsets (reducing the need for 
edit lists)", 0, AV_OPT_TYPE_CONST, {.i64 = FF_MOV_FLAG_NEGATIVE_CTS_OFFSETS}, 
INT_MIN, INT_MAX, AV_OPT_FLAG_ENCODING_PARAM, "movflags" },
 FF_RTP_FLAG_OPTS(MOVMuxContext, rtp_flags),
 { "skip_iods", "Skip writing iods atom.", offsetof(MOVMuxContext, 
iods_skip), AV_OPT_TYPE_BOOL, {.i64 = 1}, 0, 1, AV_OPT_FLAG_ENCODING_PARAM},
 { "iods_audio_profile", "iods audio profile atom.", 
offsetof(MOVMuxContext, iods_audio_profile), AV_OPT_TYPE_INT, {.i64 = -1}, -1, 
255, AV_OPT_FLAG_ENCODING_PARAM},
@@ -2094,8 +2095,9 @@ static int mov_write_stsd_tag(AVFormatContext *s, 
AVIOContext *pb, MOVMuxContext
 return update_size(pb, pos);
 }
 
-static int mov_write_ctts_tag(AVIOContext *pb, MOVTrack *track)
+static int mov_write_ctts_tag(AVFormatContext *s, AVIOContext *pb, MOVTrack 
*track)
 {
+MOVMuxContext *mov = s->priv_data;
 MOVStts *ctts_entries;
 uint32_t entries = 0;
 uint32_t atom_size;
@@ -2119,7 +2121,11 @@ static int mov_write_ctts_tag(AVIOContext *pb, MOVTrack 
*track)
 atom_size = 16 + (entries * 8);
 avio_wb32(pb, atom_size); /* size */
 ffio_wfourcc(pb, "ctts");
-avio_wb32(pb, 0); /* version & flags */
+if (mov->flags & FF_MOV_FLAG_NEGATIVE_CTS_OFFSETS)
+avio_w8(pb, 1); /* version */
+else
+avio_w8(pb, 0); /* version */
+avio_wb24(pb, 0); /* flags */
 avio_wb32(pb, entries); /* entry count */
 for (i = 0; i < entries; i++) {
 avio_wb32(pb, ctts_entries[i].count);
@@ -2303,7 +2309,7 @@ static int mov_write_stbl_tag(AVFormatContext *s, 
AVIOContext *pb, MOVMuxContext
 if (track->par->codec_type == AVMEDIA_TYPE_VIDEO &&
 track->flags & MOV_TRACK_CTTS && track->entry) {
 
-if ((ret = mov_write_ctts_tag(pb, track)) < 0)
+if ((ret = mov_write_ctts_tag(s, pb, track)) < 0)
 return ret;
 }
 mov_write_stsc_tag(pb, track);
@@ -4044,7 +4050,10 @@ static int mov_write_trun_tag(AVIOContext *pb, 
MOVMuxContext *mov,
 
 avio_wb32(pb, 0); /* size placeholder */
 ffio_wfourcc(pb, "trun");
-avio_w8(pb, 0); /* version */
+if (mov->flags & FF_MOV_FLAG_NEGATIVE_CTS_OFFSETS)
+avio_w8(pb, 1); /* version */
+else
+avio_w8(pb, 0); /* version */
 avio_wb24(pb, flags);
 
 avio_wb32(pb, end - first); /* sample count */
@@ -4489,6 +4498,8 @@ static int mov_write_ftyp_tag(AVIOContext *pb, 
AVFormatContext *s)
 ffio_wfourcc(pb, "MSNV");
 else if (mov->mode == MODE_MP4 && mov->flags & 
FF_MOV_FLAG_DEFAULT_BASE_MOOF)
 ffio_wfourcc(pb, "iso5"); // Required when using default-base-is-moof
+else if (mov->mode == MODE_MP4 && mov->flags & 
FF_MOV_FLAG_NEGATIVE_CTS_OFFSETS)
+ffio_wfourcc(pb, "iso4");
 else if (mov->mode == MODE_MP4)
 ffio_wfourcc(pb, "isom");
 else if (mov->mode == MODE_IPOD)
@@ -4759,6 +4770,8 @@ static int mov_flush_fragment(AVFormatContext *s, int 
force)
 if (!track->end_reliable) {
 AVPacket pkt;
 if (!ff_interleaved_peek(s, i, , 1)) {
+if (track->dts_shift != AV_NOPTS_VALUE)
+pkt.dts += track->dts_shift;
 track->track_duration = pkt.dts - track->start_dts;
 if (pkt.pts != AV_NOPTS_VALUE)
 track->end_pts = pkt.pts;
@@ -5282,6 +5295,12 @@ static int mov_write_single_packet(AVFormatContext *s, 
AVPacket *pkt)
 mov->flags &= ~FF_MOV_FLAG_FRAG_DISCONT;
 }
 
+if (mov->flags & FF_MOV_FLAG_NEGATIVE_CTS_OFFSETS) {
+if 

[FFmpeg-devel] [PATCH] configure: add pkg-config check for alsa

[Jan Ekström]

---
 configure | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/configure b/configure
index b9a3a9bc1f..5aa642a9bb 100755
--- a/configure
+++ b/configure
@@ -6254,7 +6254,8 @@ EOF
 fi
 check_header soundcard.h
 
-enabled alsa && check_lib alsa alsa/asoundlib.h snd_pcm_htimestamp -lasound
+enabled alsa && use_pkg_config alsa alsa "alsa/asoundlib.h" snd_pcm_htimestamp 
||
+check_lib alsa alsa/asoundlib.h snd_pcm_htimestamp -lasound
 
 enabled jack && check_lib jack jack/jack.h jack_client_open -ljack &&
 check_func jack_port_get_latency_range -ljack
-- 
2.13.6

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

[FFmpeg-devel] [PATCH 1/2 v2] movenc: Add an option for enabling negative CTS offsets

[Jan Ekström]

From: Martin Storsjö 

This reduces the need for an edit list; streams that start with
e.g. dts=-1, pts=0 can be encoded as dts=0, pts=0 (which is valid
in mov/mp4) by shifting the dts values of all packets forward.
This avoids the need for edit lists for such streams (while they
still are needed for audio streams with encoder delay).

This eases conformance with the DASH-IF interoperability guidelines.

Signed-off-by: Martin Storsjö 
---
 doc/muxers.texi  |  2 ++
 libavformat/movenc.c | 28 
 libavformat/movenc.h |  2 ++
 3 files changed, 28 insertions(+), 4 deletions(-)

diff --git a/doc/muxers.texi b/doc/muxers.texi
index 36769b8c1a..312749942c 100644
--- a/doc/muxers.texi
+++ b/doc/muxers.texi
@@ -1055,6 +1055,8 @@ on the implicit end of the previous track fragment).
 @item -write_tmcd
 Specify @code{on} to force writing a timecode track, @code{off} to disable it
 and @code{auto} to write a timecode track only for mov and mp4 output 
(default).
+@item -movflags negative_cts_offsets
+Enables utilization of version 1 of the CTTS box, in which the CTS offsets can 
be negative. This enables the initial sample to have DTS/CTS of zero, and 
reduces the need for edit lists for some cases such as video tracks with 
B-frames. Additionally, eases conformance with the DASH-IF interoperability 
guidelines.
 @end table
 
 @subsection Example
diff --git a/libavformat/movenc.c b/libavformat/movenc.c
index 10b959ad02..917486384a 100644
--- a/libavformat/movenc.c
+++ b/libavformat/movenc.c
@@ -77,6 +77,7 @@ static const AVOption options[] = {
 { "write_gama", "Write deprecated gama atom", 0, AV_OPT_TYPE_CONST, {.i64 
= FF_MOV_FLAG_WRITE_GAMA}, INT_MIN, INT_MAX, AV_OPT_FLAG_ENCODING_PARAM, 
"movflags" },
 { "use_metadata_tags", "Use mdta atom for metadata.", 0, 
AV_OPT_TYPE_CONST, {.i64 = FF_MOV_FLAG_USE_MDTA}, INT_MIN, INT_MAX, 
AV_OPT_FLAG_ENCODING_PARAM, "movflags" },
 { "skip_trailer", "Skip writing the mfra/tfra/mfro trailer for fragmented 
files", 0, AV_OPT_TYPE_CONST, {.i64 = FF_MOV_FLAG_SKIP_TRAILER}, INT_MIN, 
INT_MAX, AV_OPT_FLAG_ENCODING_PARAM, "movflags" },
+{ "negative_cts_offsets", "Use negative CTS offsets (reducing the need for 
edit lists)", 0, AV_OPT_TYPE_CONST, {.i64 = FF_MOV_FLAG_NEGATIVE_CTS_OFFSETS}, 
INT_MIN, INT_MAX, AV_OPT_FLAG_ENCODING_PARAM, "movflags" },
 FF_RTP_FLAG_OPTS(MOVMuxContext, rtp_flags),
 { "skip_iods", "Skip writing iods atom.", offsetof(MOVMuxContext, 
iods_skip), AV_OPT_TYPE_BOOL, {.i64 = 1}, 0, 1, AV_OPT_FLAG_ENCODING_PARAM},
 { "iods_audio_profile", "iods audio profile atom.", 
offsetof(MOVMuxContext, iods_audio_profile), AV_OPT_TYPE_INT, {.i64 = -1}, -1, 
255, AV_OPT_FLAG_ENCODING_PARAM},
@@ -2094,8 +2095,9 @@ static int mov_write_stsd_tag(AVFormatContext *s, 
AVIOContext *pb, MOVMuxContext
 return update_size(pb, pos);
 }
 
-static int mov_write_ctts_tag(AVIOContext *pb, MOVTrack *track)
+static int mov_write_ctts_tag(AVFormatContext *s, AVIOContext *pb, MOVTrack 
*track)
 {
+MOVMuxContext *mov = s->priv_data;
 MOVStts *ctts_entries;
 uint32_t entries = 0;
 uint32_t atom_size;
@@ -2119,7 +2121,11 @@ static int mov_write_ctts_tag(AVIOContext *pb, MOVTrack 
*track)
 atom_size = 16 + (entries * 8);
 avio_wb32(pb, atom_size); /* size */
 ffio_wfourcc(pb, "ctts");
-avio_wb32(pb, 0); /* version & flags */
+if (mov->flags & FF_MOV_FLAG_NEGATIVE_CTS_OFFSETS)
+avio_w8(pb, 1); /* version */
+else
+avio_w8(pb, 0); /* version */
+avio_wb24(pb, 0); /* flags */
 avio_wb32(pb, entries); /* entry count */
 for (i = 0; i < entries; i++) {
 avio_wb32(pb, ctts_entries[i].count);
@@ -2303,7 +2309,7 @@ static int mov_write_stbl_tag(AVFormatContext *s, 
AVIOContext *pb, MOVMuxContext
 if (track->par->codec_type == AVMEDIA_TYPE_VIDEO &&
 track->flags & MOV_TRACK_CTTS && track->entry) {
 
-if ((ret = mov_write_ctts_tag(pb, track)) < 0)
+if ((ret = mov_write_ctts_tag(s, pb, track)) < 0)
 return ret;
 }
 mov_write_stsc_tag(pb, track);
@@ -4044,7 +4050,10 @@ static int mov_write_trun_tag(AVIOContext *pb, 
MOVMuxContext *mov,
 
 avio_wb32(pb, 0); /* size placeholder */
 ffio_wfourcc(pb, "trun");
-avio_w8(pb, 0); /* version */
+if (mov->flags & FF_MOV_FLAG_NEGATIVE_CTS_OFFSETS)
+avio_w8(pb, 1); /* version */
+else
+avio_w8(pb, 0); /* version */
 avio_wb24(pb, flags);
 
 avio_wb32(pb, end - first); /* sample count */
@@ -4489,6 +4498,8 @@ static int mov_write_ftyp_tag(AVIOContext *pb, 
AVFormatContext *s)
 ffio_wfourcc(pb, "MSNV");
 else if (mov->mode == MODE_MP4 && mov->flags & 
FF_MOV_FLAG_DEFAULT_BASE_MOOF)
 ffio_wfourcc(pb, "iso5"); // Required when using default-base-is-moof
+else if (mov->mode == MODE_MP4 && mov->flags & 
FF_MOV_FLAG_NEGATIVE_CTS_OFFSETS)
+ffio_wfourcc(pb, "iso4");
 else if 

[FFmpeg-devel] [PATCH 1/2 v3] movenc: Add an option for enabling negative CTS offsets

[Jan Ekström]

From: Martin Storsjö 

This reduces the need for an edit list; streams that start with
e.g. dts=-1, pts=0 can be encoded as dts=0, pts=0 (which is valid
in mov/mp4) by shifting the dts values of all packets forward.
This avoids the need for edit lists for such streams (while they
still are needed for audio streams with encoder delay).

This eases conformance with the DASH-IF interoperability guidelines.

Signed-off-by: Martin Storsjö 
---
 doc/muxers.texi  |  6 ++
 libavformat/movenc.c | 28 
 libavformat/movenc.h |  2 ++
 3 files changed, 32 insertions(+), 4 deletions(-)

diff --git a/doc/muxers.texi b/doc/muxers.texi
index 36769b8c1a..8a1319c153 100644
--- a/doc/muxers.texi
+++ b/doc/muxers.texi
@@ -1055,6 +1055,12 @@ on the implicit end of the previous track fragment).
 @item -write_tmcd
 Specify @code{on} to force writing a timecode track, @code{off} to disable it
 and @code{auto} to write a timecode track only for mov and mp4 output 
(default).
+@item -movflags negative_cts_offsets
+Enables utilization of version 1 of the CTTS box, in which the CTS offsets can
+be negative. This enables the initial sample to have DTS/CTS of zero, and
+reduces the need for edit lists for some cases such as video tracks with
+B-frames. Additionally, eases conformance with the DASH-IF interoperability
+guidelines.
 @end table
 
 @subsection Example
diff --git a/libavformat/movenc.c b/libavformat/movenc.c
index 10b959ad02..917486384a 100644
--- a/libavformat/movenc.c
+++ b/libavformat/movenc.c
@@ -77,6 +77,7 @@ static const AVOption options[] = {
 { "write_gama", "Write deprecated gama atom", 0, AV_OPT_TYPE_CONST, {.i64 
= FF_MOV_FLAG_WRITE_GAMA}, INT_MIN, INT_MAX, AV_OPT_FLAG_ENCODING_PARAM, 
"movflags" },
 { "use_metadata_tags", "Use mdta atom for metadata.", 0, 
AV_OPT_TYPE_CONST, {.i64 = FF_MOV_FLAG_USE_MDTA}, INT_MIN, INT_MAX, 
AV_OPT_FLAG_ENCODING_PARAM, "movflags" },
 { "skip_trailer", "Skip writing the mfra/tfra/mfro trailer for fragmented 
files", 0, AV_OPT_TYPE_CONST, {.i64 = FF_MOV_FLAG_SKIP_TRAILER}, INT_MIN, 
INT_MAX, AV_OPT_FLAG_ENCODING_PARAM, "movflags" },
+{ "negative_cts_offsets", "Use negative CTS offsets (reducing the need for 
edit lists)", 0, AV_OPT_TYPE_CONST, {.i64 = FF_MOV_FLAG_NEGATIVE_CTS_OFFSETS}, 
INT_MIN, INT_MAX, AV_OPT_FLAG_ENCODING_PARAM, "movflags" },
 FF_RTP_FLAG_OPTS(MOVMuxContext, rtp_flags),
 { "skip_iods", "Skip writing iods atom.", offsetof(MOVMuxContext, 
iods_skip), AV_OPT_TYPE_BOOL, {.i64 = 1}, 0, 1, AV_OPT_FLAG_ENCODING_PARAM},
 { "iods_audio_profile", "iods audio profile atom.", 
offsetof(MOVMuxContext, iods_audio_profile), AV_OPT_TYPE_INT, {.i64 = -1}, -1, 
255, AV_OPT_FLAG_ENCODING_PARAM},
@@ -2094,8 +2095,9 @@ static int mov_write_stsd_tag(AVFormatContext *s, 
AVIOContext *pb, MOVMuxContext
 return update_size(pb, pos);
 }
 
-static int mov_write_ctts_tag(AVIOContext *pb, MOVTrack *track)
+static int mov_write_ctts_tag(AVFormatContext *s, AVIOContext *pb, MOVTrack 
*track)
 {
+MOVMuxContext *mov = s->priv_data;
 MOVStts *ctts_entries;
 uint32_t entries = 0;
 uint32_t atom_size;
@@ -2119,7 +2121,11 @@ static int mov_write_ctts_tag(AVIOContext *pb, MOVTrack 
*track)
 atom_size = 16 + (entries * 8);
 avio_wb32(pb, atom_size); /* size */
 ffio_wfourcc(pb, "ctts");
-avio_wb32(pb, 0); /* version & flags */
+if (mov->flags & FF_MOV_FLAG_NEGATIVE_CTS_OFFSETS)
+avio_w8(pb, 1); /* version */
+else
+avio_w8(pb, 0); /* version */
+avio_wb24(pb, 0); /* flags */
 avio_wb32(pb, entries); /* entry count */
 for (i = 0; i < entries; i++) {
 avio_wb32(pb, ctts_entries[i].count);
@@ -2303,7 +2309,7 @@ static int mov_write_stbl_tag(AVFormatContext *s, 
AVIOContext *pb, MOVMuxContext
 if (track->par->codec_type == AVMEDIA_TYPE_VIDEO &&
 track->flags & MOV_TRACK_CTTS && track->entry) {
 
-if ((ret = mov_write_ctts_tag(pb, track)) < 0)
+if ((ret = mov_write_ctts_tag(s, pb, track)) < 0)
 return ret;
 }
 mov_write_stsc_tag(pb, track);
@@ -4044,7 +4050,10 @@ static int mov_write_trun_tag(AVIOContext *pb, 
MOVMuxContext *mov,
 
 avio_wb32(pb, 0); /* size placeholder */
 ffio_wfourcc(pb, "trun");
-avio_w8(pb, 0); /* version */
+if (mov->flags & FF_MOV_FLAG_NEGATIVE_CTS_OFFSETS)
+avio_w8(pb, 1); /* version */
+else
+avio_w8(pb, 0); /* version */
 avio_wb24(pb, flags);
 
 avio_wb32(pb, end - first); /* sample count */
@@ -4489,6 +4498,8 @@ static int mov_write_ftyp_tag(AVIOContext *pb, 
AVFormatContext *s)
 ffio_wfourcc(pb, "MSNV");
 else if (mov->mode == MODE_MP4 && mov->flags & 
FF_MOV_FLAG_DEFAULT_BASE_MOOF)
 ffio_wfourcc(pb, "iso5"); // Required when using default-base-is-moof
+else if (mov->mode == MODE_MP4 && mov->flags & 
FF_MOV_FLAG_NEGATIVE_CTS_OFFSETS)
+ffio_wfourcc(pb, "iso4");
 else if 

[FFmpeg-devel] [PATCH] maintainers: add myself to the general developers list

[Jan Ekström]

---

It was recommended to me that I do this, as I do not maintain
any specific functionality/module as such. 

Jan

 MAINTAINERS | 1 +
 1 file changed, 1 insertion(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 77f48b984b..d08fad80b8 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -556,6 +556,7 @@ Pedro Arthur
 Sebastien Zwickert
 Vittorio Giovara
 wm4
+Jan Ekström
 (this list is incomplete)
 
 
-- 
2.13.6

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

[FFmpeg-devel] [PATCH] movenc: take packet dts shifting into mention in check_pkt

[Jan Ekström]

This FFmpeg-specific "fuzzer fix" was never perfect, but now it
stopped encoding of actual content with a big enough DTS shift.
This returns the function to its original state of results
before negative CTS offsets were added.

I remember dealing with this function before, but somehow had
forgotten about it during VDD. The test cases not tripping this
over also didn't help.
---
 libavformat/movenc.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/libavformat/movenc.c b/libavformat/movenc.c
index 9c3e6437d7..2838286141 100644
--- a/libavformat/movenc.c
+++ b/libavformat/movenc.c
@@ -4989,6 +4989,12 @@ static int check_pkt(AVFormatContext *s, AVPacket *pkt)
 } else
 ref = pkt->dts; // Skip tests for the first packet
 
+if (trk->dts_shift != AV_NOPTS_VALUE) {
+/* With negative CTS offsets we have set an offset to the DTS,
+ * reverse this for the check. */
+ref -= trk->dts_shift;
+}
+
 duration = pkt->dts - ref;
 if (pkt->dts < ref || duration >= INT_MAX) {
 av_log(s, AV_LOG_ERROR, "Application provided duration: %"PRId64" / 
timestamp: %"PRId64" is out of range for mov/mp4 format\n",
-- 
2.13.6

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

Re: [FFmpeg-devel] [PATCH] hwcontext_d3d11va: properly reset values after release/close

[Jan Ekström]

On Sat, Nov 25, 2017 at 6:25 PM, Mark Thompson  wrote:
> LGTM, please apply.
>
> I checked the other hwcontext implementations for the same problem, and found 
> it only in OpenCL - it could also crash there, fixed in 
> .
>
> Thanks,
>
> - Mark

Thanks for the reviews, applied.

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

[FFmpeg-devel] [PATCH] hwcontext_d3d11va: properly reset values after release/close

[Jan Ekström]

Makes the uninit function re-entrable, which can be a common case
when an API user first tries to initialize its context, fails, and
then finally unrefs the AVHWDevice.

Fixes a crash reported by sm2345 on IRC.
---
 libavutil/hwcontext_d3d11va.c | 21 -
 1 file changed, 16 insertions(+), 5 deletions(-)

diff --git a/libavutil/hwcontext_d3d11va.c b/libavutil/hwcontext_d3d11va.c
index 65dd6651fc..845a4a45fe 100644
--- a/libavutil/hwcontext_d3d11va.c
+++ b/libavutil/hwcontext_d3d11va.c
@@ -458,20 +458,31 @@ static void d3d11va_device_uninit(AVHWDeviceContext 
*hwdev)
 {
 AVD3D11VADeviceContext *device_hwctx = hwdev->hwctx;
 
-if (device_hwctx->device)
+if (device_hwctx->device) {
 ID3D11Device_Release(device_hwctx->device);
+device_hwctx->device = NULL;
+}
 
-if (device_hwctx->device_context)
+if (device_hwctx->device_context) {
 ID3D11DeviceContext_Release(device_hwctx->device_context);
+device_hwctx->device_context = NULL;
+}
 
-if (device_hwctx->video_device)
+if (device_hwctx->video_device) {
 ID3D11VideoDevice_Release(device_hwctx->video_device);
+device_hwctx->video_device = NULL;
+}
 
-if (device_hwctx->video_context)
+if (device_hwctx->video_context) {
 ID3D11VideoContext_Release(device_hwctx->video_context);
+device_hwctx->video_context = NULL;
+}
 
-if (device_hwctx->lock == d3d11va_default_lock)
+if (device_hwctx->lock == d3d11va_default_lock) {
 CloseHandle(device_hwctx->lock_ctx);
+device_hwctx->lock_ctx = INVALID_HANDLE_VALUE;
+device_hwctx->lock = NULL;
+}
 }
 
 static int d3d11va_device_create(AVHWDeviceContext *ctx, const char *device,
-- 
2.14.3

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

[FFmpeg-devel] [PATCH] mediacodecdec: fix build by including hwaccel.h

[Jan Ekström]

Enables the decoder to utilize the type AVCodecHWConfigInternal.
---
 libavcodec/mediacodecdec.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/libavcodec/mediacodecdec.c b/libavcodec/mediacodecdec.c
index 6d392adb3a..63209f52ac 100644
--- a/libavcodec/mediacodecdec.c
+++ b/libavcodec/mediacodecdec.c
@@ -36,6 +36,7 @@
 #include "internal.h"
 #include "mediacodec_wrapper.h"
 #include "mediacodecdec_common.h"
+#include "hwaccel.h"
 
 typedef struct MediaCodecH264DecContext {
 
-- 
2.14.3

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

[FFmpeg-devel] lavc/arm/hevcdsp_idct_neon: build failure with clang + gas-preprocessor

[Jan Ekström]

Hi,

I have been testing FFmpeg with the Android NDK (R15)'s clang, and
recently (a few weeks ago) the build has broken at
libavcodec/arm/hevcdsp_idct_neon.

It should be enough to test this with --cc=arm-linux-androideabi-clang
(or any other ARM clang compiler) and the latest gas-preprocessor.pl
in PATH for NEON SIMD
(https://git.libav.org/?p=gas-preprocessor.git;a=summary).

The errors are as follows:
> AS  libavcodec/arm/hevcdsp_idct_neon.o
> :356:10: error: out of range pc-relative fixup value
>  ldr r3, Literal_0
>  ^
> :358:10: error: out of range pc-relative fixup value
>  ldr r3, Literal_1
>  ^
> :360:10: error: out of range pc-relative fixup value
>  ldr r3, Literal_2
>  ^

Best regards,
Jan
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] mediacodecdec: fix build by including hwaccel.h

[Jan Ekström]

On Fri, Dec 1, 2017 at 10:44 PM, Mark Thompson  wrote:
>
> LGTM.
>
> (Apologies for breaking that.)
>

Thanks for the LGTM. Pushed with the header include added in its
alphabetically ordered position as recommended on IRC.

And no problem, we all miss things :) .

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

Re: [FFmpeg-devel] [PATCH] Added Turing codec to ffmpeg

[Jan Ekström]

On Thu, Dec 14, 2017 at 12:39 AM, Josh de Kock  wrote:
> On Thu,  7 Dec 2017 11:08:47 +
> Matteo Naccari  wrote:
>
>> - This patch contains the changes required to interface the Turing codec
>> [...]
>
> I still have an issue with this patch, while it would be nice to have another 
> HEVC encoder available in FFmpeg for comparisons and whatnot, I feel that 
> turingcodec isn't a mature enough encoder compared to what is already in the 
> project.
>
> Not to mention that development seems to have stalled (with only very minor 
> fixes for several months). In FFmpeg it is very difficult to remove 
> 'features', so if this patch were to be merged and then turingcodec to 
> actually go stale we'd be left with dead code for longer than is ideal 
> (forever).
>
> My opinion is that you should just maintain this separately as an out-of-tree 
> patch as it doesn't benefit us.
>

Hi,

After taking a look at the commit history of the last year+ or so,
issue tracker and pull request list over at
https://github.com/bbc/turingcodec I must say I find it somewhat hard
to disagree on a general level.

Creating an encoder is great work and I applaud people for that, but
unfortunately it - at the current point of time - looks like neither
from the licensing, performance or project activity point of view
merging a wrapper for this library is a good idea.


Best regards,
Jan
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] libavcodec/hevcdsp: compilation error fixed for ARM

[Jan Ekström]

On Fri, Dec 8, 2017 at 7:18 PM, Michael Niedermayer
 wrote:
> please provide the uncut error message and compiler/assembler version
> affected in the commit message as reference otherwise its hard to
> understand what/where exactly the issue was

Hi,

I noticed this breakage with clang on ARMv7, and jamrial seemed to
mention that aarch64 with GCC seemed to be broken as well?
https://ffmpeg.org/pipermail/ffmpeg-devel/2017-December/221518.html


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

Re: [FFmpeg-devel] [PATCH] arm/hevc_idct: fix compilation on Android

[Jan Ekström]

On Sat, Dec 9, 2017 at 12:14 AM, James Almer  wrote:
> Compilation error "out of range" fixed for armeabi-v7a. Compilation failed
> trying to build libvlc.aar for ARM7 android on ubuntu 16.04 host. Error
> messages is "Offset out of range". The reason of the error is assembler LDR
> directives in function "ff_hevc_transform_luma_4x4_neon_8" need local storage
> in range <1k, but no such storage provided.
>
> Based on a patch by Ihor Bobalo 
>
> Suggested-by: wbs
> Signed-off-by: James Almer 
>

Can confirm that this fixes compilation, clang+gas-preprocessor works. Thanks.

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

Re: [FFmpeg-devel] [PATCH] arm/hevc_idct: fix compilation on Android

[Jan Ekström]

On Sat, Dec 9, 2017 at 2:52 PM, Jan Ekström <jee...@gmail.com> wrote:
> On Sat, Dec 9, 2017 at 12:14 AM, James Almer <jamr...@gmail.com> wrote:
>> Compilation error "out of range" fixed for armeabi-v7a. Compilation failed
>> trying to build libvlc.aar for ARM7 android on ubuntu 16.04 host. Error
>> messages is "Offset out of range". The reason of the error is assembler LDR
>> directives in function "ff_hevc_transform_luma_4x4_neon_8" need local storage
>> in range <1k, but no such storage provided.
>>
>> Based on a patch by Ihor Bobalo <b...@eleks.com>
>>
>> Suggested-by: wbs
>> Signed-off-by: James Almer <jamr...@gmail.com>
>>
>
> Can confirm that this fixes compilation, clang+gas-preprocessor works. Thanks.
>
> Jan

Aditionally tested with armv7 GCC 4.9 as well, so nothing seems to be
broken on that side, either. This is not surprising, as this only
moves a function and a macro - as well as adds a .ltorg which causes
the literal pool to be dumped. This helps as the offsets are getting
too large otherwise for the SIMD used in the following function.

Given the limited change in this, I'd say LGTM and will push tonight
unless someone objects.

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

Re: [FFmpeg-devel] [PATCH] arm/hevc_idct: fix compilation on Android

[Jan Ekström]

On Sat, Dec 9, 2017 at 12:14 AM, James Almer  wrote:
> Compilation error "out of range" fixed for armeabi-v7a. Compilation failed
> trying to build libvlc.aar for ARM7 android on ubuntu 16.04 host. Error
> messages is "Offset out of range". The reason of the error is assembler LDR
> directives in function "ff_hevc_transform_luma_4x4_neon_8" need local storage
> in range <1k, but no such storage provided.
>
> Based on a patch by Ihor Bobalo 
>
> Suggested-by: wbs
> Signed-off-by: James Almer 
> ---

Pushed. Thanks for posting the patch.

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

Re: [FFmpeg-devel] [PATCH] lavf/bluray: translate a read of 0 to EOF

[Jan Ekström]

On Sun, May 6, 2018 at 5:32 PM, wm4  wrote:
>
> Hilarious, another of those EOf issues. Too bad we didn't just revert
> that crap. I wonder how many years it'll take until we got all of them.
>
> LGTM.

Thanks, pushed. This should be back-ported to release/4.0 I guess?

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

[FFmpeg-devel] [PATCH] lavf/bluray: translate a read of 0 to EOF

[Jan Ekström]

Yet another case of forgotten 0 =! EOF translation. The libbluray
documentation specifically mentions that a read of 0 is EOF.

Reported by Fyr on IRC.
---
 libavformat/bluray.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavformat/bluray.c b/libavformat/bluray.c
index 9282bf9956..635c4f1b87 100644
--- a/libavformat/bluray.c
+++ b/libavformat/bluray.c
@@ -198,7 +198,7 @@ static int bluray_read(URLContext *h, unsigned char *buf, 
int size)
 
 len = bd_read(bd->bd, buf, size);
 
-return len;
+return len == 0 ? AVERROR_EOF : len;
 }
 
 static int64_t bluray_seek(URLContext *h, int64_t pos, int whence)
-- 
2.17.0

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

Re: [FFmpeg-devel] [PATCH] configure: add pkg-config check for zlib

[Jan Ekström]

On Sun, May 6, 2018 at 7:41 PM, James Almer  wrote:
>
> LGTM.

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

Re: [FFmpeg-devel] [PATCH] flvenc: Fix sequence header update timestamps

[Jan Ekström]

WHAT!?

This LGTM was for the bit mask *only*

ALL OTHER POINTS STAND

Jan

On Fri, May 4, 2018, 06:04 Steven Liu <l...@chinaffmpeg.org> wrote:

>
>
> > On 4 May 2018, at 02:00, Jan Ekström <jee...@gmail.com> wrote:
> >
> > On Thu, May 3, 2018 at 8:58 PM, Jan Ekström <jee...@gmail.com> wrote:
> >> On Thu, May 3, 2018 at 7:50 PM, Alex Converse <alex.conve...@gmail.com>
> wrote:
> >>> From: Alex Converse <alexc...@twitch.tv>
> >>>
> >>> ---
> >>> libavformat/flvenc.c | 10 +-
> >>> 1 file changed, 5 insertions(+), 5 deletions(-)
> >>>
> >>> diff --git a/libavformat/flvenc.c b/libavformat/flvenc.c
> >>> index e8af48cb64..827d798a61 100644
> >>> --- a/libavformat/flvenc.c
> >>> +++ b/libavformat/flvenc.c
> >>> @@ -480,7 +480,7 @@ static int unsupported_codec(AVFormatContext *s,
> >>> return AVERROR(ENOSYS);
> >>> }
> >>>
> >>> -static void flv_write_codec_header(AVFormatContext* s,
> AVCodecParameters* par) {
> >>> +static void flv_write_codec_header(AVFormatContext* s,
> AVCodecParameters* par, unsigned int ts) {
> >>
> >> Hi,
> >>
> >> While the timestamp field is 8+24=32 bits, the DTS value is int64_ts.
> >> Thus, while I'm really bad at doing wrap-around logic, wouldn't it be
> >> something a la ´uint32_t wrapped_timestamp = (uint32_t)(ts %
> >> UINT32_MAX)`?
> >>
> >> Additionally, I did briefly go through E.4.1 (FLV Tag) in the spec and
> >> it doesn't really seem to define whether this value is PTS or DTS...
> >> Is this defined anywhere proper? Given FLV's age I wouldn't be
> >> surprised that the answer would be "effectively DTS", of course. But
> >> if you've seen what  Adobe's implementation writes with B-frames it'd
> >> be interesting to see.
> >>
> >>> int64_t data_size;
> >>> AVIOContext *pb = s->pb;
> >>> FLVContext *flv = s->priv_data;
> >>> @@ -492,8 +492,8 @@ static void
> flv_write_codec_header(AVFormatContext* s, AVCodecParameters* par) {
> >>> par->codec_type == AVMEDIA_TYPE_VIDEO ?
> >>> FLV_TAG_TYPE_VIDEO : FLV_TAG_TYPE_AUDIO);
> >>> avio_wb24(pb, 0); // size patched later
> >>> -avio_wb24(pb, 0); // ts
> >>> -avio_w8(pb, 0);   // ts ext
> >>> +avio_wb24(pb, ts & 0xFF);
> >>> +avio_w8(pb, (ts >> 24) & 0x7F);
> >>
> >> Looking at the spec this is bottom 24 bits of the timestamp and top 8,
> >> thus why is the second one not & 0xFF ?
> >>
> >
> > D'oh, I should read better. "...to form a SI32 value". Thus, this is
> LGTM.
>
> Will apply.
>
> Thanks
> Steven
>
>
>
>
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH]configure: Support libxml2 on systems without pkg-config

[Jan Ekström]

On Mon, May 14, 2018 at 10:42 PM, Carl Eugen Hoyos  wrote:
> 2018-05-14 21:39 GMT+02:00, Nicolas George :
>> Carl Eugen Hoyos (2018-05-14):
>>> Attached patch allows to easily enable the dash demuxer on systems
>>> without pkg-config.
>>
>> I am rather for letting them install pkg-config.
>
> Which - as you know - can be impossible.
>
> Carl Eugen

Just out of interest, which systems are these? OS/2? While this
question could be interpreted as facetious, let me say I am wholly
just genuinely interested in such systems - where modern FFmpeg can
still build or operate.

Also for the record, some distros (including Fedora) have actually
stopped using original pkg-config since a few versions ago, instead
opting for a new re-implementation called pkgconf
(https://github.com/pkgconf/pkgconf).

Best regards,
Jan
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] About the future of component registration APIs

[Jan Ekström]

On Wed, May 9, 2018 at 3:38 PM, Yu Xiaolei  wrote:
> Hello,
> I noticed that commit 7e8eba2d87 deprecated avcodec_register and there was
> some disagreement on this issue. Will there be some sort of replacement for
> it?
>
> We want to build ffmpeg in a way that only the most frequently used
> components are shipped initially and others are downloaded on demand. This
> can be implemented for now with a custom link step but will be impossible
> if this API were removed.

Hi,

The problem was that the things in FFmpeg until then did not make it
actually possible to dynamically register external things. Not to
mention that there were internal symbols required to even create what
you were trying to register. In other words, it looked as if you could
add external things, but in reality you could not with the public
APIs.

The other alternative, where you just wanted to distribute internal
parts of FFmpeg separately, was not supported by the build system in
any other form than what Debian did. Namely, they built one shared
library with certain decoders and encoders disabled, and then another
version which was a replacement for the first one. And this is still
possible.

If you require proper separation of components within libraries, and
then their dynamic registration, that needs a proper public API
design. Currently there is no replacement for the function you
mention, while I am not sure what you could do with it and the
standard build system options.

Best regards,
Jan
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] lavf/bluray: translate a read of 0 to EOF

[Jan Ekström]

On Sun, May 6, 2018 at 11:16 PM, Michael Niedermayer
<mich...@niedermayer.cc> wrote:
> On Sun, May 06, 2018 at 06:55:01PM +0300, Jan Ekström wrote:
>> Thanks, pushed. This should be back-ported to release/4.0 I guess?
>
> probably yes
>
> thanks
>

Finally got the time, cherry-pick -x'd and pushed to release/4.0.

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

Re: [FFmpeg-devel] [RFC][PATCH] configure: Disable unsafe demuxers by default

[Jan Ekström]

On Thu, May 10, 2018 at 6:53 PM, Paul B Mahol  wrote:
>
> Against.

Hi,

Thank you for your review.

I would recommend you put a bit more effort into explaining which
parts you are opposed to. Think of yourself being on the receiving end
of such comments, how you would like to just get a flat out refusal
without any further details. You do not give the other side any chance
of doing anything, because you have not noted what is wrong with it.

Best regards,
Jan
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] flvenc: Fix sequence header update timestamps

[Jan Ekström]

On Fri, May 11, 2018 at 1:39 AM, Alex Converse <alex.conve...@gmail.com> wrote:
> On Thu, May 3, 2018 at 10:58 AM, Jan Ekström <jee...@gmail.com> wrote:
>>
>> Hi,
>>
>> While the timestamp field is 8+24=32 bits, the DTS value is int64_ts.
>> Thus, while I'm really bad at doing wrap-around logic, wouldn't it be
>> something a la ´uint32_t wrapped_timestamp = (uint32_t)(ts %
>> UINT32_MAX)`?
>>
>
> See the note about timestamps below.
>
>> Additionally, I did briefly go through E.4.1 (FLV Tag) in the spec and
>> it doesn't really seem to define whether this value is PTS or DTS...
>> Is this defined anywhere proper? Given FLV's age I wouldn't be
>> surprised that the answer would be "effectively DTS", of course. But
>> if you've seen what  Adobe's implementation writes with B-frames it'd
>> be interesting to see.
>>
>
> FLV AVC packets have a field called CompositionTime described to match
> 14496-12. FLV requires this composition offset to be zero for sequence header
> type packets. This strongly indicates to me that we want DTS here. In addition
> the current muxer and demuxer already use dts pretty consistently for this
> value (and use cts = pts - dts).
>

Alright, so dts it is... That only leaves out the fact that we're
stuffing int64_t into an "unsigned int", which most likely will not
warn on 64bit linux, but most likely will on various architectures
and/or systems.

So we:
1) take in the dts as int64_t.
2) apply wrap-over at either 32 or 31 bits depending on if the signed
value is ever supposed to be negative. Depends on how wrap-around in
FLV is supposed to be handled (aka "Is the negative area ever supposed
to be used from the 32bit signed integer field?").
3) Write it there.

>
>> >  int64_t data_size;
>> >  AVIOContext *pb = s->pb;
>> >  FLVContext *flv = s->priv_data;
>> > @@ -492,8 +492,8 @@ static void flv_write_codec_header(AVFormatContext* s, 
>> > AVCodecParameters* par) {
>> >  par->codec_type == AVMEDIA_TYPE_VIDEO ?
>> >  FLV_TAG_TYPE_VIDEO : FLV_TAG_TYPE_AUDIO);
>> >  avio_wb24(pb, 0); // size patched later
>> > -avio_wb24(pb, 0); // ts
>> > -avio_w8(pb, 0);   // ts ext
>> > +avio_wb24(pb, ts & 0xFF);
>> > +avio_w8(pb, (ts >> 24) & 0x7F);
>>
>> Looking at the spec this is bottom 24 bits of the timestamp and top 8,
>> thus why is the second one not & 0xFF ?
>>
>
> The mapping from dts to the flv timestamp we write to the stream is identical
> for to what we do for non header packets. [1] I can pull this into a separate
> function but it's only two lines so it didn't seem worth while.

Yes, I think I commented on this that I hadn't noticed the signedness
of the value there :) So this is 100% a-OK.

>
>> >  avio_wb24(pb, 0); // streamid
>> >  pos = avio_tell(pb);
>> >  if (par->codec_id == AV_CODEC_ID_AAC) {
>> > @@ -756,7 +756,7 @@ static int flv_write_header(AVFormatContext *s)
>> >  }
>> >
>> >  for (i = 0; i < s->nb_streams; i++) {
>> > -flv_write_codec_header(s, s->streams[i]->codecpar);
>> > +flv_write_codec_header(s, s->streams[i]->codecpar, 0);
>> >  }
>> >
>>
>> Is it customary that even if you've got a live stream going, that the
>> start point of a given ingest is always zero? In that case you might
>> want to take mention of the initial dts, and then write offsets
>> compared to that? Otherwise if you have an initial offset of, say, 5s,
>> and then you a 5s GOP with an update, then while the difference to the
>> initial timestamp would be 5s, using the original dts field you would
>> get the second header having a value of 10s there. Or am I
>> misunderstanding something here?
>
> The FLV file (on disk) format requires the initial DTS to be zero. For FLV
> over RTMP this is not the case.
>

Oh, interesting... makes sense, of course, for continuing a stream
relative to the last timestamp of the previous ingest.

> At one point the flv muxer handled that itself, but that changed to handle
> copyts better.[2]
>
> For non-zero starting DTS should header packets have non-zero
> timestamp? Maybe but that's the case irrespective of weather or
> not we offset late extradata. Meanwhile many popular demuxers
> (avformat included) special case initial extradata.

Interesting, so in theory we should be making the initial
initialization data to be according to the DTS according to your
reading? Or is the initial extradata packet always supposed to be
zero, irrelevant of the actual initial content DTS?

As soon as these questions can be answered I think we've got the ball
rolling on getting this in. As I mentioned already, this is an
improvement.


Best regards,
Jan
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] flvenc: Fix sequence header update timestamps

[Jan Ekström]

On Fri, May 11, 2018 at 1:48 AM, Alex Converse  wrote:
>
> Sorry about the lateness on my part. Were there any later comments. I
> haven't seen any. (And yes I can push this myself when all the
> concerns are resolved).

It's OK, it has been a rather busy time for me as well.

I was already thinking if you had given up on this and if I should
just apply the changes I thought were correct and re-post it for
review myself:
* making the function take in int64_t.
* DTS is most likely what's wanted so no change there.
* most likely FLV never used negative timestamps (even though the
value is signed) so:
  1.wrap-around at the 31 bits for the signed integer value, and then
  2. keep the 0x7F because the topmost bit of a signed field would
never be used.
* try to figure out if the initial metadata packet should specifically
be starting with a zero timestamp, or the initial DTS of the input?

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

Re: [FFmpeg-devel] [PATCH 1/2] avformat/dashenc: Added option for Segment file format

[Jan Ekström]

On Fri, May 4, 2018 at 9:32 AM, Karthick J  wrote:
> From: Karthick Jeyapal 
>
> Right now segment file format is chosen to be either mp4 or webm based on the 
> codec format.
> This patch makes that choice configurable by the user, instead of being 
> decided by the muxer.
> ---
>  doc/muxers.texi   |  8 
>  libavformat/dashenc.c | 48 ++--
>  2 files changed, 30 insertions(+), 26 deletions(-)
>

Hi,

Sorry for getting to this so late, been busy on various things (as
usual). Thanks for prodding me.

> diff --git a/doc/muxers.texi b/doc/muxers.texi
> index 6f03bba..2429f8e 100644
> --- a/doc/muxers.texi
> +++ b/doc/muxers.texi
> @@ -282,6 +282,14 @@ corrects that index value.
>  Typically this logic is needed in live streaming use cases. The network 
> bandwidth
>  fluctuations are common during long run streaming. Each fluctuation can cause
>  the segment indexes fall behind the expected real time position.
> +
> +@item dash_segment_type @var{dash_segment_type}
> +Possible values:
> +@item mp4
> +If this flag is set, the dash segment files will be in in ISOBMFF format. 
> This is the default format.
> +
> +@item webm
> +If this flag is set, the dash segment files will be in in WebM format.
>  @end table
>
>  @anchor{framecrc}
> diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c
> index 1dd6333..412f074 100644
> --- a/libavformat/dashenc.c
> +++ b/libavformat/dashenc.c
> @@ -48,6 +48,11 @@
>  #include "vpcc.h"
>  #include "dash.h"
>
> +typedef enum {
> +SEGMENT_TYPE_MP4,
> +SEGMENT_TYPE_WEBM,
> +} SegmentType;
> +

Ah yes, an enum :) I really like the checks being equality/inequality
now. I've seen things like SEGMENT_TYPE_NB used for the stopper so
that in the AVOption you can then set the maximum to *_NB - 1 instead
of then having to change it if it ever gets anything added to it.

Maybe consider making something like the `codecs[]` array for formats
and make the thing in DASHContext as a char pointer, so that you can
just point the string pointer to its value in init() instead of doing
a run-time strncpy.

This does remove the "dynamicness" of  the per-stream selection, which
possibly should be mentioned. But at least personally I think this is
what people actually wanted with WebM vs ISOBMFF DASH selection ;) ,
as in not having surprises between streams.

Otherwise this patch generally looks alright, leaving just the segment
file name part not automatical just yet :) (I feel like we need to
have separate options for the general template and the extension).

Best regards,
Jan
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 2/2] flvenc: Fix sequence header update timestamps

[Jan Ekström]

On Fri, May 11, 2018 at 4:40 AM, Alex Converse  wrote:
> From: Alex Converse 
>
> ---
>  libavformat/flvenc.c | 9 -
>  1 file changed, 4 insertions(+), 5 deletions(-)
>
> diff --git a/libavformat/flvenc.c b/libavformat/flvenc.c
> index 9b7cdfe7db..7aa2dbf9a6 100644
> --- a/libavformat/flvenc.c
> +++ b/libavformat/flvenc.c
> @@ -485,7 +485,7 @@ static int unsupported_codec(AVFormatContext *s,
>  return AVERROR(ENOSYS);
>  }
>
> -static void flv_write_codec_header(AVFormatContext* s, AVCodecParameters* 
> par) {
> +static void flv_write_codec_header(AVFormatContext* s, AVCodecParameters* 
> par, unsigned ts) {
>  int64_t data_size;
>  AVIOContext *pb = s->pb;
>  FLVContext *flv = s->priv_data;
> @@ -497,8 +497,7 @@ static void flv_write_codec_header(AVFormatContext* s, 
> AVCodecParameters* par) {
>  par->codec_type == AVMEDIA_TYPE_VIDEO ?
>  FLV_TAG_TYPE_VIDEO : FLV_TAG_TYPE_AUDIO);
>  avio_wb24(pb, 0); // size patched later
> -avio_wb24(pb, 0); // ts
> -avio_w8(pb, 0);   // ts ext
> +put_timestamp(pb, ts);
>  avio_wb24(pb, 0); // streamid
>  pos = avio_tell(pb);
>  if (par->codec_id == AV_CODEC_ID_AAC) {
> @@ -761,7 +760,7 @@ static int flv_write_header(AVFormatContext *s)
>  }
>
>  for (i = 0; i < s->nb_streams; i++) {
> -flv_write_codec_header(s, s->streams[i]->codecpar);
> +flv_write_codec_header(s, s->streams[i]->codecpar, 0);
>  }
>
>  flv->datastart_offset = avio_tell(pb);
> @@ -905,7 +904,7 @@ static int flv_write_packet(AVFormatContext *s, AVPacket 
> *pkt)
>  }
>  memcpy(par->extradata, side, side_size);
>  par->extradata_size = side_size;
> -flv_write_codec_header(s, par);
> +flv_write_codec_header(s, par, (unsigned)pkt->dts);
>  }
>  }
>

Yes, this will get rid of the possible warning by casting, but you're
still dealing with system specifically sized variables, so you might
be doing int64_t ->uint64_t or int64_t->uint32_t.

I have no idea why the aversion of just using the same type in
`flv_write_codec_header` as what the DTS is (int64_t)? And why are we
completely ignoring the fact that FLV has timestamp wrap-arounds? Or
does this update header not care about that?

Best regards,
Jan
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 2/2] flvenc: Fix sequence header update timestamps

[Jan Ekström]

On Sun, May 13, 2018 at 12:25 PM, Jan Ekström <jee...@gmail.com> wrote:
> On Fri, May 11, 2018 at 4:40 AM, Alex Converse <alex.conve...@gmail.com> 
> wrote:
>> From: Alex Converse <alexc...@twitch.tv>
>>
>> ---
>>  libavformat/flvenc.c | 9 -
>>  1 file changed, 4 insertions(+), 5 deletions(-)
>>
>> diff --git a/libavformat/flvenc.c b/libavformat/flvenc.c
>> index 9b7cdfe7db..7aa2dbf9a6 100644
>> --- a/libavformat/flvenc.c
>> +++ b/libavformat/flvenc.c
>> @@ -485,7 +485,7 @@ static int unsupported_codec(AVFormatContext *s,
>>  return AVERROR(ENOSYS);
>>  }
>>
>> -static void flv_write_codec_header(AVFormatContext* s, AVCodecParameters* 
>> par) {
>> +static void flv_write_codec_header(AVFormatContext* s, AVCodecParameters* 
>> par, unsigned ts) {
>>  int64_t data_size;
>>  AVIOContext *pb = s->pb;
>>  FLVContext *flv = s->priv_data;
>> @@ -497,8 +497,7 @@ static void flv_write_codec_header(AVFormatContext* s, 
>> AVCodecParameters* par) {
>>  par->codec_type == AVMEDIA_TYPE_VIDEO ?
>>  FLV_TAG_TYPE_VIDEO : FLV_TAG_TYPE_AUDIO);
>>  avio_wb24(pb, 0); // size patched later
>> -avio_wb24(pb, 0); // ts
>> -avio_w8(pb, 0);   // ts ext
>> +put_timestamp(pb, ts);
>>  avio_wb24(pb, 0); // streamid
>>  pos = avio_tell(pb);
>>  if (par->codec_id == AV_CODEC_ID_AAC) {
>> @@ -761,7 +760,7 @@ static int flv_write_header(AVFormatContext *s)
>>  }
>>
>>  for (i = 0; i < s->nb_streams; i++) {
>> -flv_write_codec_header(s, s->streams[i]->codecpar);
>> +flv_write_codec_header(s, s->streams[i]->codecpar, 0);
>>  }
>>
>>  flv->datastart_offset = avio_tell(pb);
>> @@ -905,7 +904,7 @@ static int flv_write_packet(AVFormatContext *s, AVPacket 
>> *pkt)
>>  }
>>  memcpy(par->extradata, side, side_size);
>>  par->extradata_size = side_size;
>> -flv_write_codec_header(s, par);
>> +flv_write_codec_header(s, par, (unsigned)pkt->dts);
>>  }
>>  }
>>
>
> Yes, this will get rid of the possible warning by casting, but you're
> still dealing with system specifically sized variables, so you might
> be doing int64_t ->uint64_t or int64_t->uint32_t.
>
> I have no idea why the aversion of just using the same type in
> `flv_write_codec_header` as what the DTS is (int64_t)? And why are we
> completely ignoring the fact that FLV has timestamp wrap-arounds? Or
> does this update header not care about that?
>
> Best regards,
> Jan

Hi,

OK, seemingly I'm the bad guy here and all such technical issues in
new code (including old modules) should just be ignored if it's just
copying stuff from the same place that is not fit for our coding
standards.

My original intention was to make sure that Alex's patch doesn't get
ignored and that it could have a nice review which could be handled in
a single or two iterations by looking into how FLV works and fixing up
some minor things like the int64_t->unsigned case. My idea was not to
fix other parts of flvenc, but just at the very least getting the
information on how to fix it fully afterwards if indeed some copied
code seemingly did things incorrectly, and just making this part as an
example of how to do that in the future.

And now it seems like these intentions went the wrong way, and most of
the people on IRC seem to say that since this same way was used in
flvenc before (int64_t->unsigned), it could be used again in newly
added code.

OK, I will not be a nuisance in this thread any more and any technical
notes I made here can be considered moot since I seem to have come out
as just being an asshole to Alex. I am sorry. That was never my
intention.

Best regards,
Jan
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] configure: fix configure check for lilv-0

[Jan Ekström]

On Sun, May 13, 2018 at 6:07 PM, Niklas Haas  wrote:
> From: Niklas Haas 
>
> This should be included as ``, same as is done in af_lv2.c.
> Forcing the extra lilv-0 breaks platforms where the include dir is
> `/usr/include/lilv/lilv.h` rather than
> `/usr/include/lilv-0/lilv/lilv.h`.
>
> The new include path works for both, because the `pkg-config --cflags`
> includes `-I/usr/include/lilv-0`.
> ---
>  configure | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/configure b/configure
> index a1f13a7109..451d1937b7 100755
> --- a/configure
> +++ b/configure
> @@ -5973,7 +5973,7 @@ enabled gnutls&& require_pkg_config gnutls 
> gnutls gnutls/gnutls.h gn
>  enabled jni   && { [ $target_os = "android" ] && check_header 
> jni.h && enabled pthreads || die "ERROR: jni not found"; }
>  enabled ladspa&& require_header ladspa.h
>  enabled libaom&& require_pkg_config libaom "aom >= 0.1.0" 
> aom/aom_codec.h aom_codec_version
> -enabled lv2   && require_pkg_config lv2 lilv-0 
> "lilv-0/lilv/lilv.h" lilv_world_new
> +enabled lv2   && require_pkg_config lv2 lilv-0 "lilv/lilv.h" 
> lilv_world_new
>  enabled libiec61883   && require libiec61883 libiec61883/iec61883.h 
> iec61883_cmp_connect -lraw1394 -lavc1394 -lrom1394 -liec61883
>  enabled libass&& require_pkg_config libass libass ass/ass.h 
> ass_library_init
>  enabled libbluray && require_pkg_config libbluray libbluray 
> libbluray/bluray.h bd_open
> --
> 2.17.0
>

Generally looks good, CC'ing Paul so he can verify that it still
builds for him as well.

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

Re: [FFmpeg-devel] [PATCH] configure: fix configure check for lilv-0

[Jan Ekström]

On Sun, May 13, 2018 at 7:12 PM, Paul B Mahol  wrote:
> On 5/13/18, Jan Ekstroem  wrote:
>> On Sun, May 13, 2018 at 6:52 PM, Paul B Mahol  wrote:
>>> On 5/13/18, Niklas Haas  wrote:
 From: Niklas Haas 

 This should be included as ``, same as is done in af_lv2.c.
 Forcing the extra lilv-0 breaks platforms where the include dir is
 `/usr/include/lilv/lilv.h` rather than
 `/usr/include/lilv-0/lilv/lilv.h`.

 The new include path works for both, because the `pkg-config --cflags`
 includes `-I/usr/include/lilv-0`.
 ---
  configure | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

>>>
>>> lgtm
>>
>> Thank you. Pushed in.
>>
>> Should this be back-ported to release/4.0 as well?
>
> If you care.

You may say that I do not care, but I have this still vivid in my
memory and I would guess you would like your filter to build better in
releases as well.


Best regards,
Jan
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/1] configure: add pkg-config check for libmysofa

[Jan Ekström]

On Sun, May 13, 2018 at 7:11 PM, Paul B Mahol  wrote:
> On 5/13/18, Reino Wijnsma  wrote:
>> *ping*
>
> Could you wait for new libmysofa release?

Hi,

I think this depends on whether this breaks build where it used to
work before. As you may notice, it still has the non-pkg-config
fall-back. So if the test doesn't link (I think this check tests for
linking?), it should revert to the non-pkg-config one.

Unfortunately I do not have libmysofa installed so I cannot verify
this myself, but it heavily looks like this actually is an overall
improvement, esp. if they are not going to change the name of the pc
file.


Best regards,
Jan
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] configure: fix configure check for lilv-0

[Jan Ekström]

On Sun, May 13, 2018 at 7:12 PM, Paul B Mahol  wrote:
> On 5/13/18, Jan Ekstroem  wrote:
>> On Sun, May 13, 2018 at 6:52 PM, Paul B Mahol  wrote:
>>> On 5/13/18, Niklas Haas  wrote:
 From: Niklas Haas 

 This should be included as ``, same as is done in af_lv2.c.
 Forcing the extra lilv-0 breaks platforms where the include dir is
 `/usr/include/lilv/lilv.h` rather than
 `/usr/include/lilv-0/lilv/lilv.h`.

 The new include path works for both, because the `pkg-config --cflags`
 includes `-I/usr/include/lilv-0`.
 ---
  configure | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

>>>
>>> lgtm
>>
>> Thank you. Pushed in.
>>
>> Should this be back-ported to release/4.0 as well?
>
> If you care.

And thus, back-ported to release/4.0.

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

Re: [FFmpeg-devel] [PATCH] configure: fix configure check for lilv-0

[Jan Ekström]

On Sun, May 13, 2018 at 6:52 PM, Paul B Mahol  wrote:
> On 5/13/18, Niklas Haas  wrote:
>> From: Niklas Haas 
>>
>> This should be included as ``, same as is done in af_lv2.c.
>> Forcing the extra lilv-0 breaks platforms where the include dir is
>> `/usr/include/lilv/lilv.h` rather than
>> `/usr/include/lilv-0/lilv/lilv.h`.
>>
>> The new include path works for both, because the `pkg-config --cflags`
>> includes `-I/usr/include/lilv-0`.
>> ---
>>  configure | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>
> lgtm

Thank you. Pushed in.

Should this be back-ported to release/4.0 as well?

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

[FFmpeg-devel] [PATCH] configure: add pkg-config check for zlib

[Jan Ekström]

It exists, so why not use it? Helps one get rid of additional
search path related flags in addition to PKG_CONFIG_{PATH,LIBDIR}
when utilizing a cross-prefix separate from the sysroot.
---
 configure | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/configure b/configure
index f78853cc6c..2d99c8ea85 100755
--- a/configure
+++ b/configure
@@ -5933,7 +5933,8 @@ if ! disabled pthreads && ! enabled w32threads && ! 
enabled os2threads; then
 fi
 fi
 
-enabled  zlib && check_lib zlib   zlib.h  zlibVersion-lz
+enabled  zlib && { check_pkg_config zlib zlib "zlib.h" zlibVersion ||
+   check_lib zlib   zlib.h  zlibVersion-lz; }
 enabled bzlib && check_lib bzlib bzlib.h BZ2_bzlibVersion-lbz2
 enabled  lzma && check_lib lzma   lzma.h lzma_version_number -llzma
 
-- 
2.17.0

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

Re: [FFmpeg-devel] [PATCH v4 1/3] avformat: add fields to AVProgram/AVStream for PMT change tracking

[Jan Ekström]

On Sun, May 20, 2018 at 1:54 PM, Carl Eugen Hoyos  wrote:
>
> Reading the original submission above, isn't the whole point of the
> patch to add public symbols to help downstream with real-world
> issues?
>
> Carl Eugen

Yes, currently the API user has no visibility over how the programs
are being updated. Two alternative takes on this were listed in the
commit message, one being a call-back and another being a custom data
packet from stream id 0.

So yes, the pmt_version is most definitely meant to be publicly
utilized, with it the proper utilization would go as follows:
1) API client picks the program(s) it cares about, and gets the
AVProgram(s)' pointers and notes the pmt_version when it started
reading.
2) After each AVPacket read, it checks if the pmt_version was updated.
If it was, it iterates over the streams currently registered in the
AVProgram(s) it cares about.
3) If any streams got dropped, those should be no longer cared about
by the API client. If any streams got added, they should be checked by
the API client if it is interested in them.

This is an upgrade on the previous state of affairs which would have
required the following:
1) API client picks the program(s) it cares about, and gets the
AVProgram(s)' pointers.
2) After each AVPacket read, it iterates over the streams currently
registered in the AVProgram(s) it cares about.
3) If any streams got dropped, those should be no longer cared about
by the API client. If any streams got added, they should be checked by
the API client if it is interested in them.

It is not perfect, but still an upgrade, since you can just check an
integer now, instead of doing the full iteration every time you read
an AVPacket.


Best regards,
Jan
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v4 1/3] avformat: add fields to AVProgram/AVStream for PMT change tracking

[Jan Ekström]

On Sun, May 20, 2018 at 2:06 PM, Jan Ekström <jee...@gmail.com> wrote:
> On Sun, May 20, 2018 at 1:54 PM, Carl Eugen Hoyos <ceffm...@gmail.com> wrote:
>>
>> Reading the original submission above, isn't the whole point of the
>> patch to add public symbols to help downstream with real-world
>> issues?
>>
>> Carl Eugen
>
> Yes, currently the API user has no visibility over how the programs
> are being updated. Two alternative takes on this were listed in the
> commit message, one being a call-back and another being a custom data
> packet from stream id 0.
>
> So yes, the pmt_version is most definitely meant to be publicly
> utilized, with it the proper utilization would go as follows:
> 1) API client picks the program(s) it cares about, and gets the
> AVProgram(s)' pointers and notes the pmt_version when it started
> reading.
> 2) After each AVPacket read, it checks if the pmt_version was updated.
> If it was, it iterates over the streams currently registered in the
> AVProgram(s) it cares about.
> 3) If any streams got dropped, those should be no longer cared about
> by the API client. If any streams got added, they should be checked by
> the API client if it is interested in them.
>
> This is an upgrade on the previous state of affairs which would have
> required the following:
> 1) API client picks the program(s) it cares about, and gets the
> AVProgram(s)' pointers.
> 2) After each AVPacket read, it iterates over the streams currently
> registered in the AVProgram(s) it cares about.
> 3) If any streams got dropped, those should be no longer cared about
> by the API client. If any streams got added, they should be checked by
> the API client if it is interested in them.
>
> It is not perfect, but still an upgrade, since you can just check an
> integer now, instead of doing the full iteration every time you read
> an AVPacket.
>
>
> Best regards,
> Jan

Oh, and I'm not sure if lavf's internal reordering of packets could
make it happen that you receive the program update, and then still
receive one or more packets from the previous stream. In that case you
might also incorporate some check that the flush and reset of previous
decoder only happens after you get your first new packet for that new
stream.

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

Re: [FFmpeg-devel] [RFC][ALT PATCHES] Code of Conduct Enforcement

[Jan Ekström]

On Mon, May 14, 2018 at 7:50 PM, Derek Buitenhuis
 wrote:
>
> So, I present to you two possible options:
>
> 1. Implement a formal CoC enforcement system. This has been mostly 
> copypasted
>from VideoLAN's, and is meant as more of a blueprint. This will no 
> doubt
>be controversial.
> 2. Remove the CoC. If you're not going to enforce it, ever, there is 
> literally
>no point in having one. I know some members of this community object 
> to the
>very notion of a CoC, so this should please them, I am sure.
>
> I'm sure this will be a civil discussion.

Hi,

Just voicing my opinion as a community member. Out of these two
examples (which they are) I'm preferring nr1, the CoC should be
improved (or a VideoLAN style one adopted) and we should make an
effort to try and minimize the amount of rudeness and bad behaviour in
this project.

Removing the CoC sounds to me like either we don't agree with the
notion of being civil with each other, or that we just can't as a
community handle civil discourse. Both of those alternatives make me
rather sad.

I know a lot of people want to just focus on the technical parts, and
in a perfect world we would be able to not have personal problems -
but I think we don't have a healthy community right now.

Of course, I am also fully aware that fixing the issues is going to
take way more than just applying a more specific CoC.

Best regards,
Jan
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avformat/mpegts: add merge_pmt_versions option

[Jan Ekström]

On Tue, May 15, 2018, 15:12 Michael Niedermayer 
wrote:

> On Mon, May 14, 2018 at 03:54:01PM -0700, Aman Gupta wrote:
> > From: Aman Gupta 
> >
> > This new optional flag makes it easier to deal with mpegts
> > samples where the PMT is updated and elementary streams move
> > to different PIDs in the middle of playback.
> >
> > Previously, new AVStreams were created per PID, and it was up
> > to the user to figure out which streams had migrated to a new PID
> > (by iterating over the list of AVProgram and making guesses), and
> > switch seamlessly to the new AVStream during playback.
> >
> > Transcoding or remuxing these streams with ffmpeg on the CLI was
> > also quite painful, and the user would need to extract each set of
> > PIDs into a separate file and then stitch them back together.
> >
> > With this new option, the mpegts demuxer will automatically detect
> > PMT changes and feed data from the new PID to the original AVStream
> > that was created for the orignal PID. For mpegts samples with
> > stream_identifier_descriptor available, the unique ID is used to merge
> > PIDs together. If the stream id is not available, the demuxer attempts
> > to map PIDs based on their order and relation to the PCR pid.
> >
> > With this change, I am able to playback and transcode/remux these
> > two samples which previously caused issues:
> >
> > https://tmm1.s3.amazonaws.com/pmt-version-change.ts
> > https://kuroko.fushizen.eu/videos/pid_switch_sample.ts
> >
> > I also have another longer sample which contains multiple PMT
> > changes, some of which change the ES pids and others which do not:
> >
> > https://tmm1.s3.amazonaws.com/multiple-pmt-change.ts
> >
> > Demuxing this sample with the new option shows several new log
> > messages as the PMT changes are handled:
> >
> > [mpegts @ 0x7ffe18801200] detected PMT change (version=3/4,
> pcr_pid=0xf98/0xf9b)
> > [mpegts @ 0x7ffe18801200] re-using existing video stream 0
> (pid=0xf98) for new pid=0xf9b
> > [mpegts @ 0x7ffe18801200] re-using existing audio stream 1
> (pid=0xf99) for new pid=0xf9c
> > [mpegts @ 0x7ffe18801200] re-using existing audio stream 2
> (pid=0xf9a) for new pid=0xf9d
> > [mpegts @ 0x7ffe18801200] detected PMT change (version=4/5,
> pcr_pid=0xf9b/0xfa9)
> > [mpegts @ 0x7ffe18801200] re-using existing video stream 0
> (pid=0xf98) for new pid=0xfa9
> > [mpegts @ 0x7ffe18801200] re-using existing audio stream 1
> (pid=0xf99) for new pid=0xfaa
> > [mpegts @ 0x7ffe18801200] re-using existing audio stream 2
> (pid=0xf9a) for new pid=0xfab
>
> This sounds like an interresting feature
> this should also get a fate test
>

It is not the "real" solution, as we still need a flag for PMT updates in
AVProgram, or a callback for updated programs - so that API clients can
handle all this properly dynamically.

But, I do find this an interesting way of handling some cases of PID
switch. And under an AVOption it will not break any expectations by default.


>
> >
> > Signed-off-by: Aman Gupta 
> > ---
> >  doc/demuxers.texi|   4 ++
> >  libavformat/mpegts.c | 105
> +--
> >  2 files changed, 105 insertions(+), 4 deletions(-)
> >
> > diff --git a/doc/demuxers.texi b/doc/demuxers.texi
> > index e7c2abce57..2f7d7e0f3a 100644
> > --- a/doc/demuxers.texi
> > +++ b/doc/demuxers.texi
> > @@ -552,6 +552,10 @@ Show the detected raw packet size, cannot be set by
> the user.
> >  Scan and combine all PMTs. The value is an integer with value from -1
> >  to 1 (-1 means automatic setting, 1 means enabled, 0 means
> >  disabled). Default value is -1.
> > +
> > +@item merge_pmt_versions
> > +Re-use existing streams when a PMT's version is updated and elementary
> > +streams move to different PIDs. Default value is 0.
> >  @end table
> >
> >  @section mpjpeg
> > diff --git a/libavformat/mpegts.c b/libavformat/mpegts.c
> > index 27b1c30a44..c42e564a7e 100644
> > --- a/libavformat/mpegts.c
> > +++ b/libavformat/mpegts.c
> > @@ -84,6 +84,8 @@ typedef struct MpegTSSectionFilter {
> >  unsigned int end_of_section_reached : 1;
> >  SectionCallback *section_cb;
> >  void *opaque;
> > +int orig_pcr_pid; /* pmt specific */
> > +int last_pcr_pid;
> >  } MpegTSSectionFilter;
> >
> >  struct MpegTSFilter {
> > @@ -147,6 +149,7 @@ struct MpegTSContext {
> >  int scan_all_pmts;
> >
> >  int resync_size;
> > +int merge_pmt_versions;
> >
> >  /**/
> >  /* private mpegts data */
> > @@ -172,6 +175,8 @@ static const AVOption options[] = {
> >   {.i64 = 0}, 0, 0, AV_OPT_FLAG_DECODING_PARAM | AV_OPT_FLAG_EXPORT
> | AV_OPT_FLAG_READONLY },
> >  {"scan_all_pmts", "scan and combine all PMTs",
> offsetof(MpegTSContext, scan_all_pmts), AV_OPT_TYPE_BOOL,
> >   {.i64 = -1}, -1, 1, AV_OPT_FLAG_DECODING_PARAM },
> > +{"merge_pmt_versions", "re-use streams when PMT's 

Re: [FFmpeg-devel] [RFC] libfdk_aac license

[Jan Ekström]

On Sat, Jun 9, 2018 at 11:00 PM, Carl Eugen Hoyos  wrote:
> 2018-05-29 6:53 GMT+02:00, Gyan Doshi :
>>
>> On 29-05-2018 03:34 AM, Carl Eugen Hoyos wrote:
>>
>>> Just remove "and is not known...",
>
>>> please don't state that you guarantee
>>> they are compatible.
>
> Where should we sent people who trust what you wrote in the
> documentation but had to find out it isn't correct?
>
>> If we are continuing to permit LGPL compilation, shouldn't it be
>>
>> "The Fraunhofer AAC library is licensed under a license incompatible
>>   to the GPL. Therefore, for GPL builds, you have to pass
>>   @code{--enable-nonfree} to configure to use it.
>
>> To the best of our knowledge, it is compatible with the LGPL" ?
>
> I am curious because of your follow-up in another thread:
> Why do you think it is compatible?
>
> Carl Eugen

IANAL, but here goes:

I think the general idea was that since LGPL lets you link an LGPL
library in a proprietary piece of software (given that you follow the
spirit and language of LGPL by letting people build the same version
and making it possible for the built version to be loaded up in the
proprietary application), it probably works the other way as well. If
you have a proprietary module that you have provided the necessary
means to link against, an LGPL piece of software can utilize that as
long as the LGPL part of the deal is kept. Of course the means to
build this mish-mash is also to be provided to the user. I think
VideoLAN's or FSF's or so lawyers looked into this before, although I
might be incorrect. That is why non-free libraries tend to only be
requiring a special flag that makes the result non-distributable if
you don't enable GPL modules.

Of course, the requirement for fdk-aac has lessened after the internal
AAC encoder improved, but I still think some people are into it for
one reason or another. Too bad its license is just incompatible with
GPL (unless you remove all of the currently-still-patented stuff, I
guess, since the license's "additional restraints" were dealing with
patents. Which was the reading of the Red Hat lawyers - although I'm
not sure what if anything at all they're linking against it in
Fedora).

Best regards,
Jan
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] fftools/ffmpeg_opt: Add -toeof option to stop writing relative to EOF

[Jan Ekström]

On Sun, Jun 10, 2018 at 10:39 PM, Morten With  wrote:
> As Gyan clarified, this only affects one input file. Help text has been
> modified as per Gyan's instructions (not yet submitted).
>
> This feature was specifically requested here (and I had the same issue as
> the one who opened the ticket): https://trac.ffmpeg.org/ticket/7155
>
> I think it's a lot cleaner to just solve this with one ffmpeg command
> without any external scripting math, since ffmpeg knows the duration of the
> file internally anyway. Otherwise, why would -sseof exist?
>

Yes, programmatic things for things like these are often better. That
said, the question regarding sseof can be answered by "the person who
merged this stuff was OK with all the asterisks/caveats around it".

Think of MPEG-TS, for example. I think - quite a bit simplified - it
basically parses the timestamps until it finishes probing, and then
extrapolates according to the size/bit rate of the file. That might be
close, or that might be not close at all. At the end of the day, the
libraries in FFmpeg are very much based on A->B access, not
frame-exactness in access or figuring out the full length of a media
file with any sort of precision. Of course, this doesn't mean that
this base feature set cannot be utilized to gain such features - ffms2
(https://github.com/FFMS/ffms2/) is one example of this, which is a
wrapper around FFmpeg's libraries that indexes the file, and then
provides you (unless you hit a bug or special case) frame-exact access
to the contents.

Many people have their own use cases for various things and have
enough leverage to get things that specifically work for their use
case into the code base, which is why in the end we have three
different ways of doing concatenation in the libraries (instead of
implementing it in the API client), each with their own caveats
(protocol, demuxer, filter). And the users will trust these features,
and attempt to utilize them for their own use cases. That, in various
cases, can lead to things just not working, as often the caveats are
not mentioned and the attempted use cases are different from what
those features were originally designed for.


Best regards,
Jan
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] fix ftp hang up because not return AVRRROR_EOF

[Jan Ekström]

On Wed, Jun 13, 2018 at 1:27 PM, Gj X  wrote:
> fix:
> diff --git a/libavformat/ftp.c b/libavformat/ftp.c
> index 9aa7a45629..3474a0adbc 100644
> --- a/libavformat/ftp.c
> +++ b/libavformat/ftp.c
> @@ -777,7 +777,11 @@ static int ftp_read(URLContext *h, unsigned char *buf,
> int size)
>  {
>  FTPContext *s = h->priv_data;
>  int read, err, retry_done = 0;
> -
> +if(s->position >= s->filesize)
> +{
> +ff_dlog(h,"ftp protocol reach file end\n");
> +return AVERROR_EOF;
> +}
>  ff_dlog(h, "ftp protocol read %d bytes\n", size);
>retry:
>  if (s->state == DISCONNECTED) {
>

Hi,

Thanks for your contribution. I just looked at that function and it
seems like `ftp_read` needs some improvement.

But staying on the 0 != EOF fixup topic, probably something like this
should prod it to work:

diff --git a/libavformat/ftp.c b/libavformat/ftp.c
index 9aa7a45629..f07e9fcdd9 100644
--- a/libavformat/ftp.c
+++ b/libavformat/ftp.c
@@ -783,13 +783,13 @@ static int ftp_read(URLContext *h, unsigned char
*buf, int size)
 if (s->state == DISCONNECTED) {
 /* optimization */
 if (s->position >= s->filesize)
-return 0;
+return AVERROR_EOF;
 if ((err = ftp_connect_data_connection(h)) < 0)
 return err;
 }
 if (s->state == READY) {
 if (s->position >= s->filesize)
-return 0;
+return AVERROR_EOF;
 if ((err = ftp_retrieve(s)) < 0)
 return err;
 }
@@ -823,7 +823,7 @@ static int ftp_read(URLContext *h, unsigned char
*buf, int size)
 goto retry;
 }
 }
-return read;
+return read ? read : AVERROR_EOF;
 }

 av_log(h, AV_LOG_DEBUG, "FTP read failed\n");
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/2] avcodec/libzvbi-teletextdec: add support for selecting subtitle pages only

[Jan Ekström]

On Wed, Jun 13, 2018 at 12:47 PM, Carl Eugen Hoyos  wrote:
> 2018-05-06 23:05 GMT+02:00, Marton Balint :
>
>> +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.
>
> Shouldn't this default to "subtitle"? The current default is useless iirc.
>
> Carl Eugen

I think one of the major problems is that IIRC currently the receiving
end has no idea for which page a subtitle was received for (be it
image or text).

Not only would it let the default be * (in case someone wants to
render teletext on the screen in general), but also there are channels
where a single teletext stream has at least two or three different
subtitle pages, and if the API client would be able to distinguish
between them without making multiple decoder instances I'd think
that'd be neat.

Best regards,
Jan
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] lavf/libssh: translate a read of 0 to EOF

[Jan Ekström]

On Mon, May 28, 2018 at 2:16 PM, Nicolas George  wrote:
> Jan Ekström (2018-05-28):
>> Yet another case of forgotten 0 =! EOF translation.
>>
>> While the documentation for this specific synchronous read
>> function does not mention it, the documentation for
>> `sftp_async_read` documents it, as well as looking at the
>> implementation of this function leads one to find
>> `if (handle->eof) { return 0; }`.
>>
>> Reported by stnutt on IRC.
>
> LGTM.
>
> --
>   Nicolas George

Cheers.

Pushed and back-ported to release/4.0.

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

Re: [FFmpeg-devel] [PATCH v3 1/3] lavc,doc: add avs2 codec

[Jan Ekström]

On Wed, May 30, 2018 at 4:19 AM, hwren  wrote:
> Signed-off-by: hwren 
> ---
>  doc/APIchanges  | 3 +++
>  libavcodec/avcodec.h| 1 +
>  libavcodec/codec_desc.c | 7 +++
>  libavcodec/version.h| 4 ++--
>  4 files changed, 13 insertions(+), 2 deletions(-)
>
> diff --git a/doc/APIchanges b/doc/APIchanges
> index efe15ba..3d08bb9 100644
> --- a/doc/APIchanges
> +++ b/doc/APIchanges
> @@ -15,6 +15,9 @@ libavutil: 2017-10-21
>
>  API changes, most recent first:
>
> +2018-05-xx - xx - lavc 58.20.100 - avcodec.h
> +  Add AV_CODEC_ID_AVS2.
> +
>  2018-05-xx - xx - lavf 58.15.100 - avformat.h
>Add pmt_version field to AVProgram
>
> diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
> index fb0c6fa..ce5f307 100644
> --- a/libavcodec/avcodec.h
> +++ b/libavcodec/avcodec.h
> @@ -409,6 +409,7 @@ enum AVCodecID {
>  AV_CODEC_ID_DXV,
>  AV_CODEC_ID_SCREENPRESSO,
>  AV_CODEC_ID_RSCC,
> +AV_CODEC_ID_AVS2,
>
>  AV_CODEC_ID_Y41P = 0x8000,
>  AV_CODEC_ID_AVRP,
> diff --git a/libavcodec/codec_desc.c b/libavcodec/codec_desc.c
> index 79552a9..e85492e 100644
> --- a/libavcodec/codec_desc.c
> +++ b/libavcodec/codec_desc.c
> @@ -1395,6 +1395,13 @@ static const AVCodecDescriptor codec_descriptors[] = {
>  .props = AV_CODEC_PROP_LOSSLESS,
>  },
>  {
> +.id= AV_CODEC_ID_AVS2,
> +.type  = AVMEDIA_TYPE_VIDEO,
> +.name  = "avs2",
> +.long_name = NULL_IF_CONFIG_SMALL("AVS2/IEEE 1857.4"),
> +.props = AV_CODEC_PROP_LOSSY,
> +},

Hi,

Are there any reference sample sets available for GY/T 299.1-2016 aka
IEEE 1857.4 aka AVS2?

I tried to search around and while I found some info that 92 samples
were available on some semi-closed FTP, I couldn't really find any
real test samples that could make a reference test suite.

Best regards,
Jan
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] lavf/libssh: translate a read of 0 to EOF

[Jan Ekström]

On Mon, May 28, 2018, 03:21 Jan Ekström <jee...@gmail.com> wrote:

> Yet another case of forgotten 0 =! EOF translation.
>
> While the documentation for this specific synchronous read
> function does not mention it, the documentation for
> `sftp_async_read` documents it, as well as looking at the
> implementation of this function leads one to find
> `if (handle->eof) { return 0; }`.
>
> Reported by stnutt on IRC.
> ---
>  libavformat/libssh.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavformat/libssh.c b/libavformat/libssh.c
> index 9e3d4da45e..21474f0f0a 100644
> --- a/libavformat/libssh.c
> +++ b/libavformat/libssh.c
> @@ -295,7 +295,7 @@ static int libssh_read(URLContext *h, unsigned char
> *buf, int size)
>  av_log(libssh, AV_LOG_ERROR, "Read error.\n");
>  return AVERROR(EIO);
>  }
> -return bytes_read;
> +return bytes_read ? bytes_read : AVERROR_EOF;
>  }
>
>  static int libssh_write(URLContext *h, const unsigned char *buf, int size)
> --
> 2.17.0
>


During the time while I was sleeping I got a confirnation from the user
that this indeed fixes the issues with seeming freezing+constant cpu usage
with the sftp protocol.

In other words, if this looks OK to people, feel free to merge while I'm at
work and back-port to release/4.0


Jan

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

[FFmpeg-devel] [PATCH] lavfi/Makefile: move dnn_*.o under vf_srcnn

[Jan Ekström]

These files depend on libavformat, and the vf_srcnn filter
currently is the only thing utilizing these dnn_* files and
already happens to have a dependency on libavformat.

This fixes compilation in cases where libavformat is not a
dependency for libavfilter.

Reported by Kam_ on IRC.
---
 libavfilter/Makefile | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index 5bacd5b621..4303e80097 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -12,8 +12,6 @@ OBJS = allfilters.o   
  \
avfiltergraph.o  \
buffersink.o \
buffersrc.o  \
-   dnn_interface.o  \
-   dnn_backend_native.o \
drawutils.o  \
fifo.o   \
formats.o\
@@ -338,7 +336,7 @@ OBJS-$(CONFIG_SMARTBLUR_FILTER)  += 
vf_smartblur.o
 OBJS-$(CONFIG_SOBEL_FILTER)  += vf_convolution.o
 OBJS-$(CONFIG_SPLIT_FILTER)  += split.o
 OBJS-$(CONFIG_SPP_FILTER)+= vf_spp.o
-OBJS-$(CONFIG_SRCNN_FILTER)  += vf_srcnn.o
+OBJS-$(CONFIG_SRCNN_FILTER)  += vf_srcnn.o dnn_interface.o 
dnn_backend_native.o
 OBJS-$(CONFIG_SSIM_FILTER)   += vf_ssim.o framesync.o
 OBJS-$(CONFIG_STEREO3D_FILTER)   += vf_stereo3d.o
 OBJS-$(CONFIG_STREAMSELECT_FILTER)   += f_streamselect.o framesync.o
-- 
2.17.1

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

Re: [FFmpeg-devel] [PATCH] lavfi/Makefile: move dnn_*.o under vf_srcnn

[Jan Ekström]

On Sat, Jun 2, 2018 at 7:07 PM, Jan Ekström  wrote:
> These files depend on libavformat, and the vf_srcnn filter
> currently is the only thing utilizing these dnn_* files and
> already happens to have a dependency on libavformat.
>
> This fixes compilation in cases where libavformat is not a
> dependency for libavfilter.
>
> Reported by Kam_ on IRC.
> ---

Got two LGTMs on IRC, pushed to master.

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

[FFmpeg-devel] [PATCH] lavf/libssh: translate a read of 0 to EOF

[Jan Ekström]

Yet another case of forgotten 0 =! EOF translation.

While the documentation for this specific synchronous read
function does not mention it, the documentation for
`sftp_async_read` documents it, as well as looking at the
implementation of this function leads one to find
`if (handle->eof) { return 0; }`.

Reported by stnutt on IRC.
---
 libavformat/libssh.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavformat/libssh.c b/libavformat/libssh.c
index 9e3d4da45e..21474f0f0a 100644
--- a/libavformat/libssh.c
+++ b/libavformat/libssh.c
@@ -295,7 +295,7 @@ static int libssh_read(URLContext *h, unsigned char *buf, 
int size)
 av_log(libssh, AV_LOG_ERROR, "Read error.\n");
 return AVERROR(EIO);
 }
-return bytes_read;
+return bytes_read ? bytes_read : AVERROR_EOF;
 }
 
 static int libssh_write(URLContext *h, const unsigned char *buf, int size)
-- 
2.17.0

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

Re: [FFmpeg-devel] [PATCH v2 3/3] avformat/dashenc: Set mp4 as the default format for VP9

[Jan Ekström]

On Thu, Apr 26, 2018 at 12:00 PM, Jeyapal, Karthick  wrote:
>
>
> On 4/23/18 11:40 AM, Karthick J wrote:
>> From: Karthick Jeyapal 
>>
>> There is a separate muxer(webmdashenc.c) for supporting VP9+webm output in 
>> DASH.
>> Hence in this muxer we will focus on supporting VP9 in MP4
>> Have verified playout support of VP9+MP4 in Chrome and Firefox.
>> ---
>>  libavformat/dashenc.c | 3 +--
>>  1 file changed, 1 insertion(+), 2 deletions(-)
>>
>> diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c
>> index a5f58d4..211ef23 100644
>> --- a/libavformat/dashenc.c
>> +++ b/libavformat/dashenc.c
>> @@ -959,11 +959,10 @@ static int dash_init(AVFormatContext *s)
>>  if (!ctx)
>>  return AVERROR(ENOMEM);
>>
>> -// choose muxer based on codec: webm for VP8/9 and opus, mp4 
>> otherwise
>> +// choose muxer based on codec: webm for VP8 and opus, mp4 otherwise
>>  // note: os->format_name is also used as part of the mimetype of the
>>  //   representation, e.g. video/
>>  if (s->streams[i]->codecpar->codec_id == AV_CODEC_ID_VP8 ||
>> -s->streams[i]->codecpar->codec_id == AV_CODEC_ID_VP9 ||
>>  s->streams[i]->codecpar->codec_id == AV_CODEC_ID_OPUS ||
>>  s->streams[i]->codecpar->codec_id == AV_CODEC_ID_VORBIS) {
>>  snprintf(os->format_name, sizeof(os->format_name), "webm");
>
> Pushed the patchset
>

Hi,

First of all, I would prefer the patch to actually mention what it is
doing. It is removing the webm override from the muxer for VP9. There
is as far as I know no option to switch between modes in current git,
so the commit message is blindly misleading at best and just plain
trying to look harmless (in order to get a free pass) if taken the
wrong way. Not saying you meant it that way, but the commit message
does not say what it does as far as I can see.

Also the patch does not mention the reason why it is doing this other
than the fact that there's a separate webm DASH muxer. That is true,
but the real reason you were switching this default is because the
WebM mode does not work. Now, fixing segfaults is good. And, for the
record, I actually agree with the change since with the profile string
it works in dash.js on various browsers (Firefox, Chromium, Edge).

But begesus... If it is done like this you might as well be honest and
just remove the WebM mode! Because right now you left it there to
segfault for VP8, Opus, Vorbis. Another alternative would have been to
apply the small change to Rodger Combs's patch
(https://patchwork.ffmpeg.org/patch/7984/), which you even commented
on before! Maybe it still doesn't work in browsers, but at least it
would have gotten to that point.

Really, I am thankful that you are contributing, but I really do not
want to see things like these after long days of work when I have not
noticed or wasn't able to write a long reply. You waited for two days,
and pushed without reviews even though I had shown interest in the
patch in its first iteration. If you are interested in getting quick
comments from someone (including me when I am awake and available),
please join the IRC channel #ffmpeg-devel if only possible. Even if it
is just for pokes and links to patchwork towards someone who has shown
interest to related patches before. I try as much as possible to poke
relevant people when I post patches, and I would prefer it if others
would do that as well. We're not perfect and issues can and do go
through peoples' eyes (esp. if the change set is of the larger size
issues tend to get hidden in plain sight, unfortunately), but let's
try to make this work.

Best regards,
Jan

P.S. I am sorry if my way of speech came out bad, it is just past
midnight here and I was trying to get a reply to this written after
noticing this mail.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH 2/3] lavf/dashenc: require experimental mode to be enabled for WebM

[Jan Ekström]

It has not ever been working and has not been validated,
Additionally, mention that the segment file names should be changed
to end with webm instead of m4s, which is utilized for ISOBMFF
fragments.
---
 libavformat/dashenc.c | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c
index 4f8f61b704..45f7830aec 100644
--- a/libavformat/dashenc.c
+++ b/libavformat/dashenc.c
@@ -966,6 +966,16 @@ static int dash_init(AVFormatContext *s)
 s->streams[i]->codecpar->codec_id == AV_CODEC_ID_OPUS ||
 s->streams[i]->codecpar->codec_id == AV_CODEC_ID_VORBIS) {
 snprintf(os->format_name, sizeof(os->format_name), "webm");
+
+if (s->strict_std_compliance > FF_COMPLIANCE_EXPERIMENTAL) {
+av_log(s, AV_LOG_ERROR,
+   "WebM support in dashenc is experimental and has not "
+   "been validated. For testing purposes, make sure "
+   "to add -strict experimental and override "
+   "-init_seg_name and -media_seg_name to end with "
+   "the extension 'webm'.\n");
+return AVERROR(EINVAL);
+}
 } else {
 snprintf(os->format_name, sizeof(os->format_name), "mp4");
 }
-- 
2.17.0

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

[FFmpeg-devel] [PATCH 0/3] WebM in dashenc

[Jan Ekström]

Personally I would be for removal of the WebM muxing feature in dashenc
altogether, since the dashenc feature has never seemingly worked, and
since there is a whole separate WebM-specific DASH meta muxer in
webmdashenc.

But these patches should at least make the thing not crash, and put it
under FF_COMPLIANCE_EXPERIMENTAL strictness. That way nobody should be
accidentally utilizing it.

Jan Ekström (2):
  lavf/dashenc: require experimental mode to be enabled for WebM
  lavf/dashenc: pass standards compliance value to the internal context

Rodger Combs (1):
  lavf/dashenc: don't call flush_init_segment before
avformat_write_header

 libavformat/dashenc.c | 33 ++---
 1 file changed, 22 insertions(+), 11 deletions(-)

-- 
2.17.0

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

[FFmpeg-devel] [PATCH 3/3] lavf/dashenc: pass standards compliance value to the internal context

[Jan Ekström]

Enables one to test possibly nonstandard formats such as Opus or
FLAC in ISOBMFF, among other things.

This becomes much more useful if output segment format becomes an
option, or if the WebM segment feature gets removed.
---
 libavformat/dashenc.c | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c
index 45f7830aec..1dd633365d 100644
--- a/libavformat/dashenc.c
+++ b/libavformat/dashenc.c
@@ -983,10 +983,11 @@ static int dash_init(AVFormatContext *s)
 if (!ctx->oformat)
 return AVERROR_MUXER_NOT_FOUND;
 os->ctx = ctx;
-ctx->interrupt_callback = s->interrupt_callback;
-ctx->opaque = s->opaque;
-ctx->io_close   = s->io_close;
-ctx->io_open= s->io_open;
+ctx->interrupt_callback= s->interrupt_callback;
+ctx->opaque= s->opaque;
+ctx->io_close  = s->io_close;
+ctx->io_open   = s->io_open;
+ctx->strict_std_compliance = s->strict_std_compliance;
 
 if (!(st = avformat_new_stream(ctx, NULL)))
 return AVERROR(ENOMEM);
-- 
2.17.0

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

[FFmpeg-devel] [PATCH 1/3] lavf/dashenc: don't call flush_init_segment before avformat_write_header

[Jan Ekström]

From: Rodger Combs 

Fixes crash when muxing MKV-in-DASH
---
 libavformat/dashenc.c | 14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c
index 211ef23cb0..4f8f61b704 100644
--- a/libavformat/dashenc.c
+++ b/libavformat/dashenc.c
@@ -1026,13 +1026,6 @@ static int dash_init(AVFormatContext *s)
 
 av_log(s, AV_LOG_VERBOSE, "Representation %d init segment will be 
written to: %s\n", i, filename);
 
-// Flush init segment
-// except for mp4, since delay_moov is set and the init segment
-// is then flushed after the first packets
-if (strcmp(os->format_name, "mp4")) {
-flush_init_segment(s, os);
-}
-
 s->streams[i]->time_base = st->time_base;
 // If the muxer wants to shift timestamps, request to have them shifted
 // already before being handed to this muxer, so we don't have 
mismatches
@@ -1074,6 +1067,13 @@ static int dash_write_header(AVFormatContext *s)
 OutputStream *os = >streams[i];
 if ((ret = avformat_write_header(os->ctx, NULL)) < 0)
 return ret;
+
+// Flush init segment
+// Only for WebM segment, since for mp4 delay_moov is set and
+// the init segment is thus flushed after the first packets.
+if (strcmp(os->format_name, "mp4") &&
+(ret = flush_init_segment(s, os)) < 0)
+return ret;
 }
 return ret;
 }
-- 
2.17.0

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

Re: [FFmpeg-devel] [PATCH 0/3] WebM in dashenc

[Jan Ekström]

On Fri, Apr 27, 2018 at 3:51 AM, Jan Ekström <jee...@gmail.com> wrote:
> Personally I would be for removal of the WebM muxing feature in dashenc
> altogether, since the dashenc feature has never seemingly worked, and
> since there is a whole separate WebM-specific DASH meta muxer in
> webmdashenc.
>
> But these patches should at least make the thing not crash, and put it
> under FF_COMPLIANCE_EXPERIMENTAL strictness. That way nobody should be
> accidentally utilizing it.
>

Also, do note that the usefulness of the WebM mode in dashenc went way
down with 4c27a6fbfde12317bd7d10502d73fb74d566afc3 , which moves the
current primary format that would get utilized with WebM (VP9) out of
the A/V formats that would cause the meta muxer to pick WebM for that
track.

I am posting these patches purely so that I will not get called
someone who never sends out patches.


Good night,
Jan
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] flvenc: Fix sequence header update timestamps

[Jan Ekström]

On Thu, May 3, 2018 at 8:58 PM, Jan Ekström <jee...@gmail.com> wrote:
> On Thu, May 3, 2018 at 7:50 PM, Alex Converse <alex.conve...@gmail.com> wrote:
>> From: Alex Converse <alexc...@twitch.tv>
>>
>> ---
>>  libavformat/flvenc.c | 10 +-
>>  1 file changed, 5 insertions(+), 5 deletions(-)
>>
>> diff --git a/libavformat/flvenc.c b/libavformat/flvenc.c
>> index e8af48cb64..827d798a61 100644
>> --- a/libavformat/flvenc.c
>> +++ b/libavformat/flvenc.c
>> @@ -480,7 +480,7 @@ static int unsupported_codec(AVFormatContext *s,
>>  return AVERROR(ENOSYS);
>>  }
>>
>> -static void flv_write_codec_header(AVFormatContext* s, AVCodecParameters* 
>> par) {
>> +static void flv_write_codec_header(AVFormatContext* s, AVCodecParameters* 
>> par, unsigned int ts) {
>
> Hi,
>
> While the timestamp field is 8+24=32 bits, the DTS value is int64_ts.
> Thus, while I'm really bad at doing wrap-around logic, wouldn't it be
> something a la ´uint32_t wrapped_timestamp = (uint32_t)(ts %
> UINT32_MAX)`?
>
> Additionally, I did briefly go through E.4.1 (FLV Tag) in the spec and
> it doesn't really seem to define whether this value is PTS or DTS...
> Is this defined anywhere proper? Given FLV's age I wouldn't be
> surprised that the answer would be "effectively DTS", of course. But
> if you've seen what  Adobe's implementation writes with B-frames it'd
> be interesting to see.
>
>>  int64_t data_size;
>>  AVIOContext *pb = s->pb;
>>  FLVContext *flv = s->priv_data;
>> @@ -492,8 +492,8 @@ static void flv_write_codec_header(AVFormatContext* s, 
>> AVCodecParameters* par) {
>>  par->codec_type == AVMEDIA_TYPE_VIDEO ?
>>  FLV_TAG_TYPE_VIDEO : FLV_TAG_TYPE_AUDIO);
>>  avio_wb24(pb, 0); // size patched later
>> -avio_wb24(pb, 0); // ts
>> -avio_w8(pb, 0);   // ts ext
>> +avio_wb24(pb, ts & 0xFF);
>> +avio_w8(pb, (ts >> 24) & 0x7F);
>
> Looking at the spec this is bottom 24 bits of the timestamp and top 8,
> thus why is the second one not & 0xFF ?
>

D'oh, I should read better. "...to form a SI32 value". Thus, this is LGTM.

>>  avio_wb24(pb, 0); // streamid
>>  pos = avio_tell(pb);
>>  if (par->codec_id == AV_CODEC_ID_AAC) {
>> @@ -756,7 +756,7 @@ static int flv_write_header(AVFormatContext *s)
>>  }
>>
>>  for (i = 0; i < s->nb_streams; i++) {
>> -flv_write_codec_header(s, s->streams[i]->codecpar);
>> +flv_write_codec_header(s, s->streams[i]->codecpar, 0);
>>  }
>>
>
> Is it customary that even if you've got a live stream going, that the
> start point of a given ingest is always zero? In that case you might
> want to take mention of the initial dts, and then write offsets
> compared to that? Otherwise if you have an initial offset of, say, 5s,
> and then you a 5s GOP with an update, then while the difference to the
> initial timestamp would be 5s, using the original dts field you would
> get the second header having a value of 10s there. Or am I
> misunderstanding something here?
>
> Otherwise, looks like a nice improvement in the implementation.
>
>
> Best regards,
> Jan

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

Re: [FFmpeg-devel] [PATCH] flvenc: Fix sequence header update timestamps

[Jan Ekström]

On Thu, May 3, 2018 at 7:50 PM, Alex Converse  wrote:
> From: Alex Converse 
>
> ---
>  libavformat/flvenc.c | 10 +-
>  1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/libavformat/flvenc.c b/libavformat/flvenc.c
> index e8af48cb64..827d798a61 100644
> --- a/libavformat/flvenc.c
> +++ b/libavformat/flvenc.c
> @@ -480,7 +480,7 @@ static int unsupported_codec(AVFormatContext *s,
>  return AVERROR(ENOSYS);
>  }
>
> -static void flv_write_codec_header(AVFormatContext* s, AVCodecParameters* 
> par) {
> +static void flv_write_codec_header(AVFormatContext* s, AVCodecParameters* 
> par, unsigned int ts) {

Hi,

While the timestamp field is 8+24=32 bits, the DTS value is int64_ts.
Thus, while I'm really bad at doing wrap-around logic, wouldn't it be
something a la ´uint32_t wrapped_timestamp = (uint32_t)(ts %
UINT32_MAX)`?

Additionally, I did briefly go through E.4.1 (FLV Tag) in the spec and
it doesn't really seem to define whether this value is PTS or DTS...
Is this defined anywhere proper? Given FLV's age I wouldn't be
surprised that the answer would be "effectively DTS", of course. But
if you've seen what  Adobe's implementation writes with B-frames it'd
be interesting to see.

>  int64_t data_size;
>  AVIOContext *pb = s->pb;
>  FLVContext *flv = s->priv_data;
> @@ -492,8 +492,8 @@ static void flv_write_codec_header(AVFormatContext* s, 
> AVCodecParameters* par) {
>  par->codec_type == AVMEDIA_TYPE_VIDEO ?
>  FLV_TAG_TYPE_VIDEO : FLV_TAG_TYPE_AUDIO);
>  avio_wb24(pb, 0); // size patched later
> -avio_wb24(pb, 0); // ts
> -avio_w8(pb, 0);   // ts ext
> +avio_wb24(pb, ts & 0xFF);
> +avio_w8(pb, (ts >> 24) & 0x7F);

Looking at the spec this is bottom 24 bits of the timestamp and top 8,
thus why is the second one not & 0xFF ?

>  avio_wb24(pb, 0); // streamid
>  pos = avio_tell(pb);
>  if (par->codec_id == AV_CODEC_ID_AAC) {
> @@ -756,7 +756,7 @@ static int flv_write_header(AVFormatContext *s)
>  }
>
>  for (i = 0; i < s->nb_streams; i++) {
> -flv_write_codec_header(s, s->streams[i]->codecpar);
> +flv_write_codec_header(s, s->streams[i]->codecpar, 0);
>  }
>

Is it customary that even if you've got a live stream going, that the
start point of a given ingest is always zero? In that case you might
want to take mention of the initial dts, and then write offsets
compared to that? Otherwise if you have an initial offset of, say, 5s,
and then you a 5s GOP with an update, then while the difference to the
initial timestamp would be 5s, using the original dts field you would
get the second header having a value of 10s there. Or am I
misunderstanding something here?

Otherwise, looks like a nice improvement in the implementation.


Best regards,
Jan
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 0/3] WebM in dashenc

[Jan Ekström]

On Fri, Apr 27, 2018 at 3:51 AM, Jan Ekström <jee...@gmail.com> wrote:
> Personally I would be for removal of the WebM muxing feature in dashenc
> altogether, since the dashenc feature has never seemingly worked, and
> since there is a whole separate WebM-specific DASH meta muxer in
> webmdashenc.
>
> But these patches should at least make the thing not crash, and put it
> under FF_COMPLIANCE_EXPERIMENTAL strictness. That way nobody should be
> accidentally utilizing it.
>

For the record, I wrote this at around 4AM under the impression that
the "WebM DASH" muxer was actually what you would expect from its
name.. (and by quickly checking that it seemed to be writing a DASH
manifest)

It most certainly is not that, it just writes a DASH manifest. Does
not actually mux anything. So yes, dashenc is the thing to poke for
both ISOBMFF and WebM DASH.

Accordingly, I have found out that someone actually utilized WebM dash
for audio, and they mentioned that it worked for them on Chromium,
Firefox and Edge. The muxer seems to have worked without crashing at
least during release/3.4. I asked them to verify some video as well,
and if it works then the FF_COMPLIANCE_EXPERIMENTAL limitation can be
removed.

Kind of glad adding that made someone notice something, and report
that they were actually utilizing the feature. They seemed to be happy
about the thing no longer crashing, as well as the pass-through of
compliance mode to the sub-muxer.

Best regards,
Jan
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] rtsp: rename certain options after a deprecation period

[Jan Ekström]

On Fri, Jan 26, 2018 at 1:56 AM, Carl Eugen Hoyos  wrote:
> 2018-01-26 0:52 GMT+01:00 wm4 :
>> (and I already wrote that on IRC too, where he lurks as
>> michaelni)
>
> Could one of the native speakers please try to convince
> me that this is not a disparaging term?
>

Hi,

I am not an English native, but the verb "to lurk" is colloquially utilized as:

"read the postings in an Internet forum without actively contributing."
(quote from whatever dictionary Google utilizes)

...and this IMHO is applicable enough as Michael is busy just like
many of us are busy most of the day.

Now, please, all parties. Stop. We've had enough rudeness in this
thread. And now, back to on-topic:

* This change set offers to rename some options to make them similar
to how the TCP protocol does things
(http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavformat/tcp.c;h=8773493df1efebac33cff5d203c8c9ff17299d4b;hb=HEAD#l52).
UDP protocol seems to follow suite regarding the "timeout" parameter,
even matching the microsecond part?
* It's imperfect since it doesn't change any of the types of the
options (listen_timeout is now name-wise matched, but type-wise is
supposed to contain seconds for rtsp, milliseconds (! yet another time
scale) in tcp).
* But if we do not rename the current timeout parameter (which does a
different thing than timeout for both TCP and UDP - and name-wise
matches "listen_timeout" as far as it can be seen), we cannot have the
matching name for the matching type of - which should be under the
option "timeout".

So, as far as I can see for now applying this or a slightly modified
version of this as per James' comments doesn't seem to be a too bad
initial step. It brings at least one option in line. We can then start
the larger job of normalizing the timeout parameter across FFmpeg, as
it seems like mentioning this area made multiple people notice
possible improvements in this area. But this is just my 2 eurocents.


Best regards,
Jan
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH 2/3] mpegvideo_parser: parse the output picture number

[Jan Ekström]

From: Masaki Tanaka 

Utilizes the temporal_reference field from the picture header.
---
 libavcodec/mpegvideo_parser.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/libavcodec/mpegvideo_parser.c b/libavcodec/mpegvideo_parser.c
index 3406346a8b..4f554b684e 100644
--- a/libavcodec/mpegvideo_parser.c
+++ b/libavcodec/mpegvideo_parser.c
@@ -60,6 +60,7 @@ static void mpegvideo_extract_headers(AVCodecParserContext *s,
 switch(start_code) {
 case PICTURE_START_CODE:
 if (bytes_left >= 2) {
+s->output_picture_number = (buf[0] << 2) | (buf[1] >> 6);
 s->pict_type = (buf[1] >> 3) & 7;
 if (bytes_left >= 4)
 vbv_delay = ((buf[1] & 0x07) << 13) | (buf[2] << 5) | (buf[3]  
>> 3);
-- 
2.14.3

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

[FFmpeg-devel] [PATCH 1/3] mpegvideo_parser: implement parsing of the picture structure field

[Jan Ekström]

From: Masaki Tanaka 

Lets one receive the proper field order from pictures coded in
field picture mode, until now forcibly set to BFF.
---
 libavcodec/mpegvideo_parser.c | 16 +++-
 1 file changed, 15 insertions(+), 1 deletion(-)

diff --git a/libavcodec/mpegvideo_parser.c b/libavcodec/mpegvideo_parser.c
index be240b6890..3406346a8b 100644
--- a/libavcodec/mpegvideo_parser.c
+++ b/libavcodec/mpegvideo_parser.c
@@ -41,7 +41,7 @@ static void mpegvideo_extract_headers(AVCodecParserContext *s,
 uint32_t start_code;
 int frame_rate_index, ext_type, bytes_left;
 int frame_rate_ext_n, frame_rate_ext_d;
-int top_field_first, repeat_first_field, progressive_frame;
+int picture_structure, top_field_first, repeat_first_field, 
progressive_frame;
 int horiz_size_ext, vert_size_ext, bit_rate_ext;
 int did_set_size=0;
 int set_dim_ret = 0;
@@ -51,6 +51,7 @@ static void mpegvideo_extract_headers(AVCodecParserContext *s,
 enum AVPixelFormat pix_fmt = AV_PIX_FMT_NONE;
 //FIXME replace the crap with get_bits()
 s->repeat_pict = 0;
+s->picture_structure = AV_PICTURE_STRUCTURE_UNKNOWN;
 
 while (buf < buf_end) {
 start_code= -1;
@@ -114,6 +115,7 @@ static void mpegvideo_extract_headers(AVCodecParserContext 
*s,
 break;
 case 0x8: /* picture coding extension */
 if (bytes_left >= 5) {
+picture_structure = buf[2] & 0x03;
 top_field_first = buf[3] & (1 << 7);
 repeat_first_field = buf[3] & (1 << 1);
 progressive_frame = buf[4] & (1 << 7);
@@ -138,6 +140,18 @@ static void mpegvideo_extract_headers(AVCodecParserContext 
*s,
 s->field_order = AV_FIELD_BB;
 } else
 s->field_order = AV_FIELD_PROGRESSIVE;
+
+switch (picture_structure) {
+case PICT_TOP_FIELD:
+s->picture_structure = 
AV_PICTURE_STRUCTURE_TOP_FIELD;
+break;
+case PICT_BOTTOM_FIELD:
+s->picture_structure = 
AV_PICTURE_STRUCTURE_BOTTOM_FIELD;
+break;
+case PICT_FRAME:
+s->picture_structure = AV_PICTURE_STRUCTURE_FRAME;
+break;
+}
 }
 break;
 }
-- 
2.14.3

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

[FFmpeg-devel] [PATCH 3/3] mpegvideo_parser: fix indentation of an if statement

[Jan Ekström]

From: Masaki Tanaka 

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

diff --git a/libavcodec/mpegvideo_parser.c b/libavcodec/mpegvideo_parser.c
index 4f554b684e..ecf7c28e72 100644
--- a/libavcodec/mpegvideo_parser.c
+++ b/libavcodec/mpegvideo_parser.c
@@ -63,7 +63,7 @@ static void mpegvideo_extract_headers(AVCodecParserContext *s,
 s->output_picture_number = (buf[0] << 2) | (buf[1] >> 6);
 s->pict_type = (buf[1] >> 3) & 7;
 if (bytes_left >= 4)
-vbv_delay = ((buf[1] & 0x07) << 13) | (buf[2] << 5) | (buf[3]  
>> 3);
+vbv_delay = ((buf[1] & 0x07) << 13) | (buf[2] << 5) | 
(buf[3] >> 3);
 }
 break;
 case SEQ_START_CODE:
-- 
2.14.3

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

[FFmpeg-devel] [PATCH 0/3] MPEG-2 video parser improvements

[Jan Ekström]

These were brought to my knowledge by Yusuke, and they seemed correct
according to the specification, as well as the picture structure
parsing patch apparently fixes the detected field order with field
coded picture MPEG-2 video streams.

Masaki Tanaka (3):
  mpegvideo_parser: implement parsing of the picture structure field
  mpegvideo_parser: parse the output picture number
  mpegvideo_parser: fix indentation of an if statement

 libavcodec/mpegvideo_parser.c | 19 +--
 1 file changed, 17 insertions(+), 2 deletions(-)

-- 
2.14.3

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

Re: [FFmpeg-devel] [PATCH 2/3] mpegvideo_parser: parse the output picture number

[Jan Ekström]

On Sun, Feb 11, 2018 at 7:52 PM, Michael Niedermayer
 wrote:
>
> should be ok unless its intended to also restore the MSB
>

The value seemed to be 10bit and if the pointer is at the position
right after the picture_start_code, then `buf[0] << 2` would move the
8 bits left of data two bits leftwards, and `buf[1] >> 6` would then
move the topmost bits of the following byte to be the bottom-most
bits.

Unless you mean that there's a forgotten `(uint16_t)` there as the end
value has 10 bits of effective data, making the correct way of doing
it something a la `(((uint16_t)buf[0]) << 2) | (((uint16_t)buf[1]) >>
6)`?

> Theres no code using output_picture_number currently
>

Seems like some API users utilize this value.


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

Re: [FFmpeg-devel] [PATCH 1/3] mpegvideo_parser: implement parsing of the picture structure field

[Jan Ekström]

On Mon, Feb 12, 2018 at 12:23 AM, Michael Niedermayer
 wrote:
>
> I think a better API is needed to export the picture_structure correctly.
>

I might be misunderstanding the problem at hand, but I'm not sure if a
better API is required right now in the sense that if we define that:
* the demuxer and/or parser should return a decode'able coding unit
(whether or not it can actually be decoded depends on the state of
things). In case of field coded pictures this would be one coded
field, if I understand correctly.
* and, if the decoder then needs two coded field pictures to generate
a combed together "frame" - so be it. The new decoding/encoding APIs
let you have a non-synchronized amount of input VS output.

The primary part of course being that we shouldn't be ignoring the
other field picture in the parser if they are in the same PES packet,
for example.

> With the API here, i think unspecified is better than delcaring field pictures
> to be frames. The field value is also what decoders would use, they have to
> 2 field pics arent the same as a frame picture
>

Yes, if we are not going to be separating them in the parser as two
decode'able units, then we at the very least would have to parse both
and set the field order flags for that packet of two field pictures
correctly.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/3] mpegvideo_parser: implement parsing of the picture structure field

[Jan Ekström]

On Tue, Feb 13, 2018 at 2:13 PM, Michael Niedermayer
 wrote:
> ...
> If there are 2 fields in a packet that can be as 2 field pictures or
> as a interlaced frame coded in a way thats inseperable. Then you have
> 2 timestamps really and might have information associated with each
> field in principle. Our API doesnt have a place to put the information
> for the 2nd field anywhere. (which is together with picture_structure
> what i meant with needing a better API ...)
>

OK, so they are inseparable? Then it makes sense to pass them
together. Until now I only had the information that the two pictures
were in the same PES packet.

In that case the best thing we can do is set the field order correctly
for the set by parsing both field pictures' information. I just
wondered if the two field pictures are separately coded pictures, just
like with PAFF in AVC or how interlacing is generally done with HEVC
(which we even decode as separate fields right now).

Thus, I was just trying to query if the two field pictures were indeed
two separate images, and thus could be properly tagged and passed
through, without the latter picture apparently getting ignored. For
that at this point of time no new APIs would be needed, only work with
the parser.

>
> We have several decoders that can be fed with input at lower granularity
> like slices since a long time ago. So iam not sure how any "new APIs" are
> related here
>

Yes, although I think the feed/receive APIs make it work both ways
(you can feed more or receive more).

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

[FFmpeg-devel] [PATCH] lavf/aptxdec: fix the limit on the APTX demuxer definition

[Jan Ekström]

Fixes breakage with --disable-muxers as it was originally limited
to the muxer, and not the demuxer.
---
 libavformat/aptxdec.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavformat/aptxdec.c b/libavformat/aptxdec.c
index 467bc3fd5a..a262cd9ebe 100644
--- a/libavformat/aptxdec.c
+++ b/libavformat/aptxdec.c
@@ -87,7 +87,7 @@ static const AVOption aptx_options[] = {
 { NULL },
 };
 
-#if CONFIG_APTX_MUXER
+#if CONFIG_APTX_DEMUXER
 static const AVClass aptx_demuxer_class = {
 .class_name = "aptx demuxer",
 .item_name  = av_default_item_name,
-- 
2.14.3

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

Re: [FFmpeg-devel] [PATCH] lavf/aptxdec: fix the limit on the APTX demuxer definition

[Jan Ekström]

On Sat, Feb 10, 2018 at 6:18 PM, Paul B Mahol  wrote:
>
> lgtm
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Cheers, pushed.

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

Re: [FFmpeg-devel] [PATCH] lavf/aptxdec: fix the limit on the APTX demuxer definition

[Jan Ekström]

On Sat, Feb 10, 2018 at 6:27 PM, James Almer  wrote:
>
> I know it's a simple fix so in this case it's fine, but keep in mind
> Aurelien Jacobs is the maintainer of aptx for future patches.

Yes, if this was less straightforward I would have waited for the maintainer.

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

Re: [FFmpeg-devel] [PATCH 1/1] mpeg: add experimental support for PSMF audio.

[Jan Ekström]

On Mon, Jan 1, 2018 at 11:32 AM,   wrote:
> ...
> +avctx->sample_rate= ctx->sample_rate;
> +avctx->block_align= ctx->frame_size;
> +avctx->bit_rate   = ctx->sample_rate * ctx->frame_size * 8 / 
> 2048;
> +avctx->channels   = oma_chid_to_num_channels[ctx->channel_id - 
> 1];
> +avctx->channel_layout = oma_chid_to_native_layout[ctx->channel_id - 
> 1];
> +
> ...

Hi,

I had at one point looked into working on this after the initial patch
set failed to get merged as the AVCodecContext was modified in a
parser and people were afraid about threading issues. Is this no
longer an issue?

Currently this design of the parser is based on the ATRAC3+ decoder's
design, which is built upon the WAV-like OMA format. That, in part,
expects the demuxer to have filled all this information for it, and
basically it would have required to either insert the headers utilized
in the MPEG-PS encapsulation to every packet with OMA demux (and make
the decoder not require these values in the AVCodecContext) - which
would break any remuxing if such would take place unless those would
be removed in the muxer, or the decoder would have to have two modes.
One for the OMA-like (no header in packets), and the other for MPEG-PS
encapsulation (header in each packet). I had asked on the -devel IRC
channel regarding how to do it the best way a few times but never got
a nice answer.

> ...
> +} else if (!memcmp("PSMF00", buffer, 6)) {
> +m->sony_psmf = 1;
> ...

Games for the Sony PS3 seem to utilize the header "PAMF00" for the
same purpose. I can share a sample on IRC (poke JEEB).

Best regards,
Jan
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] fftools/ffmpeg: replace call to av_strerror with av_err2str

[Jan Ekström]

On Mon, Feb 26, 2018 at 9:40 AM, Tobias Rapp  wrote:
> Signed-off-by: Tobias Rapp 
> ---
>  fftools/ffmpeg.c | 10 ++
>  1 file changed, 2 insertions(+), 8 deletions(-)
>
> diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
> index 32caa4b..3a45f43 100644
> --- a/fftools/ffmpeg.c
> +++ b/fftools/ffmpeg.c
> @@ -2175,10 +2175,7 @@ static int ifilter_send_frame(InputFilter *ifilter, 
> AVFrame *frame)
>
>  ret = reap_filters(1);
>  if (ret < 0 && ret != AVERROR_EOF) {
> -char errbuf[128];
> -av_strerror(ret, errbuf, sizeof(errbuf));
> -
> -av_log(NULL, AV_LOG_ERROR, "Error while filtering: %s\n", 
> errbuf);
> +av_log(NULL, AV_LOG_ERROR, "Error while filtering: %s\n", 
> av_err2str(ret));
>  return ret;
>  }
>
> @@ -4638,10 +4635,7 @@ static int transcode(void)
>
>  ret = transcode_step();
>  if (ret < 0 && ret != AVERROR_EOF) {
> -char errbuf[128];
> -av_strerror(ret, errbuf, sizeof(errbuf));
> -
> -av_log(NULL, AV_LOG_ERROR, "Error while filtering: %s\n", 
> errbuf);
> +av_log(NULL, AV_LOG_ERROR, "Error while filtering: %s\n", 
> av_err2str(ret));
>  break;
>  }
>
> --
> 2.7.4

If I recall correctly logging seems to be the use case where this
macro should be used, so this looks good to me after a quick look in
the e-mail client (and simplifies this piece of code).

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

Re: [FFmpeg-devel] [PATCH] avformat/librtmp: fix returning EOF from Read/Write

[Jan Ekström]

On Thu, Jul 26, 2018 at 1:20 PM, Timo Rothenpieler
 wrote:
> ---
>  libavformat/librtmp.c | 10 --
>  1 file changed, 8 insertions(+), 2 deletions(-)
>
> diff --git a/libavformat/librtmp.c b/libavformat/librtmp.c
> index f3cfa9a8e2..43013e46e0 100644
> --- a/libavformat/librtmp.c
> +++ b/libavformat/librtmp.c
> @@ -261,7 +261,10 @@ static int rtmp_write(URLContext *s, const uint8_t *buf, 
> int size)
>  LibRTMPContext *ctx = s->priv_data;
>  RTMP *r = >rtmp;
>
> -return RTMP_Write(r, buf, size);
> +int ret = RTMP_Write(r, buf, size);
> +if (!ret)
> +return AVERROR_EOF;
> +return ret;
>  }
>
>  static int rtmp_read(URLContext *s, uint8_t *buf, int size)
> @@ -269,7 +272,10 @@ static int rtmp_read(URLContext *s, uint8_t *buf, int 
> size)
>  LibRTMPContext *ctx = s->priv_data;
>  RTMP *r = >rtmp;
>
> -return RTMP_Read(r, buf, size);
> +int ret = RTMP_Read(r, buf, size);
> +if (!ret)
> +return AVERROR_EOF;
> +return ret;
>  }
>
>  static int rtmp_read_pause(URLContext *s, int pause)
> --
> 2.18.0
>

Cheers, these things just keep popping up it seems :) . Generally I've
done something along the lines of return ret ? ret : AVERROR_EOF; ,
but that's just a stylistic thing.

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

Re: [FFmpeg-devel] [PATCH] avformat/movenc: implicitly enable negative CTS offsets for ismv

[Jan Ekström]

On Fri, Jul 27, 2018 at 1:30 AM, Michael Niedermayer
 wrote:
> breaks fate
>

fate-lavf-ismv seems to be all about the version identifier (0 is for
uintXX CTS offsets, and 1 is for intXX CTS offsets). F.ex. with the
first file:

diff --git a/old_1st.log b/new_1st.log
index f188075577..5100ff6710 100644
--- a/old_1st.log
+++ b/new_1st.log
@@ -267,7 +267,7 @@
 [trun: Track Fragment Run Box]
 position = 851
 size = 120
-version = 0
+version = 1
 flags = 0x000305
 data-offset-present
 first-sample-flags-present
@@ -350,7 +350,7 @@
 [trun: Track Fragment Run Box]
 position = 143053
 size = 120
-version = 0
+version = 1
 flags = 0x000305
 data-offset-present
 first-sample-flags-present
@@ -433,7 +433,7 @@
 [trun: Track Fragment Run Box]
 position = 284519
 size = 32
-version = 0
+version = 1
 flags = 0x000305
 data-offset-present
 first-sample-flags-present

Will send a new patch with that test updated.

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

Re: [FFmpeg-devel] [PATCH] lavfi/nlmeans: fixup aarch64 assembly with clang

[Jan Ekström]

On Fri, Jul 27, 2018 at 11:14 AM, Clément Bœsch  wrote:
> On Fri, Jul 27, 2018 at 12:03:46AM +0300, Jan Ekström wrote:
>> Clang is more strict about some things.
>> ---
>>  libavfilter/aarch64/vf_nlmeans_neon.S | 4 ++--
>>  1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/libavfilter/aarch64/vf_nlmeans_neon.S 
>> b/libavfilter/aarch64/vf_nlmeans_neon.S
>> index 6308a428db..ac16157bbd 100644
>> --- a/libavfilter/aarch64/vf_nlmeans_neon.S
>> +++ b/libavfilter/aarch64/vf_nlmeans_neon.S
>> @@ -22,7 +22,7 @@
>>
>>  // acc_sum_store(ABCD) = {X+A, X+A+B, X+A+B+C, X+A+B+C+D}
>>  .macro acc_sum_store x, xb
>> -dup v24.4S, v24.4S[3]   // 
>> ...X -> 
>> +dup v24.4s, v24.s[3]// 
>> ...X -> 
>
> can you keep the capitalized form?
>
>>  ext v25.16B, v26.16B, \xb, #12  // 
>> ext(,ABCD,12)=0ABC
>>  add v24.4S, v24.4S, \x  // 
>> +ABCD={X+A,X+B,X+C,X+D}
>>  add v24.4S, v24.4S, v25.4S  // 
>> {X+A,X+B+A,X+C+B,X+D+C}   (+0ABC)
>> @@ -37,7 +37,7 @@ function ff_compute_safe_ssd_integral_image_neon, export=1
>>  moviv26.4S, #0  // 
>> used as zero for the "rotations" in acc_sum_store
>>  sub x3, x3, w6, UXTW// 
>> s1 padding (s1_linesize - w)
>>  sub x5, x5, w6, UXTW// 
>> s2 padding (s2_linesize - w)
>> -sub x9, x0, x1, UXTW #2 // 
>> dst_top
>> +sub x9, x0, w1, UXTW #2 // 
>> dst_top
>>  sub x1, x1, w6, UXTW// 
>> dst padding (dst_linesize_32 - w)
>>  lsl x1, x1, #2  // 
>> dst padding expressed in bytes
>>  1:  mov w10, w6 // 
>> width copy for each line
>
> LGTM otherwise, thx
>

Fixed the capitalization with the s suffix and used "fix" instead of
"fixup" in the commit message due to IRC review.

Pushed, and default compilation configuration should now be fixed
again with aarch64+clang.

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

[FFmpeg-devel] [PATCH v2] avformat/movenc: implicitly enable negative CTS offsets for ismv

[Jan Ekström]

ISMV lacks any sort of edit list support, as well as tfxd is
effectively the PTS of the fragment for most intents and purposes.

Thus, if b-frames are requested without negative CTS offsets you
end up with N frames' worth of delay (tfxd PTS plus the CTS offset
of the first sample). Negative CTS offsets enable the first sample
to have CTS=DTS, and thus a/v desync due to b-frame reorder delay
is avoided.
---
 doc/muxers.texi   | 2 ++
 libavformat/movenc.c  | 2 +-
 tests/ref/fate/movenc | 4 ++--
 tests/ref/lavf/ismv   | 6 +++---
 4 files changed, 8 insertions(+), 6 deletions(-)

diff --git a/doc/muxers.texi b/doc/muxers.texi
index 33f1f7bbaf..268c152023 100644
--- a/doc/muxers.texi
+++ b/doc/muxers.texi
@@ -1344,6 +1344,8 @@ be negative. This enables the initial sample to have 
DTS/CTS of zero, and
 reduces the need for edit lists for some cases such as video tracks with
 B-frames. Additionally, eases conformance with the DASH-IF interoperability
 guidelines.
+
+This option is implicitly set when writing ismv (Smooth Streaming) files.
 @item -write_prft
 Write producer time reference box (PRFT) with a specified time source for the
 NTP field in the PRFT box. Set value as @samp{wallclock} to specify timesource
diff --git a/libavformat/movenc.c b/libavformat/movenc.c
index d530f40cab..14f85eb2a7 100644
--- a/libavformat/movenc.c
+++ b/libavformat/movenc.c
@@ -6049,7 +6049,7 @@ static int mov_init(AVFormatContext *s)
 /* Set other implicit flags immediately */
 if (mov->mode == MODE_ISM)
 mov->flags |= FF_MOV_FLAG_EMPTY_MOOV | FF_MOV_FLAG_SEPARATE_MOOF |
-  FF_MOV_FLAG_FRAGMENT;
+  FF_MOV_FLAG_FRAGMENT | FF_MOV_FLAG_NEGATIVE_CTS_OFFSETS;
 if (mov->flags & FF_MOV_FLAG_DASH)
 mov->flags |= FF_MOV_FLAG_FRAGMENT | FF_MOV_FLAG_EMPTY_MOOV |
   FF_MOV_FLAG_DEFAULT_BASE_MOOF;
diff --git a/tests/ref/fate/movenc b/tests/ref/fate/movenc
index 872796ebce..5e8f324ea3 100644
--- a/tests/ref/fate/movenc
+++ b/tests/ref/fate/movenc
@@ -17,10 +17,10 @@ write_data len 20, time nopts, type header atom ftyp
 write_data len 1171, time nopts, type header atom -
 write_data len 728, time 0, type sync atom moof
 write_data len 828, time nopts, type unknown atom -
-write_data len 728, time 1013106, type sync atom moof
+write_data len 728, time 1046439, type sync atom moof
 write_data len 812, time nopts, type unknown atom -
 write_data len 148, time nopts, type trailer atom -
-1f37c1a8e01651e8bebcd66f00b6a226 4435 ismv
+49bf122c4c732a344ef68b58acd19be5 4435 ismv
 write_data len 36, time nopts, type header atom ftyp
 write_data len 1123, time nopts, type header atom -
 write_data len 796, time 0, type sync atom moof
diff --git a/tests/ref/lavf/ismv b/tests/ref/lavf/ismv
index f29b5ff3ef..7b4a466096 100644
--- a/tests/ref/lavf/ismv
+++ b/tests/ref/lavf/ismv
@@ -1,9 +1,9 @@
-a9ccbb4cd1436d222ef4425567b4e03d *./tests/data/lavf/lavf.ismv
+96053075a3f60d271131fe2d0765c267 *./tests/data/lavf/lavf.ismv
 312542 ./tests/data/lavf/lavf.ismv
 ./tests/data/lavf/lavf.ismv CRC=0x9d9a638a
-440d85f9fd5b9f63c2676638782b5c15 *./tests/data/lavf/lavf.ismv
+7022701b4c693bc4ffe1e9f96dd82a02 *./tests/data/lavf/lavf.ismv
 321448 ./tests/data/lavf/lavf.ismv
 ./tests/data/lavf/lavf.ismv CRC=0xe8130120
-a9ccbb4cd1436d222ef4425567b4e03d *./tests/data/lavf/lavf.ismv
+96053075a3f60d271131fe2d0765c267 *./tests/data/lavf/lavf.ismv
 312542 ./tests/data/lavf/lavf.ismv
 ./tests/data/lavf/lavf.ismv CRC=0x9d9a638a
-- 
2.17.1

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

[FFmpeg-devel] [PATCH] lavfi/nlmeans: fixup aarch64 assembly with clang

[Jan Ekström]

Clang is more strict about some things.
---
 libavfilter/aarch64/vf_nlmeans_neon.S | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/libavfilter/aarch64/vf_nlmeans_neon.S 
b/libavfilter/aarch64/vf_nlmeans_neon.S
index 6308a428db..ac16157bbd 100644
--- a/libavfilter/aarch64/vf_nlmeans_neon.S
+++ b/libavfilter/aarch64/vf_nlmeans_neon.S
@@ -22,7 +22,7 @@
 
 // acc_sum_store(ABCD) = {X+A, X+A+B, X+A+B+C, X+A+B+C+D}
 .macro acc_sum_store x, xb
-dup v24.4S, v24.4S[3]   // 
...X -> 
+dup v24.4s, v24.s[3]// 
...X -> 
 ext v25.16B, v26.16B, \xb, #12  // 
ext(,ABCD,12)=0ABC
 add v24.4S, v24.4S, \x  // 
+ABCD={X+A,X+B,X+C,X+D}
 add v24.4S, v24.4S, v25.4S  // 
{X+A,X+B+A,X+C+B,X+D+C}   (+0ABC)
@@ -37,7 +37,7 @@ function ff_compute_safe_ssd_integral_image_neon, export=1
 moviv26.4S, #0  // 
used as zero for the "rotations" in acc_sum_store
 sub x3, x3, w6, UXTW// s1 
padding (s1_linesize - w)
 sub x5, x5, w6, UXTW// s2 
padding (s2_linesize - w)
-sub x9, x0, x1, UXTW #2 // 
dst_top
+sub x9, x0, w1, UXTW #2 // 
dst_top
 sub x1, x1, w6, UXTW// dst 
padding (dst_linesize_32 - w)
 lsl x1, x1, #2  // dst 
padding expressed in bytes
 1:  mov w10, w6 // 
width copy for each line
-- 
2.17.1

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

[FFmpeg-devel] [PATCH] avformat/movenc: implicitly enable negative CTS offsets for ismv

[Jan Ekström]

ISMV lacks any sort of edit list support, as well as tfxd is
effectively the PTS of the fragment for most intents and purposes.

Thus, if b-frames are requested without negative CTS offsets you
end up with N frames' worth of delay (tfxd PTS plus the CTS offset
of the first sample). Negative CTS offsets enable the first sample
to have CTS=DTS, and thus a/v desync due to b-frame reorder delay
is avoided.
---
 doc/muxers.texi   | 2 ++
 libavformat/movenc.c  | 2 +-
 tests/ref/fate/movenc | 4 ++--
 3 files changed, 5 insertions(+), 3 deletions(-)

diff --git a/doc/muxers.texi b/doc/muxers.texi
index 33f1f7bbaf..268c152023 100644
--- a/doc/muxers.texi
+++ b/doc/muxers.texi
@@ -1344,6 +1344,8 @@ be negative. This enables the initial sample to have 
DTS/CTS of zero, and
 reduces the need for edit lists for some cases such as video tracks with
 B-frames. Additionally, eases conformance with the DASH-IF interoperability
 guidelines.
+
+This option is implicitly set when writing ismv (Smooth Streaming) files.
 @item -write_prft
 Write producer time reference box (PRFT) with a specified time source for the
 NTP field in the PRFT box. Set value as @samp{wallclock} to specify timesource
diff --git a/libavformat/movenc.c b/libavformat/movenc.c
index d530f40cab..14f85eb2a7 100644
--- a/libavformat/movenc.c
+++ b/libavformat/movenc.c
@@ -6049,7 +6049,7 @@ static int mov_init(AVFormatContext *s)
 /* Set other implicit flags immediately */
 if (mov->mode == MODE_ISM)
 mov->flags |= FF_MOV_FLAG_EMPTY_MOOV | FF_MOV_FLAG_SEPARATE_MOOF |
-  FF_MOV_FLAG_FRAGMENT;
+  FF_MOV_FLAG_FRAGMENT | FF_MOV_FLAG_NEGATIVE_CTS_OFFSETS;
 if (mov->flags & FF_MOV_FLAG_DASH)
 mov->flags |= FF_MOV_FLAG_FRAGMENT | FF_MOV_FLAG_EMPTY_MOOV |
   FF_MOV_FLAG_DEFAULT_BASE_MOOF;
diff --git a/tests/ref/fate/movenc b/tests/ref/fate/movenc
index 872796ebce..5e8f324ea3 100644
--- a/tests/ref/fate/movenc
+++ b/tests/ref/fate/movenc
@@ -17,10 +17,10 @@ write_data len 20, time nopts, type header atom ftyp
 write_data len 1171, time nopts, type header atom -
 write_data len 728, time 0, type sync atom moof
 write_data len 828, time nopts, type unknown atom -
-write_data len 728, time 1013106, type sync atom moof
+write_data len 728, time 1046439, type sync atom moof
 write_data len 812, time nopts, type unknown atom -
 write_data len 148, time nopts, type trailer atom -
-1f37c1a8e01651e8bebcd66f00b6a226 4435 ismv
+49bf122c4c732a344ef68b58acd19be5 4435 ismv
 write_data len 36, time nopts, type header atom ftyp
 write_data len 1123, time nopts, type header atom -
 write_data len 796, time 0, type sync atom moof
-- 
2.17.1

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

Re: [FFmpeg-devel] [PATCH v2] avformat/movenc: implicitly enable negative CTS offsets for ismv

[Jan Ekström]

On 7/29/18, Jan Ekström  wrote:
> ISMV lacks any sort of edit list support, as well as tfxd is
> effectively the PTS of the fragment for most intents and purposes.
>
> Thus, if b-frames are requested without negative CTS offsets you
> end up with N frames' worth of delay (tfxd PTS plus the CTS offset
> of the first sample). Negative CTS offsets enable the first sample
> to have CTS=DTS, and thus a/v desync due to b-frame reorder delay
> is avoided.

Hi,

Since this fixes b-frames in ISMV by not adding a double-delay (tfxd
PTS + positive CTS offset), unless someone has any comments I will
push this tonight (JST).

Best regards,
Jan
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v2] avformat/movenc: implicitly enable negative CTS offsets for ismv

[Jan Ekström]

On Sun, Aug 5, 2018 at 6:31 AM Jan Ekström  wrote:
> Hi,
>
> Since this fixes b-frames in ISMV by not adding a double-delay (tfxd
> PTS + positive CTS offset), unless someone has any comments I will
> push this tonight (JST).
>
> Best regards,
> Jan

Pushed as 1931761f18cda3756a27087c366270c38160c754 .

Had it verified that FATE now fully passes (I didn't happen to have
the full FATE set around).

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

[FFmpeg-devel] [PATCH 1/2] ffmpeg: handle flushing and non-flushing separately in sub2video

[Jan Ekström]

The initial fix for sub2video flushing during filter chain restarts
seemed to add additional buffering into the filter chain, which in case
of files did work, but when handling live streams would cause premature
failure.

This fix reverts the timestamp filtering, and separates flushing from
normal heartbeat functionality by adding an explicit parameter.
From 9ed9d80535a1e6a2a70faef296fd8d3cbfde8e55 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Jan=20Ekstr=C3=B6m?= 
Date: Thu, 26 Jul 2018 19:07:38 +0300
Subject: [PATCH 1/2] ffmpeg: handle flushing and non-flushing separately in
 sub2video

This stops accidental flushes from happening in sub2video in case
the filter chain gets a re-configuration/re-init. Heartbeats
should not cause a flush and additional buffering in the filter chain.

Properly fixes filter chain flush handling, as previously the
filter chain would keep buffering frames.

Additionally, document the various stages of sub2video.
---
 fftools/ffmpeg.c| 57 +++--
 fftools/ffmpeg.h|  2 +-
 fftools/ffmpeg_filter.c |  2 +-
 3 files changed, 51 insertions(+), 10 deletions(-)

diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
index 934dc71a74..758e3839a3 100644
--- a/fftools/ffmpeg.c
+++ b/fftools/ffmpeg.c
@@ -237,7 +237,7 @@ static void sub2video_push_ref(InputStream *ist, int64_t pts)
 }
 }
 
-void sub2video_update(InputStream *ist, AVSubtitle *sub)
+void sub2video_update(InputStream *ist, AVSubtitle *sub, int flush)
 {
 AVFrame *frame = ist->sub2video.frame;
 int8_t *dst;
@@ -254,9 +254,47 @@ void sub2video_update(InputStream *ist, AVSubtitle *sub)
  AV_TIME_BASE_Q, ist->st->time_base);
 num_rects = sub->num_rects;
 } else {
-pts   = ist->sub2video.end_pts;
-end_pts   = INT64_MAX;
 num_rects = 0;
+
+if (flush) {
+/* Flush of the sub2video filter chain was requested.
+   Utilize previous end_pts as the pts, and set end_pts to
+   the filter chain flush value (INT64_MAX). */
+pts = ist->sub2video.end_pts;
+end_pts = INT64_MAX;
+
+av_log(ist->dec_ctx, AV_LOG_DEBUG,
+   "nullptr AVSubtitle (flush): utilized values: "
+   "pts=%"PRId64", end_pts=%"PRId64"\n",
+   pts, end_pts);
+} else {
+/* We do not have an active sub-picture and this was not a flush.
+   We will be sending a blank heartbeat frame to the filter
+   chain. */
+
+if (ist->sub2video.last_pts != AV_NOPTS_VALUE &&
+ist->sub2video.last_pts < INT64_MAX) {
+/* if the last PTS is not invalid (it's not unknown/unset or
+   the flush value), use the last PTS as the start point
+   for this filter chain heartbeat frame. */
+pts = ist->sub2video.last_pts;
+} else {
+/* If the last sub2video PTS is invalid, use the provided
+   sub2video frame PTS (set to the current input
+   timestamp by sub2video_heartbeat) */
+pts = frame->pts;
+}
+
+/* FIXME: decide if pts+1 is good enough for this, currently set
+   for .2 seconds */
+end_pts = pts + av_rescale_q(2*1000LL, AV_TIME_BASE_Q,
+ ist->st->time_base);
+
+av_log(ist->dec_ctx, AV_LOG_DEBUG,
+   "nullptr AVSubtitle (no flush): utilized values: "
+   "pts=%"PRId64", end_pts=%"PRId64"\n",
+   pts, end_pts);
+}
 }
 if (sub2video_get_blank_frame(ist) < 0) {
 av_log(ist->dec_ctx, AV_LOG_ERROR,
@@ -291,9 +329,12 @@ static void sub2video_heartbeat(InputStream *ist, int64_t pts)
 /* do not send the heartbeat frame if the subtitle is already ahead */
 if (pts2 <= ist2->sub2video.last_pts)
 continue;
-if (pts2 >= ist2->sub2video.end_pts ||
-(!ist2->sub2video.frame->data[0] && ist2->sub2video.end_pts < INT64_MAX))
-sub2video_update(ist2, NULL);
+if (pts2 >= ist2->sub2video.end_pts || !ist2->sub2video.frame->data[0]) {
+/* if we do not have a subtitle to show for a specific time,
+   add the current stream time as the fall-back PTS */
+ist2->sub2video.frame->pts = pts2;
+sub2video_update(ist2, NULL, 0);
+}
 for (j = 0, nb_reqs = 0; j < ist2->nb_filters; j++)
 nb_reqs += av_buffersrc_get_nb_failed_requests(ist2->filters[j]->filter);
 if (nb_reqs)
@@ -307,7 +348,7 @@ static void sub2video_flush(InputStream *ist)
 int ret;
 
 if (ist->sub2video.end_pts < INT64_MAX)
-sub2video_update(ist, NULL);
+sub2video_update(ist, NULL, 1);
 for (i = 0; i < ist->nb_filters; i++) {
 ret = 

[FFmpeg-devel] [PATCH 2/2] ffmpeg_filter: keep sub2video size configuration if likely a re-init

[Jan Ekström]

This commit tries to keep the sub2video canvas
size in case a filter chain re-initialization occurs. This issue
could also be improved by having this size be checked as new frames are
pushed into the overlay, or the overlay filter itself having an option
to scale overlayed images to the primary image's size.
From d896643576f4f03f0f2f4bc2b653895bb4c07df3 Mon Sep 17 00:00:00 2001
From: Nongji Chen 
Date: Thu, 26 Jul 2018 16:25:19 +0300
Subject: [PATCH 2/2] ffmpeg_filter: keep sub2video size configuration if
 likely a re-init

This way the filter chain does not accidentally mis-configure itself
in case a filter chain re-initialization happens during run-time.
---
 fftools/ffmpeg_filter.c | 23 ++-
 1 file changed, 18 insertions(+), 5 deletions(-)

diff --git a/fftools/ffmpeg_filter.c b/fftools/ffmpeg_filter.c
index 4cb81ea41f..ae86be1f1a 100644
--- a/fftools/ffmpeg_filter.c
+++ b/fftools/ffmpeg_filter.c
@@ -698,11 +698,17 @@ void check_filter_outputs(void)
 static int sub2video_prepare(InputStream *ist, InputFilter *ifilter)
 {
 AVFormatContext *avf = input_files[ist->file_index]->ctx;
-int i, w, h;
+int i, w, h, keep_existing = 0;
 
 /* Compute the size of the canvas for the subtitles stream.
-   If the subtitles codecpar has set a size, use it. Otherwise use the
-   maximum dimensions of the video streams in the same file. */
+
+   If the ifilter->width|height are nonzero and match the sub2video.w|h,
+   keep the configuration as this is likely a re-initialization
+   of the filter chain.
+
+   Otherwise if the subtitles codecpar has set a size, use it, and
+   utilize either the input filter's width|height or the maximum
+   dimensions of the video streams in the same file. */
 w = ifilter->width;
 h = ifilter->height;
 if (!(w && h)) {
@@ -717,12 +723,19 @@ static int sub2video_prepare(InputStream *ist, InputFilter *ifilter)
 h = FFMAX(h, 576);
 }
 av_log(avf, AV_LOG_INFO, "sub2video: using %dx%d canvas\n", w, h);
+} else if (w == ist->sub2video.w && h == ist->sub2video.h) {
+// This is most likely a re-configuration, so keep the currently
+// configured values for width and height.
+keep_existing = 1;
 }
+
 ist->sub2video.w = ifilter->width  = w;
 ist->sub2video.h = ifilter->height = h;
 
-ifilter->width  = ist->dec_ctx->width  ? ist->dec_ctx->width  : ist->sub2video.w;
-ifilter->height = ist->dec_ctx->height ? ist->dec_ctx->height : ist->sub2video.h;
+if (!keep_existing) {
+ifilter->width  = ist->dec_ctx->width  ? ist->dec_ctx->width  : ist->sub2video.w;
+ifilter->height = ist->dec_ctx->height ? ist->dec_ctx->height : ist->sub2video.h;
+}
 
 /* rectangles are AV_PIX_FMT_PAL8, but we have no guarantee that the
palettes for all rectangles are identical or compatible */
-- 
2.17.1

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

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

[Jan Ekström]

On Sat, Mar 3, 2018 at 10:30 PM, Jan Ekström <jee...@gmail.com> wrote:
> On Wed, Feb 21, 2018 at 7:57 PM, Stefan _ <sf...@live.de> wrote:
>> Hadn't seen that one, it does indeed describe this exact problem.
>> I've included it in the commit message, new patch attached.
>>
>
> Generally LGTM after checking the patch on patchwork
> https://patchwork.ffmpeg.org/patch/7693/
>
> Jan

Pushed.

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

Re: [FFmpeg-devel] [PATCH 3/3] mpegvideo_parser: fix indentation of an if statement

[Jan Ekström]

On Tue, Mar 6, 2018 at 10:39 AM, Paul B Mahol  wrote:
> LGTM

Cheers, pushed.

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