date:20181218

Signed-off-by: Michael Niedermayer 
---
 libavcodec/tests/rangecoder.c | 43 +--
 1 file changed, 26 insertions(+), 17 deletions(-)

diff --git a/libavcodec/tests/rangecoder.c b/libavcodec/tests/rangecoder.c
index 76a13e7091..3fd07ed9a9 100644
--- a/libavcodec/tests/rangecoder.c
+++ b/libavcodec/tests/rangecoder.c
@@ -24,41 +24,50 @@
 
 #include "libavcodec/rangecoder.h"
 
-#define SIZE 10240
+#define SIZE 1240
 
 int main(void)
 {
 RangeCoder c;
 uint8_t b[9 * SIZE];
 uint8_t r[9 * SIZE];
-int i;
+int i, p, actual_length, version;
 uint8_t state[10];
 AVLFG prng;
 
 av_lfg_init(, 1);
+for (version = 0; version < 2; version++) {
+for (p = 0; p< 1024; p++) {
+ff_init_range_encoder(, b, SIZE);
+ff_build_rac_states(, (1LL << 32) / 20, 128 + 64 + 32 + 16);
 
-ff_init_range_encoder(, b, SIZE);
-ff_build_rac_states(, (1LL << 32) / 20, 128 + 64 + 32 + 16);
+memset(state, 128, sizeof(state));
 
-memset(state, 128, sizeof(state));
+for (i = 0; i < SIZE; i++)
+r[i] = av_lfg_get() % 7;
 
-for (i = 0; i < SIZE; i++)
-r[i] = av_lfg_get() % 7;
+for (i = 0; i < SIZE; i++)
+put_rac(, state, r[i] & 1);
 
-for (i = 0; i < SIZE; i++)
-put_rac(, state, r[i] & 1);
+actual_length = ff_rac_terminate(, version);
 
-ff_rac_terminate(, 0);
+ff_init_range_decoder(, b, version ? SIZE : actual_length);
 
-ff_init_range_decoder(, b, SIZE);
+memset(state, 128, sizeof(state));
 
-memset(state, 128, sizeof(state));
-
-for (i = 0; i < SIZE; i++)
-if ((r[i] & 1) != get_rac(, state)) {
-av_log(NULL, AV_LOG_ERROR, "rac failure at %d\n", i);
-return 1;
+for (i = 0; i < SIZE; i++)
+if ((r[i] & 1) != get_rac(, state)) {
+av_log(NULL, AV_LOG_ERROR, "rac failure at %d pass %d 
version %d\n", i, p, version);
+return 1;
+}
+if(version)
+get_rac(, (uint8_t[]) { 129 });
+if (c.bytestream - c.bytestream_start - actual_length != version) {
+av_log(NULL, AV_LOG_ERROR, "rac failure at pass %d version 
%d\n", p, version);
+return 1;
+}
 }
+}
 
 return 0;
 }
-- 
2.19.2

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

[FFmpeg-devel] [PATCH 1/3] avcodec/rangecoder: factorize termination version code

Signed-off-by: Michael Niedermayer 
---
 libavcodec/ffv1enc.c  | 10 +++---
 libavcodec/rangecoder.c   |  4 +++-
 libavcodec/rangecoder.h   |  2 +-
 libavcodec/snowenc.c  |  2 +-
 libavcodec/sonic.c|  2 +-
 libavcodec/tests/rangecoder.c |  2 +-
 6 files changed, 10 insertions(+), 12 deletions(-)

diff --git a/libavcodec/ffv1enc.c b/libavcodec/ffv1enc.c
index f5eb0feb4e..796d81f7c6 100644
--- a/libavcodec/ffv1enc.c
+++ b/libavcodec/ffv1enc.c
@@ -449,7 +449,7 @@ static int write_extradata(FFV1Context *f)
 put_symbol(c, state, f->intra = (f->avctx->gop_size < 2), 0);
 }
 
-f->avctx->extradata_size = ff_rac_terminate(c);
+f->avctx->extradata_size = ff_rac_terminate(c, 0);
 v = av_crc(av_crc_get_table(AV_CRC_32_IEEE), 0, f->avctx->extradata, 
f->avctx->extradata_size);
 AV_WL32(f->avctx->extradata + f->avctx->extradata_size, v);
 f->avctx->extradata_size += 4;
@@ -1065,9 +1065,7 @@ retry:
 encode_slice_header(f, fs);
 }
 if (fs->ac == AC_GOLOMB_RICE) {
-if (f->version > 2)
-put_rac(>c, (uint8_t[]) { 129 }, 0);
-fs->ac_byte_count = f->version > 2 || (!x && !y) ? 
ff_rac_terminate(>c) : 0;
+fs->ac_byte_count = f->version > 2 || (!x && !y) ? 
ff_rac_terminate(>c, f->version > 2) : 0;
 init_put_bits(>pb,
   fs->c.bytestream_start + fs->ac_byte_count,
   fs->c.bytestream_end - fs->c.bytestream_start - 
fs->ac_byte_count);
@@ -1232,9 +1230,7 @@ FF_ENABLE_DEPRECATION_WARNINGS
 int bytes;
 
 if (fs->ac != AC_GOLOMB_RICE) {
-uint8_t state = 129;
-put_rac(>c, , 0);
-bytes = ff_rac_terminate(>c);
+bytes = ff_rac_terminate(>c, 1);
 } else {
 flush_put_bits(>pb); // FIXME: nicer padding
 bytes = fs->ac_byte_count + (put_bits_count(>pb) + 7) / 8;
diff --git a/libavcodec/rangecoder.c b/libavcodec/rangecoder.c
index 0d53bef076..fa7d5526d1 100644
--- a/libavcodec/rangecoder.c
+++ b/libavcodec/rangecoder.c
@@ -106,8 +106,10 @@ void ff_build_rac_states(RangeCoder *c, int factor, int 
max_p)
 }
 
 /* Return the number of bytes written. */
-int ff_rac_terminate(RangeCoder *c)
+int ff_rac_terminate(RangeCoder *c, int version)
 {
+if (version == 1)
+put_rac(c, (uint8_t[]) { 129 }, 0);
 c->range = 0xFF;
 c->low  += 0xFF;
 renorm_encoder(c);
diff --git a/libavcodec/rangecoder.h b/libavcodec/rangecoder.h
index 44af88b8f5..e5c7a3cc71 100644
--- a/libavcodec/rangecoder.h
+++ b/libavcodec/rangecoder.h
@@ -48,7 +48,7 @@ typedef struct RangeCoder {
 
 void ff_init_range_encoder(RangeCoder *c, uint8_t *buf, int buf_size);
 void ff_init_range_decoder(RangeCoder *c, const uint8_t *buf, int buf_size);
-int ff_rac_terminate(RangeCoder *c);
+int ff_rac_terminate(RangeCoder *c, int version);
 void ff_build_rac_states(RangeCoder *c, int factor, int max_p);
 
 static inline void renorm_encoder(RangeCoder *c)
diff --git a/libavcodec/snowenc.c b/libavcodec/snowenc.c
index 61a658fa44..df1729a083 100644
--- a/libavcodec/snowenc.c
+++ b/libavcodec/snowenc.c
@@ -1899,7 +1899,7 @@ FF_DISABLE_DEPRECATION_WARNINGS
 FF_ENABLE_DEPRECATION_WARNINGS
 #endif
 
-pkt->size = ff_rac_terminate(c);
+pkt->size = ff_rac_terminate(c, 0);
 if (s->current_picture->key_frame)
 pkt->flags |= AV_PKT_FLAG_KEY;
 *got_packet = 1;
diff --git a/libavcodec/sonic.c b/libavcodec/sonic.c
index 2e3ca79fdd..34d2952e69 100644
--- a/libavcodec/sonic.c
+++ b/libavcodec/sonic.c
@@ -842,7 +842,7 @@ static int sonic_encode_frame(AVCodecContext *avctx, 
AVPacket *avpkt,
 
 //av_log(avctx, AV_LOG_DEBUG, "used bytes: %d\n", 
(put_bits_count()+7)/8);
 
-avpkt->size = ff_rac_terminate();
+avpkt->size = ff_rac_terminate(, 0);
 *got_packet_ptr = 1;
 return 0;
 
diff --git a/libavcodec/tests/rangecoder.c b/libavcodec/tests/rangecoder.c
index 2da5c0ce33..76a13e7091 100644
--- a/libavcodec/tests/rangecoder.c
+++ b/libavcodec/tests/rangecoder.c
@@ -48,7 +48,7 @@ int main(void)
 for (i = 0; i < SIZE; i++)
 put_rac(, state, r[i] & 1);
 
-ff_rac_terminate();
+ff_rac_terminate(, 0);
 
 ff_init_range_decoder(, b, SIZE);
 
-- 
2.19.2

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

[FFmpeg-devel] [PATCH 3/3] avcodec/rangecoder: Document ff_rac_terminate()

Signed-off-by: Michael Niedermayer 
---
 libavcodec/rangecoder.h | 8 
 1 file changed, 8 insertions(+)

diff --git a/libavcodec/rangecoder.h b/libavcodec/rangecoder.h
index e5c7a3cc71..4495f6df1a 100644
--- a/libavcodec/rangecoder.h
+++ b/libavcodec/rangecoder.h
@@ -48,7 +48,15 @@ typedef struct RangeCoder {
 
 void ff_init_range_encoder(RangeCoder *c, uint8_t *buf, int buf_size);
 void ff_init_range_decoder(RangeCoder *c, const uint8_t *buf, int buf_size);
+
+/**
+ * Terminates the range coder
+ * @param version version 0 requires the decoder to know the data size in bytes
+ *version 1 needs about 1 bit more space but does not need to
+ *  carry the size from encoder to decoder
+ */
 int ff_rac_terminate(RangeCoder *c, int version);
+
 void ff_build_rac_states(RangeCoder *c, int factor, int max_p);
 
 static inline void renorm_encoder(RangeCoder *c)
-- 
2.19.2

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

Re: [FFmpeg-devel] [PATCH] avcodec: add g732_1 parser

2018-12-18 Thread James Almer

On 12/18/2018 5:05 PM, Paul B Mahol wrote:
> Signed-off-by: Paul B Mahol 
> ---
>  libavcodec/Makefile|  1 +
>  libavcodec/g723_1_parser.c | 60 ++
>  libavcodec/parsers.c   |  1 +
>  libavcodec/utils.c |  2 --
>  4 files changed, 62 insertions(+), 2 deletions(-)
>  create mode 100644 libavcodec/g723_1_parser.c
> 
> diff --git a/libavcodec/Makefile b/libavcodec/Makefile
> index d53b8ff330..08f89ae0b2 100644
> --- a/libavcodec/Makefile
> +++ b/libavcodec/Makefile
> @@ -1025,6 +1025,7 @@ OBJS-$(CONFIG_DVD_NAV_PARSER)  += 
> dvd_nav_parser.o
>  OBJS-$(CONFIG_DVDSUB_PARSER)   += dvdsub_parser.o
>  OBJS-$(CONFIG_FLAC_PARSER) += flac_parser.o flacdata.o flac.o \
>vorbis_data.o
> +OBJS-$(CONFIG_G723_1_PARSER)   += g723_1_parser.o
>  OBJS-$(CONFIG_G729_PARSER) += g729_parser.o
>  OBJS-$(CONFIG_GIF_PARSER)  += gif_parser.o
>  OBJS-$(CONFIG_GSM_PARSER)  += gsm_parser.o
> diff --git a/libavcodec/g723_1_parser.c b/libavcodec/g723_1_parser.c
> new file mode 100644
> index 00..0305ca329d
> --- /dev/null
> +++ b/libavcodec/g723_1_parser.c
> @@ -0,0 +1,60 @@
> +/*
> + * This file is part of FFmpeg.
> + *
> + * FFmpeg is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU Lesser General Public
> + * License as published by the Free Software Foundation; either
> + * version 2.1 of the License, or (at your option) any later version.
> + *
> + * FFmpeg is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
> + * Lesser General Public License for more details.
> + *
> + * You should have received a copy of the GNU Lesser General Public
> + * License along with FFmpeg; if not, write to the Free Software
> + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 
> USA
> + */
> +
> +/**
> + * @file
> + * G723_1 audio parser
> + */
> +
> +#include "parser.h"
> +#include "g723_1.h"
> +
> +typedef struct G723_1ParseContext {
> +ParseContext pc;
> +} G723_1ParseContext;
> +
> +static int g723_1_parse(AVCodecParserContext *s1, AVCodecContext *avctx,
> +const uint8_t **poutbuf, int *poutbuf_size,
> +const uint8_t *buf, int buf_size)
> +{
> +G723_1ParseContext *s = s1->priv_data;
> +ParseContext *pc = >pc;
> +int next = END_NOT_FOUND;
> +
> +if (buf_size > 0)
> +next = frame_size[buf[0] & 3] * FFMAX(1, avctx->channels);

Did you test this using a pipe from a raw container or anything that may
effectively require the parser to assemble a full frame?

Also, the g723 demuxer seems to already propagate full frames using this
same check.

> +
> +if (ff_combine_frame(pc, next, , _size) < 0 || !buf_size) {
> +*poutbuf  = NULL;
> +*poutbuf_size = 0;
> +return buf_size;
> +}
> +
> +s1->duration = 240;
> +
> +*poutbuf  = buf;
> +*poutbuf_size = buf_size;
> +return next;
> +}
> +
> +AVCodecParser ff_g723_1_parser = {
> +.codec_ids  = { AV_CODEC_ID_G723_1 },
> +.priv_data_size = sizeof(G723_1ParseContext),
> +.parser_parse   = g723_1_parse,
> +.parser_close   = ff_parse_close,
> +};
> diff --git a/libavcodec/parsers.c b/libavcodec/parsers.c
> index eca95787ae..33a71de8a0 100644
> --- a/libavcodec/parsers.c
> +++ b/libavcodec/parsers.c
> @@ -40,6 +40,7 @@ extern AVCodecParser ff_dvbsub_parser;
>  extern AVCodecParser ff_dvdsub_parser;
>  extern AVCodecParser ff_dvd_nav_parser;
>  extern AVCodecParser ff_flac_parser;
> +extern AVCodecParser ff_g723_1_parser;
>  extern AVCodecParser ff_g729_parser;
>  extern AVCodecParser ff_gif_parser;
>  extern AVCodecParser ff_gsm_parser;
> diff --git a/libavcodec/utils.c b/libavcodec/utils.c
> index 2fa811d499..d519b16092 100644
> --- a/libavcodec/utils.c
> +++ b/libavcodec/utils.c
> @@ -1599,8 +1599,6 @@ static int get_audio_frame_duration(enum AVCodecID id, 
> int sr, int ch, int ba,
>  return 256 * (frame_bytes / 64);
>  if (id == AV_CODEC_ID_RA_144)
>  return 160 * (frame_bytes / 20);
> -if (id == AV_CODEC_ID_G723_1)
> -return 240 * (frame_bytes / 24);
>  
>  if (bps > 0) {
>  /* calc from frame_bytes and bits_per_coded_sample */
> 

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

Re: [FFmpeg-devel] [PATCH] avformat: add vividas demuxer

On 12/18/18, Tomas Härdin  wrote:
> sön 2018-12-16 klockan 22:28 +0100 skrev Paul B Mahol:
>> >
>> +static void track_header(VividasDemuxContext *viv, AVFormatContext
>> *s,  uint8_t *buf, int size)
>> +{
>> +[...]
>> +if (avio_tell(pb) < off) {
>> +int num_data;
>> +int xd_size = 0;
>> +int data_len[256];
>> +int offset = 1;
>> +uint8_t *p;
>> +ffio_read_varlen(pb); // val_13
>> +avio_r8(pb); // '19'
>> +ffio_read_varlen(pb); // len_3
>> +num_data = avio_r8(pb);
>> +for (j = 0; j < num_data; j++) {
>> +data_len[j] = ffio_read_varlen(pb);
>> +xd_size += data_len[j];
>> +}
>> +
>> +st->codecpar->extradata_size = 64 + xd_size + xd_size / 255;
>> +st->codecpar->extradata =
>> av_mallocz(st->codecpar->extradata_size);
>
> This is missing padding by AV_INPUT_BUFFER_PADDING_SIZE

Fixed locally. If thats all, I will apply it.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/2] avformat/nutenc: fix duration estimation by writing EOR packets

On 12/18/18, Michael Niedermayer  wrote:
> On Tue, Dec 18, 2018 at 02:56:54PM +0100, Paul B Mahol wrote:
>> Signed-off-by: Paul B Mahol 
>> ---
>>  libavformat/nut.h|   3 +
>>  libavformat/nutenc.c | 130 +--
>>  2 files changed, 129 insertions(+), 4 deletions(-)
>>
>> diff --git a/libavformat/nut.h b/libavformat/nut.h
>> index a4409ee23d..4b15dca1ea 100644
>> --- a/libavformat/nut.h
>> +++ b/libavformat/nut.h
>> @@ -76,6 +76,9 @@ typedef struct StreamContext {
>>  int last_flags;
>>  int skip_until_key_frame;
>>  int64_t last_pts;
>> +int64_t eor_pts;
>> +int64_t eor_dts;
>> +int eor_flushed;
>>  int time_base_id;
>>  AVRational *time_base;
>>  int msb_pts_shift;
>> diff --git a/libavformat/nutenc.c b/libavformat/nutenc.c
>> index e9a3bb49db..9d1c540a9d 100644
>> --- a/libavformat/nutenc.c
>> +++ b/libavformat/nutenc.c
>> @@ -940,6 +940,80 @@ fail:
>>  return ret;
>>  }
>>
>> +static void nut_update_max_pts(AVFormatContext *s, int stream_index,
>> int64_t pts)
>> +{
>> +NUTContext *nut = s->priv_data;
>> +StreamContext *nus = >stream[stream_index];
>> +
>> +if (!nut->max_pts_tb || av_compare_ts(nut->max_pts, *nut->max_pts_tb,
>> pts, *nus->time_base) < 0) {
>> +nut->max_pts = pts;
>> +nut->max_pts_tb = nus->time_base;
>> +}
>> +}
>> +
>> +static int nut_write_eor(AVFormatContext *s, AVPacket *pkt)
>> +{
>> +AVIOContext *bc = s->pb, *dyn_bc;
>> +NUTContext *nut = s->priv_data;
>> +StreamContext *nus = >stream[pkt->stream_index];
>> +int ret, frame_code, flags, needed_flags;
>> +int64_t pts = pkt->pts;
>> +int64_t coded_pts;
>> +FrameCode *fc;
>> +
>> +coded_pts = pts & ((1 << nus->msb_pts_shift) - 1);
>> +if (ff_lsb2full(nus, coded_pts) != pts)
>> +coded_pts = pts + (1 << nus->msb_pts_shift);
>> +
>> +nut->last_syncpoint_pos = avio_tell(bc);
>> +ret = avio_open_dyn_buf(_bc);
>> +if (ret < 0)
>> +return ret;
>> +put_tt(nut, nus->time_base, dyn_bc, pkt->dts);
>> +ff_put_v(dyn_bc, 0);
>> +
>> +if (nut->flags & NUT_BROADCAST) {
>> +put_tt(nut, nus->time_base, dyn_bc,
>> +   av_rescale_q(av_gettime(), AV_TIME_BASE_Q,
>> *nus->time_base));
>> +}
>> +put_packet(nut, bc, dyn_bc, 1, SYNCPOINT_STARTCODE);
>> +
>> +frame_code  = -1;
>> +for (int i = 0; i < 256; i++) {
>> +FrameCode *fc = >frame_code[i];
>> +int flags = fc->flags;
>> +
>> +if (flags & FLAG_INVALID)
>> +continue;
>> +
>> +if (!(flags & FLAG_CODED)) {
>> +continue;
>> +}
>> +
>> +frame_code = i;
>> +break;
>> +}
>> +av_assert0(frame_code != -1);
>> +
>> +fc   = >frame_code[frame_code];
>> +flags= fc->flags;
>> +needed_flags = FLAG_KEY | FLAG_EOR | FLAG_CODED_PTS |
>> FLAG_STREAM_ID;
>> +
>> +ffio_init_checksum(bc, ff_crc04C11DB7_update, 0);
>> +avio_w8(bc, frame_code);
>> +if (flags & FLAG_CODED) {
>> +ff_put_v(bc, (flags ^ needed_flags) & ~(FLAG_CODED));
>> +flags = needed_flags;
>> +}
>> +if (flags & FLAG_STREAM_ID)  ff_put_v(bc, pkt->stream_index);
>> +if (flags & FLAG_CODED_PTS)  ff_put_v(bc, coded_pts);
>> +ffio_get_checksum(bc);
>> +
>> +nut_update_max_pts(s, pkt->stream_index, pkt->pts);
>> +
>> +return 0;
>> +}
>> +
>>  static int nut_write_packet(AVFormatContext *s, AVPacket *pkt)
>>  {
>>  NUTContext *nut= s->priv_data;
>
>> @@ -956,6 +1030,9 @@ static int nut_write_packet(AVFormatContext *s,
>> AVPacket *pkt)
>>  int data_size = pkt->size;
>>  uint8_t *sm_buf = NULL;
>>
>> +if (!data_size)
>> +return nut_write_eor(s, pkt);
>
> that could happen for non EOR packets too

How would you solve it?

>
>
>> +
>>  if (pkt->pts < 0) {
>>  av_log(s, AV_LOG_ERROR,
>> "Negative pts not supported stream %d, pts %"PRId64"\n",
>> @@ -1150,10 +1227,7 @@ static int nut_write_packet(AVFormatContext *s,
>> AVPacket *pkt)
>>  nus->keyframe_pts[nut->sp_count] = pkt->pts;
>>  }
>>
>> -if (!nut->max_pts_tb || av_compare_ts(nut->max_pts, *nut->max_pts_tb,
>> pkt->pts, *nus->time_base) < 0) {
>> -nut->max_pts = pkt->pts;
>> -nut->max_pts_tb = nus->time_base;
>> -}
>> +nut_update_max_pts(s, pkt->stream_index, pkt->pts);
>>
>>  fail:
>>  av_freep(_buf);
>> @@ -1161,6 +1235,53 @@ fail:
>>  return ret;
>>  }
>>
>> +static int nut_interleave_packet(AVFormatContext *s, AVPacket *out,
>> + AVPacket *pkt, int flush)
>> +{
>> +NUTContext *nut = s->priv_data;
>> +int ret;
>> +
>> +if (pkt) {
>> +StreamContext *nus = >stream[pkt->stream_index];
>> +
>> +nus->eor_pts = FFMAX(pkt->pts + pkt->duration, nus->eor_pts);
>> +nus->eor_dts = FFMAX(pkt->dts + pkt->duration, nus->eor_dts);
>> +} else

[FFmpeg-devel] [PATCH] Add HDR dynamic metadata struct (for SPMTE 2094-40) to libavutil.

2018-12-18 Thread Mohammad Izadi

From: Mohammad Izadi 

The dynamic metadata contains data for color volume transform - application 4 
of SPMTE 2094-40:2016 standard. The data comes from HEVC in the 
SEI_TYPE_USER_DATA_REGISTERED_ITU_T_T35.

I'll add support to HEVC in a follow-up.
---
 libavutil/Makefile   |   2 +
 libavutil/frame.c|   1 +
 libavutil/frame.h|   7 +
 libavutil/hdr_dynamic_metadata.c |  47 +
 libavutil/hdr_dynamic_metadata.h | 344 +++
 libavutil/version.h  |   2 +-
 6 files changed, 402 insertions(+), 1 deletion(-)
 create mode 100644 libavutil/hdr_dynamic_metadata.c
 create mode 100644 libavutil/hdr_dynamic_metadata.h

diff --git a/libavutil/Makefile b/libavutil/Makefile
index caddc7e155..7dcb92b06b 100644
--- a/libavutil/Makefile
+++ b/libavutil/Makefile
@@ -31,6 +31,7 @@ HEADERS = adler32.h   
  \
   file.h\
   frame.h   \
   hash.h\
+  hdr_dynamic_metadata.h\
   hmac.h\
   hwcontext.h   \
   hwcontext_cuda.h  \
@@ -119,6 +120,7 @@ OBJS = adler32.o
\
fixed_dsp.o  \
frame.o  \
hash.o   \
+   hdr_dynamic_metadata.o   \
hmac.o   \
hwcontext.o  \
imgutils.o   \
diff --git a/libavutil/frame.c b/libavutil/frame.c
index 9b3fb13e68..34a6210d9e 100644
--- a/libavutil/frame.c
+++ b/libavutil/frame.c
@@ -840,6 +840,7 @@ const char *av_frame_side_data_name(enum 
AVFrameSideDataType type)
 case AV_FRAME_DATA_QP_TABLE_PROPERTIES: return "QP table 
properties";
 case AV_FRAME_DATA_QP_TABLE_DATA:   return "QP table data";
 #endif
+case AV_FRAME_DATA_DYNAMIC_HDR_PLUS: return "HDR Dynamic Metadata 
SMPTE2094-40 (HDR10+)";
 }
 return NULL;
 }
diff --git a/libavutil/frame.h b/libavutil/frame.h
index 66f27f44bd..4de3d4e6d1 100644
--- a/libavutil/frame.h
+++ b/libavutil/frame.h
@@ -166,6 +166,13 @@ enum AVFrameSideDataType {
  * function in libavutil/timecode.c.
  */
 AV_FRAME_DATA_S12M_TIMECODE,
+
+/**
+ * HDR dynamic metadata associated with a video frame. The payload is
+ * an AVDynamicHDRPlus type and contains information for color
+ * volume transform - application 4 of SPMTE 2094-40:2016 standard.
+ */
+AV_FRAME_DATA_DYNAMIC_HDR_PLUS,
 };
 
 enum AVActiveFormatDescription {
diff --git a/libavutil/hdr_dynamic_metadata.c b/libavutil/hdr_dynamic_metadata.c
new file mode 100644
index 00..7e4d7dec10
--- /dev/null
+++ b/libavutil/hdr_dynamic_metadata.c
@@ -0,0 +1,47 @@
+/**
+ * Copyright (c) 2018 Mohammad Izadi 
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include "hdr_dynamic_metadata.h"
+#include "mem.h"
+
+AVDynamicHDRPlus *av_dynamic_hdr_plus_alloc(size_t *size)
+{
+AVDynamicHDRPlus *hdr_plus = av_mallocz(sizeof(AVDynamicHDRPlus));
+if (!hdr_plus)
+return NULL;
+
+if (size)
+*size = sizeof(*hdr_plus);
+
+return hdr_plus;
+}
+
+AVDynamicHDRPlus *av_dynamic_hdr_plus_create_side_data(AVFrame *frame)
+{
+AVFrameSideData *side_data = av_frame_new_side_data(frame,
+
AV_FRAME_DATA_DYNAMIC_HDR_PLUS,
+
sizeof(AVDynamicHDRPlus));
+if (!side_data)
+return NULL;
+
+memset(side_data->data, 0, sizeof(AVDynamicHDRPlus));
+
+return (AVDynamicHDRPlus *)side_data->data;
+}
diff --git

[FFmpeg-devel] [PATCH] fix infinite loop for ff_rtsp_connect when failure of connection after redirection

2018-12-18 Thread tianhu yang

---
 libavformat/rtsp.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/libavformat/rtsp.c b/libavformat/rtsp.c
index ceb770a3a4..af3e112152 100644
--- a/libavformat/rtsp.c
+++ b/libavformat/rtsp.c
@@ -1923,6 +1923,7 @@ redirect:
 av_log(s, AV_LOG_INFO, "Status %d: Redirecting to %s\n",
reply->status_code,
s->url);
+reply->status_code = 0;
 goto redirect;
 }
  fail2:
-- 
2.11.0 (Apple Git-81)
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/2] avformat/nutenc: fix duration estimation by writing EOR packets

On Tue, Dec 18, 2018 at 02:56:54PM +0100, Paul B Mahol wrote:
> Signed-off-by: Paul B Mahol 
> ---
>  libavformat/nut.h|   3 +
>  libavformat/nutenc.c | 130 +--
>  2 files changed, 129 insertions(+), 4 deletions(-)
> 
> diff --git a/libavformat/nut.h b/libavformat/nut.h
> index a4409ee23d..4b15dca1ea 100644
> --- a/libavformat/nut.h
> +++ b/libavformat/nut.h
> @@ -76,6 +76,9 @@ typedef struct StreamContext {
>  int last_flags;
>  int skip_until_key_frame;
>  int64_t last_pts;
> +int64_t eor_pts;
> +int64_t eor_dts;
> +int eor_flushed;
>  int time_base_id;
>  AVRational *time_base;
>  int msb_pts_shift;
> diff --git a/libavformat/nutenc.c b/libavformat/nutenc.c
> index e9a3bb49db..9d1c540a9d 100644
> --- a/libavformat/nutenc.c
> +++ b/libavformat/nutenc.c
> @@ -940,6 +940,80 @@ fail:
>  return ret;
>  }
>  
> +static void nut_update_max_pts(AVFormatContext *s, int stream_index, int64_t 
> pts)
> +{
> +NUTContext *nut = s->priv_data;
> +StreamContext *nus = >stream[stream_index];
> +
> +if (!nut->max_pts_tb || av_compare_ts(nut->max_pts, *nut->max_pts_tb, 
> pts, *nus->time_base) < 0) {
> +nut->max_pts = pts;
> +nut->max_pts_tb = nus->time_base;
> +}
> +}
> +
> +static int nut_write_eor(AVFormatContext *s, AVPacket *pkt)
> +{
> +AVIOContext *bc = s->pb, *dyn_bc;
> +NUTContext *nut = s->priv_data;
> +StreamContext *nus = >stream[pkt->stream_index];
> +int ret, frame_code, flags, needed_flags;
> +int64_t pts = pkt->pts;
> +int64_t coded_pts;
> +FrameCode *fc;
> +
> +coded_pts = pts & ((1 << nus->msb_pts_shift) - 1);
> +if (ff_lsb2full(nus, coded_pts) != pts)
> +coded_pts = pts + (1 << nus->msb_pts_shift);
> +
> +nut->last_syncpoint_pos = avio_tell(bc);
> +ret = avio_open_dyn_buf(_bc);
> +if (ret < 0)
> +return ret;
> +put_tt(nut, nus->time_base, dyn_bc, pkt->dts);
> +ff_put_v(dyn_bc, 0);
> +
> +if (nut->flags & NUT_BROADCAST) {
> +put_tt(nut, nus->time_base, dyn_bc,
> +   av_rescale_q(av_gettime(), AV_TIME_BASE_Q, *nus->time_base));
> +}
> +put_packet(nut, bc, dyn_bc, 1, SYNCPOINT_STARTCODE);
> +
> +frame_code  = -1;
> +for (int i = 0; i < 256; i++) {
> +FrameCode *fc = >frame_code[i];
> +int flags = fc->flags;
> +
> +if (flags & FLAG_INVALID)
> +continue;
> +
> +if (!(flags & FLAG_CODED)) {
> +continue;
> +}
> +
> +frame_code = i;
> +break;
> +}
> +av_assert0(frame_code != -1);
> +
> +fc   = >frame_code[frame_code];
> +flags= fc->flags;
> +needed_flags = FLAG_KEY | FLAG_EOR | FLAG_CODED_PTS | FLAG_STREAM_ID;
> +
> +ffio_init_checksum(bc, ff_crc04C11DB7_update, 0);
> +avio_w8(bc, frame_code);
> +if (flags & FLAG_CODED) {
> +ff_put_v(bc, (flags ^ needed_flags) & ~(FLAG_CODED));
> +flags = needed_flags;
> +}
> +if (flags & FLAG_STREAM_ID)  ff_put_v(bc, pkt->stream_index);
> +if (flags & FLAG_CODED_PTS)  ff_put_v(bc, coded_pts);
> +ffio_get_checksum(bc);
> +
> +nut_update_max_pts(s, pkt->stream_index, pkt->pts);
> +
> +return 0;
> +}
> +
>  static int nut_write_packet(AVFormatContext *s, AVPacket *pkt)
>  {
>  NUTContext *nut= s->priv_data;

> @@ -956,6 +1030,9 @@ static int nut_write_packet(AVFormatContext *s, AVPacket 
> *pkt)
>  int data_size = pkt->size;
>  uint8_t *sm_buf = NULL;
>  
> +if (!data_size)
> +return nut_write_eor(s, pkt);

that could happen for non EOR packets too


> +
>  if (pkt->pts < 0) {
>  av_log(s, AV_LOG_ERROR,
> "Negative pts not supported stream %d, pts %"PRId64"\n",
> @@ -1150,10 +1227,7 @@ static int nut_write_packet(AVFormatContext *s, 
> AVPacket *pkt)
>  nus->keyframe_pts[nut->sp_count] = pkt->pts;
>  }
>  
> -if (!nut->max_pts_tb || av_compare_ts(nut->max_pts, *nut->max_pts_tb, 
> pkt->pts, *nus->time_base) < 0) {
> -nut->max_pts = pkt->pts;
> -nut->max_pts_tb = nus->time_base;
> -}
> +nut_update_max_pts(s, pkt->stream_index, pkt->pts);
>  
>  fail:
>  av_freep(_buf);
> @@ -1161,6 +1235,53 @@ fail:
>  return ret;
>  }
>  
> +static int nut_interleave_packet(AVFormatContext *s, AVPacket *out,
> + AVPacket *pkt, int flush)
> +{
> +NUTContext *nut = s->priv_data;
> +int ret;
> +
> +if (pkt) {
> +StreamContext *nus = >stream[pkt->stream_index];
> +
> +nus->eor_pts = FFMAX(pkt->pts + pkt->duration, nus->eor_pts);
> +nus->eor_dts = FFMAX(pkt->dts + pkt->duration, nus->eor_dts);
> +} else if (flush) {
> +StreamContext *nus;
> +int i;
> +
> +for (i = 0; i < s->nb_streams; i++) {
> +nus = >stream[i];
> +
> +if (nus->eor_flushed)
> +

[FFmpeg-devel] [PATCH] avcodec: add g732_1 parser

Signed-off-by: Paul B Mahol 
---
 libavcodec/Makefile|  1 +
 libavcodec/g723_1_parser.c | 60 ++
 libavcodec/parsers.c   |  1 +
 libavcodec/utils.c |  2 --
 4 files changed, 62 insertions(+), 2 deletions(-)
 create mode 100644 libavcodec/g723_1_parser.c

diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index d53b8ff330..08f89ae0b2 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -1025,6 +1025,7 @@ OBJS-$(CONFIG_DVD_NAV_PARSER)  += dvd_nav_parser.o
 OBJS-$(CONFIG_DVDSUB_PARSER)   += dvdsub_parser.o
 OBJS-$(CONFIG_FLAC_PARSER) += flac_parser.o flacdata.o flac.o \
   vorbis_data.o
+OBJS-$(CONFIG_G723_1_PARSER)   += g723_1_parser.o
 OBJS-$(CONFIG_G729_PARSER) += g729_parser.o
 OBJS-$(CONFIG_GIF_PARSER)  += gif_parser.o
 OBJS-$(CONFIG_GSM_PARSER)  += gsm_parser.o
diff --git a/libavcodec/g723_1_parser.c b/libavcodec/g723_1_parser.c
new file mode 100644
index 00..0305ca329d
--- /dev/null
+++ b/libavcodec/g723_1_parser.c
@@ -0,0 +1,60 @@
+/*
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+/**
+ * @file
+ * G723_1 audio parser
+ */
+
+#include "parser.h"
+#include "g723_1.h"
+
+typedef struct G723_1ParseContext {
+ParseContext pc;
+} G723_1ParseContext;
+
+static int g723_1_parse(AVCodecParserContext *s1, AVCodecContext *avctx,
+const uint8_t **poutbuf, int *poutbuf_size,
+const uint8_t *buf, int buf_size)
+{
+G723_1ParseContext *s = s1->priv_data;
+ParseContext *pc = >pc;
+int next = END_NOT_FOUND;
+
+if (buf_size > 0)
+next = frame_size[buf[0] & 3] * FFMAX(1, avctx->channels);
+
+if (ff_combine_frame(pc, next, , _size) < 0 || !buf_size) {
+*poutbuf  = NULL;
+*poutbuf_size = 0;
+return buf_size;
+}
+
+s1->duration = 240;
+
+*poutbuf  = buf;
+*poutbuf_size = buf_size;
+return next;
+}
+
+AVCodecParser ff_g723_1_parser = {
+.codec_ids  = { AV_CODEC_ID_G723_1 },
+.priv_data_size = sizeof(G723_1ParseContext),
+.parser_parse   = g723_1_parse,
+.parser_close   = ff_parse_close,
+};
diff --git a/libavcodec/parsers.c b/libavcodec/parsers.c
index eca95787ae..33a71de8a0 100644
--- a/libavcodec/parsers.c
+++ b/libavcodec/parsers.c
@@ -40,6 +40,7 @@ extern AVCodecParser ff_dvbsub_parser;
 extern AVCodecParser ff_dvdsub_parser;
 extern AVCodecParser ff_dvd_nav_parser;
 extern AVCodecParser ff_flac_parser;
+extern AVCodecParser ff_g723_1_parser;
 extern AVCodecParser ff_g729_parser;
 extern AVCodecParser ff_gif_parser;
 extern AVCodecParser ff_gsm_parser;
diff --git a/libavcodec/utils.c b/libavcodec/utils.c
index 2fa811d499..d519b16092 100644
--- a/libavcodec/utils.c
+++ b/libavcodec/utils.c
@@ -1599,8 +1599,6 @@ static int get_audio_frame_duration(enum AVCodecID id, 
int sr, int ch, int ba,
 return 256 * (frame_bytes / 64);
 if (id == AV_CODEC_ID_RA_144)
 return 160 * (frame_bytes / 20);
-if (id == AV_CODEC_ID_G723_1)
-return 240 * (frame_bytes / 24);
 
 if (bps > 0) {
 /* calc from frame_bytes and bits_per_coded_sample */
-- 
2.17.1

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

Re: [FFmpeg-devel] aptX codec in RIFF wave container

On 12/18/18, Pali Rohár  wrote:
> Hello,
>
> it looks like that audio encoded by aptX (non-hd) codec can be stored in
> RIFF wave container. Look into old Microsoft Multimedia document named
> "New Multimedia Data Types and Data Techniques" from April 15, 1994.
>
> http://web.archive.org/web/20120917060438/http://download.microsoft.com/download/9/8/6/9863C72A-A3AA-4DDB-B1BA-CA8D17EFD2D4/RIFFNEW.pdf
>
> It was available on Microsoft website, but now is only in webarchive.
>
> At page 45 is described WAVE format header with allocated id for aptX.
>
> #define WAVE_FORMAT_APTX (0x0025)
>
> Description of compression on that page really matches aptX (non-hd)
> codec which is already supported by ffmpeg.
>
> So... could you add support for storing aptX encoded audio to RIFF wave
> container? Currently ffmpeg can store aptX only into "raw" container, so
> there is no information about frequency or channels. And above document
> describe that frequency and number of channels can be stored in RIFF
> wave also for aptX payload.

No, because we need actual samples.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] aptX codec in RIFF wave container

2018-12-18 Thread Pali Rohár

Hello,

it looks like that audio encoded by aptX (non-hd) codec can be stored in
RIFF wave container. Look into old Microsoft Multimedia document named
"New Multimedia Data Types and Data Techniques" from April 15, 1994.

http://web.archive.org/web/20120917060438/http://download.microsoft.com/download/9/8/6/9863C72A-A3AA-4DDB-B1BA-CA8D17EFD2D4/RIFFNEW.pdf

It was available on Microsoft website, but now is only in webarchive.

At page 45 is described WAVE format header with allocated id for aptX.

#define WAVE_FORMAT_APTX (0x0025)

Description of compression on that page really matches aptX (non-hd)
codec which is already supported by ffmpeg.

So... could you add support for storing aptX encoded audio to RIFF wave
container? Currently ffmpeg can store aptX only into "raw" container, so
there is no information about frequency or channels. And above document
describe that frequency and number of channels can be stored in RIFF
wave also for aptX payload.

Below is copy of page 45 from that PDF document:

Audio Processing Technology Wave Type

Added: 06/22/93
Author: Calypso Software Limited

Fact Chunk

This chunk is required for all WAVE formats other than WAVE_FORMAT_PCM. It
stores file dependent
information about the contents of the WAVE data. It currently specifies the
length of the data in samples.

WAVE Format Header

#define WAVE_FORMAT_APTX
(0x0025)

wFormatTag This must be set to WAVE_FORMAT_APTX.
nChannels Number of channels in the wave, always 1 for
mono, 2 for stereo.
nSamplesPerSec Frequency of the sample rate of the wave file.
(8000, 11025, 22050, 44100,
48000)
nAvgBytesPerSec Average data rate..= nChannels *
nSamplesPerSec/2. (16bit audio)
Playback software can estimate the buffer size
using the
value.
nBlockAlign Should be set to 2 (bytes) for mono data or 4
(bytes) for stereo.
For mono data 4 sixteen bit samples will be
compressed into 1 sixteen bit
word
For stereo data 4 sizteen bit left channel
samples will be compressed into the
first 16bit word and 4 sixteen bit right
channel samples will be cmpressed into
the next 16 bit word.
Playback software needs to process a multiple
of bytes of data
at a time, so that the value of
can be used for buffer
alignment.
wBitsPerSample This is the number of bits per sample. Not
used; set to four.
cbSize The size in bytes of the extra information in
the extended WAVE 'fmt'
header. This should be 0.(zero)

The definition of the data contained in the APTX format is considered
proprietary information of Audio
Processing Technology Limited. They can be contacted at:

Audio Processing Technology Limited
Edgewater Road
Belfast, Northern Ireland, BT3 9QJ
Tel 44 232 371110
Fax 44 232 371137

This format is proprietary audio format using 4:1 compression i.c. 16 bits of
audio are compressed to 4
bits. It is only encoded/decoded by dedicated hardware from MM_APT

Multimedia Data Standards Update April 15, 1994 Page 45 of 73

--
Pali Rohár
pali.ro...@gmail.com

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

Re: [FFmpeg-devel] [PATCH 1/2] ffmpeg: improve the intra stream discontinuity message

On Thu, Oct 11, 2018 at 2:29 PM Michael Niedermayer
 wrote:
>
> On Wed, Oct 10, 2018 at 02:10:25AM +0300, Jan Ekström wrote:
> > Now it actually tells which stream from which input and of
> > which type had an absolute DTS discontinuity larger than
> > dts_delta_threshold.
> > ---
> >  fftools/ffmpeg.c | 5 -
> >  1 file changed, 4 insertions(+), 1 deletion(-)
>
> should be ok
>
> thx
>

Replying a bit late, but thank you for the review, will rebase and apply :) .

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

Re: [FFmpeg-devel] [PATCH] avcodec/mips: [loongson] fix failed case: hevc-conformance-AMP_A_Samsung_* in loongson2k

2018-12-18 2:15 GMT+01:00, gxw :
> The AV_INPUT_BUFFER_PADDING_SIZE has been increased to 64, but the value is
> still 32
> in function ff_hevc_sao_edge_filter_8_msa. So, Modify the corresponding
> value to 64.
> Fate tests passed.
> ---
>  libavcodec/mips/hevc_lpf_sao_msa.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavcodec/mips/hevc_lpf_sao_msa.c
> b/libavcodec/mips/hevc_lpf_sao_msa.c
> index 5b5537a..bb883d0 100644
> --- a/libavcodec/mips/hevc_lpf_sao_msa.c
> +++ b/libavcodec/mips/hevc_lpf_sao_msa.c
> @@ -2630,7 +2630,7 @@ void ff_hevc_sao_edge_filter_8_msa(uint8_t *dst,
> uint8_t *src,
> int16_t *sao_offset_val,
> int eo, int width, int height)
>  {
> -ptrdiff_t stride_src = (2 * 64 + 32) / sizeof(uint8_t);

> +ptrdiff_t stride_src = (2 * 64 + 64) / sizeof(uint8_t);

You could also drop the sizeof as FFmpeg requires it to be 1.

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

Re: [FFmpeg-devel] [PATCH 1/2 v3] lavf/isom: add Dolby Vision sample entry codes for HEVC and H.264

2018-12-18 19:16 GMT+01:00, Jan Ekström :
> On Tue, Dec 18, 2018 at 8:05 PM Carl Eugen Hoyos  wrote:
>>
>> 2018-12-18 18:38 GMT+01:00, Jan Ekström :
>> > On Tue, Dec 18, 2018 at 7:30 PM Carl Eugen Hoyos 
>> > wrote:
>> >>
>> >> 2018-12-18 18:24 GMT+01:00, Jan Ekström :
>> >> > On Tue, Dec 18, 2018 at 7:21 PM Carl Eugen Hoyos 
>> >> > wrote:
>> >> >>
>> >> >> 2018-12-18 18:17 GMT+01:00, Jan Ekström :
>> >> >> > On Mon, Dec 17, 2018 at 10:17 PM Jan Ekström 
>> >> >> > wrote:
>> >> >> >>
>> >> >> >> On Mon, Dec 17, 2018 at 3:47 PM Carl Eugen Hoyos
>> >> >> >> 
>> >> >> >> wrote:
>> >> >> >> >
>> >> >> >> > 2018-12-17 7:58 GMT+01:00, Jan Ekström :
>> >> >> >> > > On Mon, Dec 17, 2018, 03:02 Carl Eugen Hoyos
>> >> >> >> > > > >> >> >> > > wrote:
>> >> >> >> > >
>> >> >> >> > >> 2018-12-17 1:58 GMT+01:00, Jan Ekström :
>> >> >> >> >
>> >> >> >> > >> > So as far as it's been possible to test this, that's been
>> >> >> >> > >> > done
>> >> >> >> > >>
>> >> >> >> > >> Could you point me to a dva1 sample?
>> >> >> >> > >
>> >> >> >> > > I have not seen any dolby vision samples with avc in the
>> >> >> >> > > wild.
>> >> >> >> > > You can ask Vittorio if he has some as he noted about
>> >> >> >> > > possibly being able to ask for some before.
>> >> >> >> >
>> >> >> >> > The patch is of course ok if Vittorio tested it with his
>> >> >> >> > samples.
>> >> >> >> >
>> >> >> >> > Thank you, Carl Eugen
>> >> >> >>
>> >> >> >> Unfortunately I have no idea what samples Vittorio does or does
>> >> >> >> not
>> >> >> >> possess, he has only mentioned off-hand that he might able to get
>> >> >> >> hold
>> >> >> >> of some if required. And since you were the one requiring them, I
>> >> >> >> pointed you towards him.
>> >> >> >>
>> >> >> >> For myself, I am happy with the following points regarding this:
>> >> >> >> 1. The identifiers are registered at the MPEG-4 RA.
>> >> >> >> 2. There is a proper specification for these mappings that is
>> >> >> >> seemingly kept up-to-date.
>> >> >> >> 3. The mappings specification specifically notes that the only
>> >> >> >> difference between the AVC and HEVC identifiers are the semantics
>> >> >> >> mentioned in ISO/IEC 14496-15. We already have all of the
>> >> >> >> identifiers
>> >> >> >> specified which these mappings are based upon, so those semantics
>> >> >> >> should not matter to us (and if they do, we have already broken
>> >> >> >> those
>> >> >> >> constraints at this point).
>> >> >> >> 4. The mapping specification specifically notes that the given
>> >> >> >> AVC
>> >> >> >> and
>> >> >> >> HEVC identifiers must also include the standard avcC and hvcC
>> >> >> >> boxes
>> >> >> >> so
>> >> >> >> that they can be decoded normally without any additional custom
>> >> >> >> code.
>> >> >> >> 5. We have samples for at least one of the four identifiers that
>> >> >> >> matches points 1 to 4.
>> >> >> >> 6. Android, Chromium, VLC among others have already implemented
>> >> >> >> these
>> >> >> >> identifiers in the same way.
>> >> >> >>
>> >> >> >> Now, if you are not happy with these points, then please clearly
>> >> >> >> state
>> >> >> >> that you are blocking any and all additional identifier additions
>> >> >> >> -
>> >> >> >> no
>> >> >> >> matter how specified - as long as there are no samples on hand
>> >> >> >> for
>> >> >> >> them.
>> >> >> >
>> >> >> > After taking a second look at this sentence, I find this wording
>> >> >> > being
>> >> >> > loaded and antagonizing. It was unprofessional, and I apologize
>> >> >> > for
>> >> >> > it.
>> >> >> >
>> >> >> > But the wish underneath was to get a clear view into what it was
>> >> >> > it
>> >> >> > that you wanted. That was what was mostly clouded for me in your
>> >> >> > replies, and that annoyed me to no end.
>> >> >> >
>> >> >> > While I must say that I would have been happy if you had told me
>> >> >> > you
>> >> >> > were not blocking the patch (set), I did not want a specific
>> >> >> > outcome
>> >> >> > out of this sentence. I just wanted you to voice your level of
>> >> >> > discomfort with the patch (set) and to voice your current wishes
>> >> >> > regarding it. I had set my wishes on the table with the six
>> >> >> > points,
>> >> >> > and why I believed the patch (set) was fine as it was.
>> >> >> >
>> >> >> > That is why after I wrote this post I asked Michael what it was
>> >> >> > that
>> >> >> > was the procedure for cases where developers have seemingly
>> >> >> > irreconcilable differences in opinions regarding a patch set. I
>> >> >> > did
>> >> >> > not know if that was the case, but the main point was that in the
>> >> >> > unfortunate case that the patch was blocked, and we did not agree
>> >> >> > on
>> >> >> > some points heavily enough that we could not co-operate, that the
>> >> >> > next
>> >> >> > step could be taken right away so as to not have the patch (set)
>> >> >> > sit
>> >> >> > there untouched for another week or two.
>> >> >> >
>> >> >> > Unfortunately, you did not respond to or touch

Re: [FFmpeg-devel] [PATCH 1/2 v3] lavf/isom: add Dolby Vision sample entry codes for HEVC and H.264

On Tue, Dec 18, 2018 at 8:05 PM Carl Eugen Hoyos  wrote:
>
> 2018-12-18 18:38 GMT+01:00, Jan Ekström :
> > On Tue, Dec 18, 2018 at 7:30 PM Carl Eugen Hoyos  wrote:
> >>
> >> 2018-12-18 18:24 GMT+01:00, Jan Ekström :
> >> > On Tue, Dec 18, 2018 at 7:21 PM Carl Eugen Hoyos 
> >> > wrote:
> >> >>
> >> >> 2018-12-18 18:17 GMT+01:00, Jan Ekström :
> >> >> > On Mon, Dec 17, 2018 at 10:17 PM Jan Ekström 
> >> >> > wrote:
> >> >> >>
> >> >> >> On Mon, Dec 17, 2018 at 3:47 PM Carl Eugen Hoyos
> >> >> >> 
> >> >> >> wrote:
> >> >> >> >
> >> >> >> > 2018-12-17 7:58 GMT+01:00, Jan Ekström :
> >> >> >> > > On Mon, Dec 17, 2018, 03:02 Carl Eugen Hoyos  >> >> >> > > wrote:
> >> >> >> > >
> >> >> >> > >> 2018-12-17 1:58 GMT+01:00, Jan Ekström :
> >> >> >> >
> >> >> >> > >> > So as far as it's been possible to test this, that's been
> >> >> >> > >> > done
> >> >> >> > >>
> >> >> >> > >> Could you point me to a dva1 sample?
> >> >> >> > >
> >> >> >> > > I have not seen any dolby vision samples with avc in the wild.
> >> >> >> > > You can ask Vittorio if he has some as he noted about
> >> >> >> > > possibly being able to ask for some before.
> >> >> >> >
> >> >> >> > The patch is of course ok if Vittorio tested it with his samples.
> >> >> >> >
> >> >> >> > Thank you, Carl Eugen
> >> >> >>
> >> >> >> Unfortunately I have no idea what samples Vittorio does or does not
> >> >> >> possess, he has only mentioned off-hand that he might able to get
> >> >> >> hold
> >> >> >> of some if required. And since you were the one requiring them, I
> >> >> >> pointed you towards him.
> >> >> >>
> >> >> >> For myself, I am happy with the following points regarding this:
> >> >> >> 1. The identifiers are registered at the MPEG-4 RA.
> >> >> >> 2. There is a proper specification for these mappings that is
> >> >> >> seemingly kept up-to-date.
> >> >> >> 3. The mappings specification specifically notes that the only
> >> >> >> difference between the AVC and HEVC identifiers are the semantics
> >> >> >> mentioned in ISO/IEC 14496-15. We already have all of the
> >> >> >> identifiers
> >> >> >> specified which these mappings are based upon, so those semantics
> >> >> >> should not matter to us (and if they do, we have already broken
> >> >> >> those
> >> >> >> constraints at this point).
> >> >> >> 4. The mapping specification specifically notes that the given AVC
> >> >> >> and
> >> >> >> HEVC identifiers must also include the standard avcC and hvcC boxes
> >> >> >> so
> >> >> >> that they can be decoded normally without any additional custom
> >> >> >> code.
> >> >> >> 5. We have samples for at least one of the four identifiers that
> >> >> >> matches points 1 to 4.
> >> >> >> 6. Android, Chromium, VLC among others have already implemented
> >> >> >> these
> >> >> >> identifiers in the same way.
> >> >> >>
> >> >> >> Now, if you are not happy with these points, then please clearly
> >> >> >> state
> >> >> >> that you are blocking any and all additional identifier additions -
> >> >> >> no
> >> >> >> matter how specified - as long as there are no samples on hand for
> >> >> >> them.
> >> >> >
> >> >> > After taking a second look at this sentence, I find this wording
> >> >> > being
> >> >> > loaded and antagonizing. It was unprofessional, and I apologize for
> >> >> > it.
> >> >> >
> >> >> > But the wish underneath was to get a clear view into what it was it
> >> >> > that you wanted. That was what was mostly clouded for me in your
> >> >> > replies, and that annoyed me to no end.
> >> >> >
> >> >> > While I must say that I would have been happy if you had told me you
> >> >> > were not blocking the patch (set), I did not want a specific outcome
> >> >> > out of this sentence. I just wanted you to voice your level of
> >> >> > discomfort with the patch (set) and to voice your current wishes
> >> >> > regarding it. I had set my wishes on the table with the six points,
> >> >> > and why I believed the patch (set) was fine as it was.
> >> >> >
> >> >> > That is why after I wrote this post I asked Michael what it was that
> >> >> > was the procedure for cases where developers have seemingly
> >> >> > irreconcilable differences in opinions regarding a patch set. I did
> >> >> > not know if that was the case, but the main point was that in the
> >> >> > unfortunate case that the patch was blocked, and we did not agree on
> >> >> > some points heavily enough that we could not co-operate, that the
> >> >> > next
> >> >> > step could be taken right away so as to not have the patch (set) sit
> >> >> > there untouched for another week or two.
> >> >> >
> >> >> > Unfortunately, you did not respond to or touch this sentence at all,
> >> >> > which I then interpreted as your comments not being blockers.
> >> >>
> >> >> > I hope this makes my intentions and annoyances clear.
> >> >>
> >> >> Afaict, it contradicts what you wrote on irc yesterday.
> >> >>
> >> >> > I hope that in
> >> >> > the future we can continue to co-operate, and that this makes it
> >>

Re: [FFmpeg-devel] [PATCH 1/2 v3] lavf/isom: add Dolby Vision sample entry codes for HEVC and H.264

2018-12-18 18:38 GMT+01:00, Jan Ekström :
> On Tue, Dec 18, 2018 at 7:30 PM Carl Eugen Hoyos  wrote:
>>
>> 2018-12-18 18:24 GMT+01:00, Jan Ekström :
>> > On Tue, Dec 18, 2018 at 7:21 PM Carl Eugen Hoyos 
>> > wrote:
>> >>
>> >> 2018-12-18 18:17 GMT+01:00, Jan Ekström :
>> >> > On Mon, Dec 17, 2018 at 10:17 PM Jan Ekström 
>> >> > wrote:
>> >> >>
>> >> >> On Mon, Dec 17, 2018 at 3:47 PM Carl Eugen Hoyos
>> >> >> 
>> >> >> wrote:
>> >> >> >
>> >> >> > 2018-12-17 7:58 GMT+01:00, Jan Ekström :
>> >> >> > > On Mon, Dec 17, 2018, 03:02 Carl Eugen Hoyos > >> >> > > wrote:
>> >> >> > >
>> >> >> > >> 2018-12-17 1:58 GMT+01:00, Jan Ekström :
>> >> >> >
>> >> >> > >> > So as far as it's been possible to test this, that's been
>> >> >> > >> > done
>> >> >> > >>
>> >> >> > >> Could you point me to a dva1 sample?
>> >> >> > >
>> >> >> > > I have not seen any dolby vision samples with avc in the wild.
>> >> >> > > You can ask Vittorio if he has some as he noted about
>> >> >> > > possibly being able to ask for some before.
>> >> >> >
>> >> >> > The patch is of course ok if Vittorio tested it with his samples.
>> >> >> >
>> >> >> > Thank you, Carl Eugen
>> >> >>
>> >> >> Unfortunately I have no idea what samples Vittorio does or does not
>> >> >> possess, he has only mentioned off-hand that he might able to get
>> >> >> hold
>> >> >> of some if required. And since you were the one requiring them, I
>> >> >> pointed you towards him.
>> >> >>
>> >> >> For myself, I am happy with the following points regarding this:
>> >> >> 1. The identifiers are registered at the MPEG-4 RA.
>> >> >> 2. There is a proper specification for these mappings that is
>> >> >> seemingly kept up-to-date.
>> >> >> 3. The mappings specification specifically notes that the only
>> >> >> difference between the AVC and HEVC identifiers are the semantics
>> >> >> mentioned in ISO/IEC 14496-15. We already have all of the
>> >> >> identifiers
>> >> >> specified which these mappings are based upon, so those semantics
>> >> >> should not matter to us (and if they do, we have already broken
>> >> >> those
>> >> >> constraints at this point).
>> >> >> 4. The mapping specification specifically notes that the given AVC
>> >> >> and
>> >> >> HEVC identifiers must also include the standard avcC and hvcC boxes
>> >> >> so
>> >> >> that they can be decoded normally without any additional custom
>> >> >> code.
>> >> >> 5. We have samples for at least one of the four identifiers that
>> >> >> matches points 1 to 4.
>> >> >> 6. Android, Chromium, VLC among others have already implemented
>> >> >> these
>> >> >> identifiers in the same way.
>> >> >>
>> >> >> Now, if you are not happy with these points, then please clearly
>> >> >> state
>> >> >> that you are blocking any and all additional identifier additions -
>> >> >> no
>> >> >> matter how specified - as long as there are no samples on hand for
>> >> >> them.
>> >> >
>> >> > After taking a second look at this sentence, I find this wording
>> >> > being
>> >> > loaded and antagonizing. It was unprofessional, and I apologize for
>> >> > it.
>> >> >
>> >> > But the wish underneath was to get a clear view into what it was it
>> >> > that you wanted. That was what was mostly clouded for me in your
>> >> > replies, and that annoyed me to no end.
>> >> >
>> >> > While I must say that I would have been happy if you had told me you
>> >> > were not blocking the patch (set), I did not want a specific outcome
>> >> > out of this sentence. I just wanted you to voice your level of
>> >> > discomfort with the patch (set) and to voice your current wishes
>> >> > regarding it. I had set my wishes on the table with the six points,
>> >> > and why I believed the patch (set) was fine as it was.
>> >> >
>> >> > That is why after I wrote this post I asked Michael what it was that
>> >> > was the procedure for cases where developers have seemingly
>> >> > irreconcilable differences in opinions regarding a patch set. I did
>> >> > not know if that was the case, but the main point was that in the
>> >> > unfortunate case that the patch was blocked, and we did not agree on
>> >> > some points heavily enough that we could not co-operate, that the
>> >> > next
>> >> > step could be taken right away so as to not have the patch (set) sit
>> >> > there untouched for another week or two.
>> >> >
>> >> > Unfortunately, you did not respond to or touch this sentence at all,
>> >> > which I then interpreted as your comments not being blockers.
>> >>
>> >> > I hope this makes my intentions and annoyances clear.
>> >>
>> >> Afaict, it contradicts what you wrote on irc yesterday.
>> >>
>> >> > I hope that in
>> >> > the future we can continue to co-operate, and that this makes it
>> >> > clear
>> >> > that I do not have any personal grievances nor a vendetta against
>> >> > you.
>> >>
>> >> Carl Eugen
>> >
>> > Feel free to quote the parts that you think contradict.
>>
>> I was under the assumption you had read this:
>> [21:26:03 CET]  carl just

Re: [FFmpeg-devel] [PATCH 1/2 v3] lavf/isom: add Dolby Vision sample entry codes for HEVC and H.264

On Tue, Dec 18, 2018 at 7:30 PM Carl Eugen Hoyos  wrote:
>
> 2018-12-18 18:24 GMT+01:00, Jan Ekström :
> > On Tue, Dec 18, 2018 at 7:21 PM Carl Eugen Hoyos  wrote:
> >>
> >> 2018-12-18 18:17 GMT+01:00, Jan Ekström :
> >> > On Mon, Dec 17, 2018 at 10:17 PM Jan Ekström  wrote:
> >> >>
> >> >> On Mon, Dec 17, 2018 at 3:47 PM Carl Eugen Hoyos 
> >> >> wrote:
> >> >> >
> >> >> > 2018-12-17 7:58 GMT+01:00, Jan Ekström :
> >> >> > > On Mon, Dec 17, 2018, 03:02 Carl Eugen Hoyos  >> >> > > wrote:
> >> >> > >
> >> >> > >> 2018-12-17 1:58 GMT+01:00, Jan Ekström :
> >> >> >
> >> >> > >> > So as far as it's been possible to test this, that's been done
> >> >> > >>
> >> >> > >> Could you point me to a dva1 sample?
> >> >> > >
> >> >> > > I have not seen any dolby vision samples with avc in the wild.
> >> >> > > You can ask Vittorio if he has some as he noted about
> >> >> > > possibly being able to ask for some before.
> >> >> >
> >> >> > The patch is of course ok if Vittorio tested it with his samples.
> >> >> >
> >> >> > Thank you, Carl Eugen
> >> >>
> >> >> Unfortunately I have no idea what samples Vittorio does or does not
> >> >> possess, he has only mentioned off-hand that he might able to get hold
> >> >> of some if required. And since you were the one requiring them, I
> >> >> pointed you towards him.
> >> >>
> >> >> For myself, I am happy with the following points regarding this:
> >> >> 1. The identifiers are registered at the MPEG-4 RA.
> >> >> 2. There is a proper specification for these mappings that is
> >> >> seemingly kept up-to-date.
> >> >> 3. The mappings specification specifically notes that the only
> >> >> difference between the AVC and HEVC identifiers are the semantics
> >> >> mentioned in ISO/IEC 14496-15. We already have all of the identifiers
> >> >> specified which these mappings are based upon, so those semantics
> >> >> should not matter to us (and if they do, we have already broken those
> >> >> constraints at this point).
> >> >> 4. The mapping specification specifically notes that the given AVC and
> >> >> HEVC identifiers must also include the standard avcC and hvcC boxes so
> >> >> that they can be decoded normally without any additional custom code.
> >> >> 5. We have samples for at least one of the four identifiers that
> >> >> matches points 1 to 4.
> >> >> 6. Android, Chromium, VLC among others have already implemented these
> >> >> identifiers in the same way.
> >> >>
> >> >> Now, if you are not happy with these points, then please clearly state
> >> >> that you are blocking any and all additional identifier additions - no
> >> >> matter how specified - as long as there are no samples on hand for
> >> >> them.
> >> >
> >> > After taking a second look at this sentence, I find this wording being
> >> > loaded and antagonizing. It was unprofessional, and I apologize for
> >> > it.
> >> >
> >> > But the wish underneath was to get a clear view into what it was it
> >> > that you wanted. That was what was mostly clouded for me in your
> >> > replies, and that annoyed me to no end.
> >> >
> >> > While I must say that I would have been happy if you had told me you
> >> > were not blocking the patch (set), I did not want a specific outcome
> >> > out of this sentence. I just wanted you to voice your level of
> >> > discomfort with the patch (set) and to voice your current wishes
> >> > regarding it. I had set my wishes on the table with the six points,
> >> > and why I believed the patch (set) was fine as it was.
> >> >
> >> > That is why after I wrote this post I asked Michael what it was that
> >> > was the procedure for cases where developers have seemingly
> >> > irreconcilable differences in opinions regarding a patch set. I did
> >> > not know if that was the case, but the main point was that in the
> >> > unfortunate case that the patch was blocked, and we did not agree on
> >> > some points heavily enough that we could not co-operate, that the next
> >> > step could be taken right away so as to not have the patch (set) sit
> >> > there untouched for another week or two.
> >> >
> >> > Unfortunately, you did not respond to or touch this sentence at all,
> >> > which I then interpreted as your comments not being blockers.
> >>
> >> > I hope this makes my intentions and annoyances clear.
> >>
> >> Afaict, it contradicts what you wrote on irc yesterday.
> >>
> >> > I hope that in
> >> > the future we can continue to co-operate, and that this makes it clear
> >> > that I do not have any personal grievances nor a vendetta against you.
> >>
> >> Carl Eugen
> >
> > Feel free to quote the parts that you think contradict.
>
> I was under the assumption you had read this:
> [21:26:03 CET]  carl just officially approved your
> patch with single condition to mention ticket #7347
>
> But re-reading it, there was no indication you actually understood
> what Paul wrote (or even read it), so sorry if I was wrong.
>

Yes, that specific line I had no interest in. I was tired, and the
ticket was not

Re: [FFmpeg-devel] [PATCH 1/2 v3] lavf/isom: add Dolby Vision sample entry codes for HEVC and H.264

2018-12-18 18:24 GMT+01:00, Jan Ekström :
> On Tue, Dec 18, 2018 at 7:21 PM Carl Eugen Hoyos  wrote:
>>
>> 2018-12-18 18:17 GMT+01:00, Jan Ekström :
>> > On Mon, Dec 17, 2018 at 10:17 PM Jan Ekström  wrote:
>> >>
>> >> On Mon, Dec 17, 2018 at 3:47 PM Carl Eugen Hoyos 
>> >> wrote:
>> >> >
>> >> > 2018-12-17 7:58 GMT+01:00, Jan Ekström :
>> >> > > On Mon, Dec 17, 2018, 03:02 Carl Eugen Hoyos > >> > > wrote:
>> >> > >
>> >> > >> 2018-12-17 1:58 GMT+01:00, Jan Ekström :
>> >> >
>> >> > >> > So as far as it's been possible to test this, that's been done
>> >> > >>
>> >> > >> Could you point me to a dva1 sample?
>> >> > >
>> >> > > I have not seen any dolby vision samples with avc in the wild.
>> >> > > You can ask Vittorio if he has some as he noted about
>> >> > > possibly being able to ask for some before.
>> >> >
>> >> > The patch is of course ok if Vittorio tested it with his samples.
>> >> >
>> >> > Thank you, Carl Eugen
>> >>
>> >> Unfortunately I have no idea what samples Vittorio does or does not
>> >> possess, he has only mentioned off-hand that he might able to get hold
>> >> of some if required. And since you were the one requiring them, I
>> >> pointed you towards him.
>> >>
>> >> For myself, I am happy with the following points regarding this:
>> >> 1. The identifiers are registered at the MPEG-4 RA.
>> >> 2. There is a proper specification for these mappings that is
>> >> seemingly kept up-to-date.
>> >> 3. The mappings specification specifically notes that the only
>> >> difference between the AVC and HEVC identifiers are the semantics
>> >> mentioned in ISO/IEC 14496-15. We already have all of the identifiers
>> >> specified which these mappings are based upon, so those semantics
>> >> should not matter to us (and if they do, we have already broken those
>> >> constraints at this point).
>> >> 4. The mapping specification specifically notes that the given AVC and
>> >> HEVC identifiers must also include the standard avcC and hvcC boxes so
>> >> that they can be decoded normally without any additional custom code.
>> >> 5. We have samples for at least one of the four identifiers that
>> >> matches points 1 to 4.
>> >> 6. Android, Chromium, VLC among others have already implemented these
>> >> identifiers in the same way.
>> >>
>> >> Now, if you are not happy with these points, then please clearly state
>> >> that you are blocking any and all additional identifier additions - no
>> >> matter how specified - as long as there are no samples on hand for
>> >> them.
>> >
>> > After taking a second look at this sentence, I find this wording being
>> > loaded and antagonizing. It was unprofessional, and I apologize for
>> > it.
>> >
>> > But the wish underneath was to get a clear view into what it was it
>> > that you wanted. That was what was mostly clouded for me in your
>> > replies, and that annoyed me to no end.
>> >
>> > While I must say that I would have been happy if you had told me you
>> > were not blocking the patch (set), I did not want a specific outcome
>> > out of this sentence. I just wanted you to voice your level of
>> > discomfort with the patch (set) and to voice your current wishes
>> > regarding it. I had set my wishes on the table with the six points,
>> > and why I believed the patch (set) was fine as it was.
>> >
>> > That is why after I wrote this post I asked Michael what it was that
>> > was the procedure for cases where developers have seemingly
>> > irreconcilable differences in opinions regarding a patch set. I did
>> > not know if that was the case, but the main point was that in the
>> > unfortunate case that the patch was blocked, and we did not agree on
>> > some points heavily enough that we could not co-operate, that the next
>> > step could be taken right away so as to not have the patch (set) sit
>> > there untouched for another week or two.
>> >
>> > Unfortunately, you did not respond to or touch this sentence at all,
>> > which I then interpreted as your comments not being blockers.
>>
>> > I hope this makes my intentions and annoyances clear.
>>
>> Afaict, it contradicts what you wrote on irc yesterday.
>>
>> > I hope that in
>> > the future we can continue to co-operate, and that this makes it clear
>> > that I do not have any personal grievances nor a vendetta against you.
>>
>> Carl Eugen
>
> Feel free to quote the parts that you think contradict.

I was under the assumption you had read this:
[21:26:03 CET]  carl just officially approved your
patch with single condition to mention ticket #7347

But re-reading it, there was no indication you actually understood
what Paul wrote (or even read it), so sorry if I was wrong.

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

Re: [FFmpeg-devel] [PATCH 1/2 v3] lavf/isom: add Dolby Vision sample entry codes for HEVC and H.264

On Tue, Dec 18, 2018 at 7:21 PM Carl Eugen Hoyos  wrote:
>
> 2018-12-18 18:17 GMT+01:00, Jan Ekström :
> > On Mon, Dec 17, 2018 at 10:17 PM Jan Ekström  wrote:
> >>
> >> On Mon, Dec 17, 2018 at 3:47 PM Carl Eugen Hoyos 
> >> wrote:
> >> >
> >> > 2018-12-17 7:58 GMT+01:00, Jan Ekström :
> >> > > On Mon, Dec 17, 2018, 03:02 Carl Eugen Hoyos  >> > > wrote:
> >> > >
> >> > >> 2018-12-17 1:58 GMT+01:00, Jan Ekström :
> >> >
> >> > >> > So as far as it's been possible to test this, that's been done
> >> > >>
> >> > >> Could you point me to a dva1 sample?
> >> > >
> >> > > I have not seen any dolby vision samples with avc in the wild.
> >> > > You can ask Vittorio if he has some as he noted about
> >> > > possibly being able to ask for some before.
> >> >
> >> > The patch is of course ok if Vittorio tested it with his samples.
> >> >
> >> > Thank you, Carl Eugen
> >>
> >> Unfortunately I have no idea what samples Vittorio does or does not
> >> possess, he has only mentioned off-hand that he might able to get hold
> >> of some if required. And since you were the one requiring them, I
> >> pointed you towards him.
> >>
> >> For myself, I am happy with the following points regarding this:
> >> 1. The identifiers are registered at the MPEG-4 RA.
> >> 2. There is a proper specification for these mappings that is
> >> seemingly kept up-to-date.
> >> 3. The mappings specification specifically notes that the only
> >> difference between the AVC and HEVC identifiers are the semantics
> >> mentioned in ISO/IEC 14496-15. We already have all of the identifiers
> >> specified which these mappings are based upon, so those semantics
> >> should not matter to us (and if they do, we have already broken those
> >> constraints at this point).
> >> 4. The mapping specification specifically notes that the given AVC and
> >> HEVC identifiers must also include the standard avcC and hvcC boxes so
> >> that they can be decoded normally without any additional custom code.
> >> 5. We have samples for at least one of the four identifiers that
> >> matches points 1 to 4.
> >> 6. Android, Chromium, VLC among others have already implemented these
> >> identifiers in the same way.
> >>
> >> Now, if you are not happy with these points, then please clearly state
> >> that you are blocking any and all additional identifier additions - no
> >> matter how specified - as long as there are no samples on hand for
> >> them.
> >
> > After taking a second look at this sentence, I find this wording being
> > loaded and antagonizing. It was unprofessional, and I apologize for
> > it.
> >
> > But the wish underneath was to get a clear view into what it was it
> > that you wanted. That was what was mostly clouded for me in your
> > replies, and that annoyed me to no end.
> >
> > While I must say that I would have been happy if you had told me you
> > were not blocking the patch (set), I did not want a specific outcome
> > out of this sentence. I just wanted you to voice your level of
> > discomfort with the patch (set) and to voice your current wishes
> > regarding it. I had set my wishes on the table with the six points,
> > and why I believed the patch (set) was fine as it was.
> >
> > That is why after I wrote this post I asked Michael what it was that
> > was the procedure for cases where developers have seemingly
> > irreconcilable differences in opinions regarding a patch set. I did
> > not know if that was the case, but the main point was that in the
> > unfortunate case that the patch was blocked, and we did not agree on
> > some points heavily enough that we could not co-operate, that the next
> > step could be taken right away so as to not have the patch (set) sit
> > there untouched for another week or two.
> >
> > Unfortunately, you did not respond to or touch this sentence at all,
> > which I then interpreted as your comments not being blockers.
>
> > I hope this makes my intentions and annoyances clear.
>
> Afaict, it contradicts what you wrote on irc yesterday.
>
> > I hope that in
> > the future we can continue to co-operate, and that this makes it clear
> > that I do not have any personal grievances nor a vendetta against you.
>
> Carl Eugen

Feel free to quote the parts that you think contradict.

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

Re: [FFmpeg-devel] [PATCH 1/2 v3] lavf/isom: add Dolby Vision sample entry codes for HEVC and H.264

2018-12-18 18:17 GMT+01:00, Jan Ekström :
> On Mon, Dec 17, 2018 at 10:17 PM Jan Ekström  wrote:
>>
>> On Mon, Dec 17, 2018 at 3:47 PM Carl Eugen Hoyos 
>> wrote:
>> >
>> > 2018-12-17 7:58 GMT+01:00, Jan Ekström :
>> > > On Mon, Dec 17, 2018, 03:02 Carl Eugen Hoyos > > > wrote:
>> > >
>> > >> 2018-12-17 1:58 GMT+01:00, Jan Ekström :
>> >
>> > >> > So as far as it's been possible to test this, that's been done
>> > >>
>> > >> Could you point me to a dva1 sample?
>> > >
>> > > I have not seen any dolby vision samples with avc in the wild.
>> > > You can ask Vittorio if he has some as he noted about
>> > > possibly being able to ask for some before.
>> >
>> > The patch is of course ok if Vittorio tested it with his samples.
>> >
>> > Thank you, Carl Eugen
>>
>> Unfortunately I have no idea what samples Vittorio does or does not
>> possess, he has only mentioned off-hand that he might able to get hold
>> of some if required. And since you were the one requiring them, I
>> pointed you towards him.
>>
>> For myself, I am happy with the following points regarding this:
>> 1. The identifiers are registered at the MPEG-4 RA.
>> 2. There is a proper specification for these mappings that is
>> seemingly kept up-to-date.
>> 3. The mappings specification specifically notes that the only
>> difference between the AVC and HEVC identifiers are the semantics
>> mentioned in ISO/IEC 14496-15. We already have all of the identifiers
>> specified which these mappings are based upon, so those semantics
>> should not matter to us (and if they do, we have already broken those
>> constraints at this point).
>> 4. The mapping specification specifically notes that the given AVC and
>> HEVC identifiers must also include the standard avcC and hvcC boxes so
>> that they can be decoded normally without any additional custom code.
>> 5. We have samples for at least one of the four identifiers that
>> matches points 1 to 4.
>> 6. Android, Chromium, VLC among others have already implemented these
>> identifiers in the same way.
>>
>> Now, if you are not happy with these points, then please clearly state
>> that you are blocking any and all additional identifier additions - no
>> matter how specified - as long as there are no samples on hand for
>> them.
>
> After taking a second look at this sentence, I find this wording being
> loaded and antagonizing. It was unprofessional, and I apologize for
> it.
>
> But the wish underneath was to get a clear view into what it was it
> that you wanted. That was what was mostly clouded for me in your
> replies, and that annoyed me to no end.
>
> While I must say that I would have been happy if you had told me you
> were not blocking the patch (set), I did not want a specific outcome
> out of this sentence. I just wanted you to voice your level of
> discomfort with the patch (set) and to voice your current wishes
> regarding it. I had set my wishes on the table with the six points,
> and why I believed the patch (set) was fine as it was.
>
> That is why after I wrote this post I asked Michael what it was that
> was the procedure for cases where developers have seemingly
> irreconcilable differences in opinions regarding a patch set. I did
> not know if that was the case, but the main point was that in the
> unfortunate case that the patch was blocked, and we did not agree on
> some points heavily enough that we could not co-operate, that the next
> step could be taken right away so as to not have the patch (set) sit
> there untouched for another week or two.
>
> Unfortunately, you did not respond to or touch this sentence at all,
> which I then interpreted as your comments not being blockers.

> I hope this makes my intentions and annoyances clear.

Afaict, it contradicts what you wrote on irc yesterday.

> I hope that in
> the future we can continue to co-operate, and that this makes it clear
> that I do not have any personal grievances nor a vendetta against you.

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

Re: [FFmpeg-devel] [PATCH 1/2 v3] lavf/isom: add Dolby Vision sample entry codes for HEVC and H.264

On Mon, Dec 17, 2018 at 10:17 PM Jan Ekström  wrote:
>
> On Mon, Dec 17, 2018 at 3:47 PM Carl Eugen Hoyos  wrote:
> >
> > 2018-12-17 7:58 GMT+01:00, Jan Ekström :
> > > On Mon, Dec 17, 2018, 03:02 Carl Eugen Hoyos  > >
> > >> 2018-12-17 1:58 GMT+01:00, Jan Ekström :
> >
> > >> > So as far as it's been possible to test this, that's been done
> > >>
> > >> Could you point me to a dva1 sample?
> > >
> > > I have not seen any dolby vision samples with avc in the wild.
> > > You can ask Vittorio if he has some as he noted about
> > > possibly being able to ask for some before.
> >
> > The patch is of course ok if Vittorio tested it with his samples.
> >
> > Thank you, Carl Eugen
>
> Unfortunately I have no idea what samples Vittorio does or does not
> possess, he has only mentioned off-hand that he might able to get hold
> of some if required. And since you were the one requiring them, I
> pointed you towards him.
>
> For myself, I am happy with the following points regarding this:
> 1. The identifiers are registered at the MPEG-4 RA.
> 2. There is a proper specification for these mappings that is
> seemingly kept up-to-date.
> 3. The mappings specification specifically notes that the only
> difference between the AVC and HEVC identifiers are the semantics
> mentioned in ISO/IEC 14496-15. We already have all of the identifiers
> specified which these mappings are based upon, so those semantics
> should not matter to us (and if they do, we have already broken those
> constraints at this point).
> 4. The mapping specification specifically notes that the given AVC and
> HEVC identifiers must also include the standard avcC and hvcC boxes so
> that they can be decoded normally without any additional custom code.
> 5. We have samples for at least one of the four identifiers that
> matches points 1 to 4.
> 6. Android, Chromium, VLC among others have already implemented these
> identifiers in the same way.
>
> Now, if you are not happy with these points, then please clearly state
> that you are blocking any and all additional identifier additions - no
> matter how specified - as long as there are no samples on hand for
> them.

After taking a second look at this sentence, I find this wording being
loaded and antagonizing. It was unprofessional, and I apologize for
it.

But the wish underneath was to get a clear view into what it was it
that you wanted. That was what was mostly clouded for me in your
replies, and that annoyed me to no end.

While I must say that I would have been happy if you had told me you
were not blocking the patch (set), I did not want a specific outcome
out of this sentence. I just wanted you to voice your level of
discomfort with the patch (set) and to voice your current wishes
regarding it. I had set my wishes on the table with the six points,
and why I believed the patch (set) was fine as it was.

That is why after I wrote this post I asked Michael what it was that
was the procedure for cases where developers have seemingly
irreconcilable differences in opinions regarding a patch set. I did
not know if that was the case, but the main point was that in the
unfortunate case that the patch was blocked, and we did not agree on
some points heavily enough that we could not co-operate, that the next
step could be taken right away so as to not have the patch (set) sit
there untouched for another week or two.

Unfortunately, you did not respond to or touch this sentence at all,
which I then interpreted as your comments not being blockers.

I hope this makes my intentions and annoyances clear. I hope that in
the future we can continue to co-operate, and that this makes it clear
that I do not have any personal grievances nor a vendetta against you.

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

Re: [FFmpeg-devel] [PATCH]lavc/mjpegdec: Interpret three-component Adobe transform 0 also as RGB

2018-12-18 14:12 GMT+01:00, Michael Niedermayer :
> On Mon, Dec 17, 2018 at 11:55:54PM +0100, Carl Eugen Hoyos wrote:
>> Hi!
>>
>> Attached patch fixes ticket #7625 for me.
>>
>> Please comment, Carl Eugen
>
>>  mjpegdec.c |3 ++-
>>  1 file changed, 2 insertions(+), 1 deletion(-)
>> 3dbfffc6a3de8e5a08d60181a6047d9301a13016
>> 0001-lavc-mjpegdec-Interpret-three-component-Adobe-transf.patch
>> From be83e6c657b8d8e2a158747b58c4dbc6ba3cc516 Mon Sep 17 00:00:00 2001
>> From: Carl Eugen Hoyos 
>> Date: Mon, 17 Dec 2018 23:53:29 +0100
>> Subject: [PATCH] lavc/mjpegdec: Interpret three-component Adobe transform
>> 0
>>  also as RGB.
>>
>> Fixes ticket #7625.
>
> LGTM

Patch applied.

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

Re: [FFmpeg-devel] [PATCH 1/3] doc/encoders: Fix colums typo

On 12/18/18, Michael Niedermayer  wrote:
> Signed-off-by: Michael Niedermayer 
> ---
>  doc/encoders.texi | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>

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

[FFmpeg-devel] [PATCH 2/3] avcodec/mjpegdec: verify SOF len field validity

Signed-off-by: Michael Niedermayer 
---
 libavcodec/mjpegdec.c | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/libavcodec/mjpegdec.c b/libavcodec/mjpegdec.c
index 2f1635838a..df01f17e0d 100644
--- a/libavcodec/mjpegdec.c
+++ b/libavcodec/mjpegdec.c
@@ -313,7 +313,6 @@ int ff_mjpeg_decode_sof(MJpegDecodeContext *s)
 memset(s->upscale_h, 0, sizeof(s->upscale_h));
 memset(s->upscale_v, 0, sizeof(s->upscale_v));
 
-/* XXX: verify len field validity */
 len = get_bits(>gb, 16);
 bits= get_bits(>gb, 8);
 
@@ -367,6 +366,11 @@ int ff_mjpeg_decode_sof(MJpegDecodeContext *s)
   "bits/component or 16-bit gray");
 return AVERROR_PATCHWELCOME;
 }
+if (len != 8 + 3 * nb_components) {
+av_log(s->avctx, AV_LOG_ERROR, "decode_sof0: error, len(%d) mismatch 
%d components\n", len, nb_components);
+return AVERROR_INVALIDDATA;
+}
+
 s->nb_components = nb_components;
 s->h_max = 1;
 s->v_max = 1;
@@ -711,8 +715,6 @@ unk_pixfmt:
 s->width, s->height, s->linesize[0], s->linesize[1],
 s->interlaced, s->avctx->height);
 
-if (len != (8 + (3 * nb_components)))
-av_log(s->avctx, AV_LOG_DEBUG, "decode_sof0: error, len(%d) 
mismatch\n", len);
 }
 
 if ((s->rgb && !s->lossless && !s->ls) ||
-- 
2.19.2

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

[FFmpeg-devel] [PATCH 1/3] doc/encoders: Fix colums typo

Signed-off-by: Michael Niedermayer 
---
 doc/encoders.texi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/doc/encoders.texi b/doc/encoders.texi
index ca3892d682..3d5b9fc2d2 100644
--- a/doc/encoders.texi
+++ b/doc/encoders.texi
@@ -1467,7 +1467,7 @@ has refilled above the threshold.  Defaults to zero (no 
frames are
 dropped).
 
 @item tiles
-Set the number of tiles to encode the input video with, as colums x
+Set the number of tiles to encode the input video with, as columns x
 rows.  Larger numbers allow greater parallelism in both encoding and
 decoding, but may decrease coding efficiency.  Defaults to the minimum
 number of tiles required by the size of the input video (this is 1x1
-- 
2.19.2

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

[FFmpeg-devel] [PATCH 3/3] avcodec/mjpegdec: Fix indention of ljpeg_decode_yuv_scan()

Signed-off-by: Michael Niedermayer 
---
 libavcodec/mjpegdec.c | 32 
 1 file changed, 16 insertions(+), 16 deletions(-)

diff --git a/libavcodec/mjpegdec.c b/libavcodec/mjpegdec.c
index df01f17e0d..ec47ad07a0 100644
--- a/libavcodec/mjpegdec.c
+++ b/libavcodec/mjpegdec.c
@@ -1220,25 +1220,25 @@ static int ljpeg_decode_yuv_scan(MJpegDecodeContext *s, 
int predictor,
 || v * mb_y + y >= s->height) {
 // Nothing to do
 } else if (bits<=8) {
-ptr = s->picture_ptr->data[c] + (linesize * (v * mb_y 
+ y)) + (h * mb_x + x); //FIXME optimize this crap
-if(y==0 && toprow){
-if(x==0 && leftcol){
-pred= 1 << (bits - 1);
-}else{
-pred= ptr[-1];
-}
-}else{
-if(x==0 && leftcol){
-pred= ptr[-linesize];
+ptr = s->picture_ptr->data[c] + (linesize * (v * 
mb_y + y)) + (h * mb_x + x); //FIXME optimize this crap
+if(y==0 && toprow){
+if(x==0 && leftcol){
+pred= 1 << (bits - 1);
+}else{
+pred= ptr[-1];
+}
 }else{
-PREDICT(pred, ptr[-linesize-1], 
ptr[-linesize], ptr[-1], predictor);
+if(x==0 && leftcol){
+pred= ptr[-linesize];
+}else{
+PREDICT(pred, ptr[-linesize-1], 
ptr[-linesize], ptr[-1], predictor);
+}
 }
-}
 
-if (s->interlaced && s->bottom_field)
-ptr += linesize >> 1;
-pred &= mask;
-*ptr= pred + ((unsigned)dc << point_transform);
+if (s->interlaced && s->bottom_field)
+ptr += linesize >> 1;
+pred &= mask;
+*ptr= pred + ((unsigned)dc << point_transform);
 }else{
 ptr16 = (uint16_t*)(s->picture_ptr->data[c] + 
2*(linesize * (v * mb_y + y)) + 2*(h * mb_x + x)); //FIXME optimize this crap
 if(y==0 && toprow){
-- 
2.19.2

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

[FFmpeg-devel] [PATCH 1/2] avformat/nutenc: fix duration estimation by writing EOR packets

Signed-off-by: Paul B Mahol 
---
 libavformat/nut.h|   3 +
 libavformat/nutenc.c | 130 +--
 2 files changed, 129 insertions(+), 4 deletions(-)

diff --git a/libavformat/nut.h b/libavformat/nut.h
index a4409ee23d..4b15dca1ea 100644
--- a/libavformat/nut.h
+++ b/libavformat/nut.h
@@ -76,6 +76,9 @@ typedef struct StreamContext {
 int last_flags;
 int skip_until_key_frame;
 int64_t last_pts;
+int64_t eor_pts;
+int64_t eor_dts;
+int eor_flushed;
 int time_base_id;
 AVRational *time_base;
 int msb_pts_shift;
diff --git a/libavformat/nutenc.c b/libavformat/nutenc.c
index e9a3bb49db..9d1c540a9d 100644
--- a/libavformat/nutenc.c
+++ b/libavformat/nutenc.c
@@ -940,6 +940,80 @@ fail:
 return ret;
 }
 
+static void nut_update_max_pts(AVFormatContext *s, int stream_index, int64_t 
pts)
+{
+NUTContext *nut = s->priv_data;
+StreamContext *nus = >stream[stream_index];
+
+if (!nut->max_pts_tb || av_compare_ts(nut->max_pts, *nut->max_pts_tb, pts, 
*nus->time_base) < 0) {
+nut->max_pts = pts;
+nut->max_pts_tb = nus->time_base;
+}
+}
+
+static int nut_write_eor(AVFormatContext *s, AVPacket *pkt)
+{
+AVIOContext *bc = s->pb, *dyn_bc;
+NUTContext *nut = s->priv_data;
+StreamContext *nus = >stream[pkt->stream_index];
+int ret, frame_code, flags, needed_flags;
+int64_t pts = pkt->pts;
+int64_t coded_pts;
+FrameCode *fc;
+
+coded_pts = pts & ((1 << nus->msb_pts_shift) - 1);
+if (ff_lsb2full(nus, coded_pts) != pts)
+coded_pts = pts + (1 << nus->msb_pts_shift);
+
+nut->last_syncpoint_pos = avio_tell(bc);
+ret = avio_open_dyn_buf(_bc);
+if (ret < 0)
+return ret;
+put_tt(nut, nus->time_base, dyn_bc, pkt->dts);
+ff_put_v(dyn_bc, 0);
+
+if (nut->flags & NUT_BROADCAST) {
+put_tt(nut, nus->time_base, dyn_bc,
+   av_rescale_q(av_gettime(), AV_TIME_BASE_Q, *nus->time_base));
+}
+put_packet(nut, bc, dyn_bc, 1, SYNCPOINT_STARTCODE);
+
+frame_code  = -1;
+for (int i = 0; i < 256; i++) {
+FrameCode *fc = >frame_code[i];
+int flags = fc->flags;
+
+if (flags & FLAG_INVALID)
+continue;
+
+if (!(flags & FLAG_CODED)) {
+continue;
+}
+
+frame_code = i;
+break;
+}
+av_assert0(frame_code != -1);
+
+fc   = >frame_code[frame_code];
+flags= fc->flags;
+needed_flags = FLAG_KEY | FLAG_EOR | FLAG_CODED_PTS | FLAG_STREAM_ID;
+
+ffio_init_checksum(bc, ff_crc04C11DB7_update, 0);
+avio_w8(bc, frame_code);
+if (flags & FLAG_CODED) {
+ff_put_v(bc, (flags ^ needed_flags) & ~(FLAG_CODED));
+flags = needed_flags;
+}
+if (flags & FLAG_STREAM_ID)  ff_put_v(bc, pkt->stream_index);
+if (flags & FLAG_CODED_PTS)  ff_put_v(bc, coded_pts);
+ffio_get_checksum(bc);
+
+nut_update_max_pts(s, pkt->stream_index, pkt->pts);
+
+return 0;
+}
+
 static int nut_write_packet(AVFormatContext *s, AVPacket *pkt)
 {
 NUTContext *nut= s->priv_data;
@@ -956,6 +1030,9 @@ static int nut_write_packet(AVFormatContext *s, AVPacket 
*pkt)
 int data_size = pkt->size;
 uint8_t *sm_buf = NULL;
 
+if (!data_size)
+return nut_write_eor(s, pkt);
+
 if (pkt->pts < 0) {
 av_log(s, AV_LOG_ERROR,
"Negative pts not supported stream %d, pts %"PRId64"\n",
@@ -1150,10 +1227,7 @@ static int nut_write_packet(AVFormatContext *s, AVPacket 
*pkt)
 nus->keyframe_pts[nut->sp_count] = pkt->pts;
 }
 
-if (!nut->max_pts_tb || av_compare_ts(nut->max_pts, *nut->max_pts_tb, 
pkt->pts, *nus->time_base) < 0) {
-nut->max_pts = pkt->pts;
-nut->max_pts_tb = nus->time_base;
-}
+nut_update_max_pts(s, pkt->stream_index, pkt->pts);
 
 fail:
 av_freep(_buf);
@@ -1161,6 +1235,53 @@ fail:
 return ret;
 }
 
+static int nut_interleave_packet(AVFormatContext *s, AVPacket *out,
+ AVPacket *pkt, int flush)
+{
+NUTContext *nut = s->priv_data;
+int ret;
+
+if (pkt) {
+StreamContext *nus = >stream[pkt->stream_index];
+
+nus->eor_pts = FFMAX(pkt->pts + pkt->duration, nus->eor_pts);
+nus->eor_dts = FFMAX(pkt->dts + pkt->duration, nus->eor_dts);
+} else if (flush) {
+StreamContext *nus;
+int i;
+
+for (i = 0; i < s->nb_streams; i++) {
+nus = >stream[i];
+
+if (nus->eor_flushed)
+continue;
+
+if (s->streams[i]->last_in_packet_buffer)
+continue;
+
+break;
+}
+
+if (i < s->nb_streams) {
+pkt = av_packet_alloc();
+if (!pkt)
+return AVERROR(ENOMEM);
+
+ret = av_new_packet(pkt, 0);
+if (ret < 0)
+return ret;
+pkt->stream_index = i;
+pkt->pts =

[FFmpeg-devel] [PATCH 2/2] avformat/nutdec: skip EOR packets if they are subtitles

Signed-off-by: Paul B Mahol 
---
 libavformat/nutdec.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/libavformat/nutdec.c b/libavformat/nutdec.c
index 056ef59d00..1d1c449bbd 100644
--- a/libavformat/nutdec.c
+++ b/libavformat/nutdec.c
@@ -1080,6 +1080,10 @@ static int decode_frame(NUTContext *nut, AVPacket *pkt, 
int frame_code)
 
 stc = >stream[stream_id];
 
+if (stc->last_flags & FLAG_EOR &&
+s->streams[stream_id]->codecpar->codec_type != AVMEDIA_TYPE_SUBTITLE)
+return 1;
+
 if (stc->last_flags & FLAG_KEY)
 stc->skip_until_key_frame = 0;
 
-- 
2.17.1

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

Re: [FFmpeg-devel] [PATCH]lavc/mjpegdec: Interpret three-component Adobe transform 0 also as RGB

On Mon, Dec 17, 2018 at 11:55:54PM +0100, Carl Eugen Hoyos wrote:
> Hi!
> 
> Attached patch fixes ticket #7625 for me.
> 
> Please comment, Carl Eugen

>  mjpegdec.c |3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 3dbfffc6a3de8e5a08d60181a6047d9301a13016  
> 0001-lavc-mjpegdec-Interpret-three-component-Adobe-transf.patch
> From be83e6c657b8d8e2a158747b58c4dbc6ba3cc516 Mon Sep 17 00:00:00 2001
> From: Carl Eugen Hoyos 
> Date: Mon, 17 Dec 2018 23:53:29 +0100
> Subject: [PATCH] lavc/mjpegdec: Interpret three-component Adobe transform 0
>  also as RGB.
> 
> Fixes ticket #7625.

LGTM

thx

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Asymptotically faster algorithms should always be preferred if you have
asymptotical amounts of data


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

Re: [FFmpeg-devel] [PATCH] avformat: add vividas demuxer

2018-12-18 Thread Tomas Härdin

sön 2018-12-16 klockan 22:28 +0100 skrev Paul B Mahol:
> > 
> +static void track_header(VividasDemuxContext *viv, AVFormatContext *s,  
> uint8_t *buf, int size)
> +{
> +[...]
> +if (avio_tell(pb) < off) {
> +int num_data;
> +int xd_size = 0;
> +int data_len[256];
> +int offset = 1;
> +uint8_t *p;
> +ffio_read_varlen(pb); // val_13
> +avio_r8(pb); // '19'
> +ffio_read_varlen(pb); // len_3
> +num_data = avio_r8(pb);
> +for (j = 0; j < num_data; j++) {
> +data_len[j] = ffio_read_varlen(pb);
> +xd_size += data_len[j];
> +}
> +
> +st->codecpar->extradata_size = 64 + xd_size + xd_size / 255;
> +st->codecpar->extradata = 
> av_mallocz(st->codecpar->extradata_size);

This is missing padding by AV_INPUT_BUFFER_PADDING_SIZE

/Tomas

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

Re: [FFmpeg-devel] [PATCH] avcodec/mips: [loongson] fix failedcase: hevc-conformance-AMP_A_Samsung_* in loongson2k

2018-12-18 Thread guxiwei-hf

>>Subject: [FFmpeg-devel] [PATCH] avcodec/mips: [loongson] fix failed case:
>>hevc-conformance-AMP_A_Samsung_* in loongson2k
>>
>>The AV_INPUT_BUFFER_PADDING_SIZE has been increased to 64, but the value is 
>>still 32
>>in function ff_hevc_sao_edge_filter_8_msa. So, Modify the corresponding value 
>>to 64.
>>Fate tests passed.
>>---
>> libavcodec/mips/hevc_lpf_sao_msa.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>>diff --git a/libavcodec/mips/hevc_lpf_sao_msa.c 
>>b/libavcodec/mips/hevc_lpf_sao_msa.c
>>index 5b5537a..bb883d0 100644
>>--- a/libavcodec/mips/hevc_lpf_sao_msa.c
>>+++ b/libavcodec/mips/hevc_lpf_sao_msa.c
>>@@ -2630,7 +2630,7 @@ void ff_hevc_sao_edge_filter_8_msa(uint8_t *dst, 
>>uint8_t *src,
>> int16_t *sao_offset_val,
>> int eo, int width, int height)
>> {
>>- ptrdiff_t stride_src = (2 * 64 + 32) / sizeof(uint8_t);
>>+ ptrdiff_t stride_src = (2 * 64 + 64) / sizeof(uint8_t);
>>
>> switch (eo) {
>> case 0:
>>--
>>2.1.0
>
>For this bug is a mips general bug, It's better to remove the key word 
>loongson in the patch name. 

thanks, will update.

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

Re: [FFmpeg-devel] [PATCH] avformat/nut: fix duration estimation by writting EOR packets

On Mon, Dec 17, 2018 at 08:29:35PM +0100, Paul B Mahol wrote:
> On 12/17/18, Michael Niedermayer  wrote:
> > On Mon, Dec 17, 2018 at 07:32:49PM +0100, Paul B Mahol wrote:
> >> On 12/17/18, Michael Niedermayer  wrote:
> >> > On Mon, Dec 17, 2018 at 06:04:40PM +0100, Paul B Mahol wrote:
> >> >> Hi,
> >> >>
> >> >> patches attached.
> >> >
> >> >>  nut.h|2 +
> >> >>  nutdec.c |3 ++
> >> >>  nutenc.c |   87
> >> >> ---
> >> >>  3 files changed, 88 insertions(+), 4 deletions(-)
> >> >> 870df19d733f29294a2cb2e3ea5ed1a09745f3a4
> >> >> 0001-avformat-nut-fix-duration-estimation-by-writing-EOR-.patch
> >> >> From 80d6805fdf386182341fe72035ab88e06a602752 Mon Sep 17 00:00:00 2001
> >> >> From: Paul B Mahol 
> >> >> Date: Mon, 17 Dec 2018 16:43:57 +0100
> >> >> Subject: [PATCH 1/2] avformat/nut: fix duration estimation by writing
> >> >> EOR
> >> >>  packets
> >> >>
> >> >> Signed-off-by: Paul B Mahol 
> >> >> ---
> >> >>  libavformat/nut.h|  2 +
> >> >>  libavformat/nutdec.c |  3 ++
> >> >>  libavformat/nutenc.c | 87
> >> >> ++--
> >> >>  3 files changed, 88 insertions(+), 4 deletions(-)
> >> >>
> >> >> diff --git a/libavformat/nut.h b/libavformat/nut.h
> >> >> index a4409ee23d..d7ba86b5e5 100644
> >> >> --- a/libavformat/nut.h
> >> >> +++ b/libavformat/nut.h
> >> >> @@ -76,6 +76,8 @@ typedef struct StreamContext {
> >> >>  int last_flags;
> >> >>  int skip_until_key_frame;
> >> >>  int64_t last_pts;
> >> >> +int64_t last_dts;
> >> >> +int64_t last_duration;
> >> >>  int time_base_id;
> >> >>  AVRational *time_base;
> >> >>  int msb_pts_shift;
> >> >> diff --git a/libavformat/nutdec.c b/libavformat/nutdec.c
> >> >> index 056ef59d00..f2490f9842 100644
> >> >
> >> >> --- a/libavformat/nutdec.c
> >> >> +++ b/libavformat/nutdec.c
> >> >> @@ -1080,6 +1080,9 @@ static int decode_frame(NUTContext *nut,
> >> >> AVPacket
> >> >> *pkt, int frame_code)
> >> >>
> >> >>  stc = >stream[stream_id];
> >> >>
> >> >> +if (stc->last_flags & FLAG_EOR)
> >> >> +return 1;
> >> >
> >> > EOR can occur in the middle of subtitle streams. It would be used to
> >> > mark
> >> > areas with no vissible subtitles.
> >> > (The point behind this is that it allows seeking to consider a subtitle
> >> > stream
> >> >  if and only if there are actually any displayed subtitles at that
> >> > time)
> >> >
> >> > this code would break that
> >> >
> >> > also demxuer and muxer changes should be in seperate patches
> >> >
> >> >
> >> >> +
> >> >>  if (stc->last_flags & FLAG_KEY)
> >> >>  stc->skip_until_key_frame = 0;
> >> >>
> >> >> diff --git a/libavformat/nutenc.c b/libavformat/nutenc.c
> >> >> index e9a3bb49db..c12b4cc8cf 100644
> >> >> --- a/libavformat/nutenc.c
> >> >> +++ b/libavformat/nutenc.c
> >> >> @@ -940,6 +940,80 @@ fail:
> >> >>  return ret;
> >> >>  }
> >> >>
> >> >> +static void nut_update_max_pts(AVFormatContext *s, int stream_index,
> >> >> int64_t pts)
> >> >> +{
> >> >> +NUTContext *nut = s->priv_data;
> >> >> +StreamContext *nus = >stream[stream_index];
> >> >> +
> >> >> +if (!nut->max_pts_tb || av_compare_ts(nut->max_pts,
> >> >> *nut->max_pts_tb,
> >> >> pts, *nus->time_base) < 0) {
> >> >> +nut->max_pts = pts;
> >> >> +nut->max_pts_tb = nus->time_base;
> >> >> +}
> >> >> +}
> >> >> +
> >> >> +static int nut_write_eor(AVFormatContext *s, int stream_index)
> >> >> +{
> >> >> +AVIOContext *bc = s->pb, *dyn_bc;
> >> >> +NUTContext *nut = s->priv_data;
> >> >> +StreamContext *nus = >stream[stream_index];
> >> >> +int ret, frame_code, flags, needed_flags;
> >> >> +int64_t pts = nus->last_pts + nus->last_duration;
> >> >> +int64_t coded_pts;
> >> >> +FrameCode *fc;
> >> >> +
> >> >> +coded_pts = pts & ((1 << nus->msb_pts_shift) - 1);
> >> >> +if (ff_lsb2full(nus, coded_pts) != pts)
> >> >> +coded_pts = pts + (1 << nus->msb_pts_shift);
> >> >> +
> >> >> +nut->last_syncpoint_pos = avio_tell(bc);
> >> >> +ret = avio_open_dyn_buf(_bc);
> >> >> +if (ret < 0)
> >> >> +return ret;
> >> >> +put_tt(nut, nus->time_base, dyn_bc, nus->last_dts +
> >> >> nus->last_duration);
> >> >> +ff_put_v(dyn_bc, 0);
> >> >> +
> >> >> +if (nut->flags & NUT_BROADCAST) {
> >> >> +put_tt(nut, nus->time_base, dyn_bc,
> >> >> +   av_rescale_q(av_gettime(), AV_TIME_BASE_Q,
> >> >> *nus->time_base));
> >> >> +}
> >> >> +put_packet(nut, bc, dyn_bc, 1, SYNCPOINT_STARTCODE);
> >> >> +
> >> >> +frame_code  = -1;
> >> >> +for (int i = 0; i < 256; i++) {
> >> >> +FrameCode *fc = >frame_code[i];
> >> >> +int flags = fc->flags;
> >> >> +
> >> >> +if (flags & FLAG_INVALID)
> >> >> +continue;
> >> >> +
> >> >> +if (!(flags & FLAG_CODED)) {
> >> >> +continue;
> >> >> +}
> >> >>

Re: [FFmpeg-devel] [PATCH] avcodec: add AV1 frame split bitstream filter

2018-12-18 Thread Tomas Härdin

mån 2018-12-17 klockan 21:56 -0300 skrev James Almer:
> This will be needed by the eventual native AV1 decoder.
> 
> +static int av1_frame_split_filter(AVBSFContext *ctx, AVPacket *out)
> +{
> +AV1FSplitContext *s = ctx->priv_data;
> +CodedBitstreamFragment *td = >temporal_unit;
> +int i, ret;
> +int split = !!s->buffer_pkt->data;
> +
> +if (!s->buffer_pkt->data) {

I was going to comment that !split might be better, but on the other
hand this makes it clear that data == NULL

Don't know enough about BSFs or AV1 to comment much else on this

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

Re: [FFmpeg-devel] [PATCH] avcodec/mips: [loongson] fix failed case: hevc-conformance-AMP_A_Samsung_* in loongson2k

2018-12-18 Thread Shiyou Yin

>-Original Message-
>From: ffmpeg-devel-boun...@ffmpeg.org [mailto:ffmpeg-devel-boun...@ffmpeg.org] 
>On Behalf Of gxw
>Sent: Tuesday, December 18, 2018 9:15 AM
>To: ffmpeg-devel@ffmpeg.org
>Cc: gxw
>Subject: [FFmpeg-devel] [PATCH] avcodec/mips: [loongson] fix failed case:
>hevc-conformance-AMP_A_Samsung_* in loongson2k
>
>The AV_INPUT_BUFFER_PADDING_SIZE has been increased to 64, but the value is 
>still 32
>in function ff_hevc_sao_edge_filter_8_msa. So, Modify the corresponding value 
>to 64.
>Fate tests passed.
>---
> libavcodec/mips/hevc_lpf_sao_msa.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
>diff --git a/libavcodec/mips/hevc_lpf_sao_msa.c 
>b/libavcodec/mips/hevc_lpf_sao_msa.c
>index 5b5537a..bb883d0 100644
>--- a/libavcodec/mips/hevc_lpf_sao_msa.c
>+++ b/libavcodec/mips/hevc_lpf_sao_msa.c
>@@ -2630,7 +2630,7 @@ void ff_hevc_sao_edge_filter_8_msa(uint8_t *dst, uint8_t 
>*src,
>int16_t *sao_offset_val,
>int eo, int width, int height)
> {
>-ptrdiff_t stride_src = (2 * 64 + 32) / sizeof(uint8_t);
>+ptrdiff_t stride_src = (2 * 64 + 64) / sizeof(uint8_t);
>
> switch (eo) {
> case 0:
>--
>2.1.0

For this bug is a mips general bug, It's better to remove the key word loongson 
in the patch name. 


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

Re: [FFmpeg-devel] [PATCH] avcodec/mips: [loongson] enable MSA optimization for loongson platform.

On Mon, Dec 17, 2018 at 06:03:30PM +0800, Shiyou Yin wrote:
> Set initialization order of MSA after MMI to make it work on loongson 
> platform(msa is supported by loongson2k、3a4000 etc.).
> ---
>  libavcodec/mips/blockdsp_init_mips.c| 6 +++---
>  libavcodec/mips/h264chroma_init_mips.c  | 6 +++---
>  libavcodec/mips/h264dsp_init_mips.c | 6 +++---
>  libavcodec/mips/h264pred_init_mips.c| 6 +++---
>  libavcodec/mips/h264qpel_init_mips.c| 6 +++---
>  libavcodec/mips/hpeldsp_init_mips.c | 6 +++---
>  libavcodec/mips/idctdsp_init_mips.c | 6 +++---
>  libavcodec/mips/mpegvideo_init_mips.c   | 6 +++---
>  libavcodec/mips/pixblockdsp_init_mips.c | 6 +++---
>  libavcodec/mips/vp8dsp_init_mips.c  | 6 +++---
>  10 files changed, 30 insertions(+), 30 deletions(-)

will apply

thx

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

Awnsering whenever a program halts or runs forever is
On a turing machine, in general impossible (turings halting problem).
On any real computer, always possible as a real computer has a finite number
of states N, and will either halt in less than N cycles or never halt.


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

Re: [FFmpeg-devel] [PATCH] avformat/mpegts: unset DTS/PTS for subtitle PES packets if PCR not available