[FFmpeg-devel] Fixes for audio/L16

[Igor Derzhavin]

Hello!
A little bunch of fixes for audio/L16 mime type handling:
0001 - RFC 2045 says MIME type should be case insensitive;
0002 - RFC 2586 says audio/L16 should be in network byte order (aka big
endian);
0003 - though "endiannes" parameter not in RFC it is widely used;
From e40e9567995042d75f8070daaa2efde46409f877 Mon Sep 17 00:00:00 2001
From: Igor Derzhavin 
Date: Thu, 22 Nov 2018 10:38:20 +0300
Subject: [PATCH 1/3] avformat/pcmdec: mime-type should be case insensitive
 (audio/L16)

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

diff --git a/libavformat/pcmdec.c b/libavformat/pcmdec.c
index bd2a0384f8..0d146a46a0 100644
--- a/libavformat/pcmdec.c
+++ b/libavformat/pcmdec.c
@@ -52,7 +52,7 @@ static int pcm_read_header(AVFormatContext *s)
 if (mime_type && s->iformat->mime_type) {
 int rate = 0, channels = 0;
 size_t len = strlen(s->iformat->mime_type);
-if (!strncmp(s->iformat->mime_type, mime_type, len)) {
+if (!av_strncasecmp(s->iformat->mime_type, mime_type, len)) {
 uint8_t *options = mime_type + len;
 len = strlen(mime_type);
 while (options < mime_type + len) {
-- 
2.17.1

From 4aa886c8941086d5290c10439a4a822538ec61e8 Mon Sep 17 00:00:00 2001
From: Igor Derzhavin 
Date: Thu, 22 Nov 2018 10:54:42 +0300
Subject: [PATCH 3/3] avformat/pcmdec: endianness for audio/L16 mime type

---
 libavformat/pcmdec.c | 12 ++--
 1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/libavformat/pcmdec.c b/libavformat/pcmdec.c
index 8530dbc1e3..9895af03a4 100644
--- a/libavformat/pcmdec.c
+++ b/libavformat/pcmdec.c
@@ -50,9 +50,9 @@ static int pcm_read_header(AVFormatContext *s)
 
 av_opt_get(s->pb, "mime_type", AV_OPT_SEARCH_CHILDREN, &mime_type);
 if (mime_type && s->iformat->mime_type) {
-int rate = 0, channels = 0;
+int rate = 0, channels = 0, little_endian = 0;
 size_t len = strlen(s->iformat->mime_type);
-if (!av_strncasecmp(s->iformat->mime_type, mime_type, len)) {
+if (!av_strncasecmp(s->iformat->mime_type, mime_type, len)) { /* audio/L16 */
 uint8_t *options = mime_type + len;
 len = strlen(mime_type);
 while (options < mime_type + len) {
@@ -63,6 +63,12 @@ static int pcm_read_header(AVFormatContext *s)
 sscanf(options, " rate=%d", &rate);
 if (!channels)
 sscanf(options, " channels=%d", &channels);
+if (!little_endian) {
+ char val[14]; /* sizeof("little-endian") == 14 */
+ if (sscanf(options, " endianness=%13s", val) == 1) {
+ little_endian = strcmp(val, "little-endian") == 0;
+ }
+}
 }
 if (rate <= 0) {
 av_log(s, AV_LOG_ERROR,
@@ -74,6 +80,8 @@ static int pcm_read_header(AVFormatContext *s)
 st->codecpar->sample_rate = rate;
 if (channels > 0)
 st->codecpar->channels = channels;
+if (little_endian)
+st->codecpar->codec_id = AV_CODEC_ID_PCM_S16LE;
 }
 }
 av_freep(&mime_type);
-- 
2.17.1

From 817fd71b9c87d019996d711d47517994c55636b1 Mon Sep 17 00:00:00 2001
From: Igor Derzhavin 
Date: Thu, 22 Nov 2018 10:39:57 +0300
Subject: [PATCH 2/3] avformat/pcmdec: audio/L16 should be in network byte
 order by default (rfc 2586)

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

diff --git a/libavformat/pcmdec.c b/libavformat/pcmdec.c
index 0d146a46a0..8530dbc1e3 100644
--- a/libavformat/pcmdec.c
+++ b/libavformat/pcmdec.c
@@ -142,10 +142,10 @@ PCMDEF(s24le, "PCM signed 24-bit little-endian",
NULL, AV_CODEC_ID_PCM_S24LE)
 
 PCMDEF(s16be, "PCM signed 16-bit big-endian",
-   AV_NE("sw", NULL), AV_CODEC_ID_PCM_S16BE)
+   AV_NE("sw", NULL), AV_CODEC_ID_PCM_S16BE, .mime_type = "audio/L16")
 
 PCMDEF(s16le, "PCM signed 16-bit little-endian",
-   AV_NE(NULL, "sw"), AV_CODEC_ID_PCM_S16LE, .mime_type = "audio/L16",)
+   AV_NE(NULL, "sw"), AV_CODEC_ID_PCM_S16LE)
 
 PCMDEF(s8, "PCM signed 8-bit",
"sb", AV_CODEC_ID_PCM_S8)
-- 
2.17.1

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

Re: [FFmpeg-devel] [PATCH 2/3] flvdec: Mark the demuxer as allowing discontinuous timestamps

[Derek Buitenhuis]

On 22/11/2018 02:16, Michael Niedermayer wrote:
> the specification says this:
> "Timestamp UI24 Time in milliseconds at which the data in this tag
> applies. This is relative to the first tag in the FLV file,
> which always has a timestamp of 0.
> "
> So flv does not seem to allow discontinuities. Any tool writing files with
> discontinuities would be faulty

I know they're not valid, however in the real world, tons and tons of these 
files
exists, since this is how live FLV is done quite often.

> declaring files which have no discontinuities as having some would
> result in worse performing seeking in some cases. Both slower and or less
> accurate. Also flv IIRC allows gaps in tracks like no packets where there is
> silence. This may interfere with discontinuities as it looks
> like a discontinuity.

I agree, but then how do you propose we handle FLVs that do have discontinuites?
Currently the demuxer just outputs the discontinuiting (negative or positive),
and it breaks, since codebases expect that demuxers which do this will be 
properly
marked with the DISCONT flag.

> Can these files with discontinuities be detected somehow from the headers?
> If so then the probe function could be changed so they get the discontinuity
> flag while valid files do not have the disadvantages from having it set

As far as I am aware, no, they cannot be detected by header. FLV is crappy like 
that.

Every downstream codebase that cares could force the 'live_flv' demuxer for all 
FLVs,
but this seems ugly and needlessly special cased.

I am open to better solutions...

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

Re: [FFmpeg-devel] Fixes for audio/L16

[Carl Eugen Hoyos]

2018-11-22 10:16 GMT+01:00, Igor Derzhavin :

> A little bunch of fixes for audio/L16 mime type handling:
> 0001 - RFC 2045 says MIME type should be case insensitive;
> 0002 - RFC 2586 says audio/L16 should be in network byte order (aka big
> endian);
> 0003 - though "endiannes" parameter not in RFC it is widely used;

Great, did you test this with any other application?

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

Re: [FFmpeg-devel] [PATCH 2/3] flvdec: Mark the demuxer as allowing discontinuous timestamps

[Carl Eugen Hoyos]

2018-11-22 11:27 GMT+01:00, Derek Buitenhuis :

> Every downstream codebase that cares could force the 'live_flv'
> demuxer for all FLVs, but this seems ugly and needlessly special cased.

Only the downstreams that expect invalid files, no?

No opinion here about the patch, Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] lavf/dashenc: Fix segment duration overflow on fine time bases.

[Carl Eugen Hoyos]

2018-11-22 7:43 GMT+01:00, Jeyapal, Karthick :
>
> On 11/20/18 11:03 PM, Andrey Semashev wrote:
>> When stream time bases are very fine grained (e.g. nanoseconds), 32-bit
>> segment duration may overflow for even for rather small segment duration
>> (about 4 seconds long). Therefore we use 64-bit values for segment
>> duration.
>> ---
>>  libavformat/dashenc.c | 6 +++---
>>  1 file changed, 3 insertions(+), 3 deletions(-)
>>
>> diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c
>> index d151921175..8d0bc4baa2 100644
>> --- a/libavformat/dashenc.c
>> +++ b/libavformat/dashenc.c
>> @@ -59,7 +59,7 @@ typedef struct Segment {
>>  int64_t start_pos;
>>  int range_length, index_length;
>>  int64_t time;
>> -int duration;
>> +int64_t duration;
>>  int n;
>>  } Segment;
>>
>> @@ -428,7 +428,7 @@ static void output_segment_list(OutputStream *os,
>> AVIOContext *out, AVFormatCont
>>  cur_time = seg->time;
>>  avio_printf(out, "t=\"%"PRId64"\" ", seg->time);
>>  }
>> -avio_printf(out, "d=\"%d\" ", seg->duration);
>> +avio_printf(out, "d=\"%"PRId64"\" ", seg->duration);
>>  while (i + repeat + 1 < os->nb_segments &&
>> os->segments[i + repeat + 1]->duration ==
>> seg->duration &&
>> os->segments[i + repeat + 1]->time ==
>> os->segments[i + repeat]->time + os->segments[i + repeat]->duration)
>> @@ -1149,7 +1149,7 @@ static int dash_write_header(AVFormatContext *s)
>>  }
>>
>>  static int add_segment(OutputStream *os, const char *file,
>> -   int64_t time, int duration,
>> +   int64_t time, int64_t duration,
>> int64_t start_pos, int64_t range_length,
>> int64_t index_length, int next_exp_index)
>>  {
>
> LGTM.

Please commit the patch if it is ok.

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

Re: [FFmpeg-devel] Fixes for audio/L16

[Igor Derzhavin]

No, I don't now applications that can play pcm streams through HTTP. VLC
misdetect such streams as mp3, and there is a two years old bug
https://trac.videolan.org/vlc/ticket/17229.

On Thu, Nov 22, 2018 at 4:00 PM Carl Eugen Hoyos  wrote:

> 2018-11-22 10:16 GMT+01:00, Igor Derzhavin :
>
> > A little bunch of fixes for audio/L16 mime type handling:
> > 0001 - RFC 2045 says MIME type should be case insensitive;
> > 0002 - RFC 2586 says audio/L16 should be in network byte order (aka big
> > endian);
> > 0003 - though "endiannes" parameter not in RFC it is widely used;
>
> Great, did you test this with any other application?
>
> Thank you, Carl Eugen
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] lavf/dashenc: Fix segment duration overflow on fine time bases.

[Jeyapal, Karthick]

On 11/22/18 6:35 PM, Carl Eugen Hoyos wrote:
> 2018-11-22 7:43 GMT+01:00, Jeyapal, Karthick :
>>
>> On 11/20/18 11:03 PM, Andrey Semashev wrote:
>>> When stream time bases are very fine grained (e.g. nanoseconds), 32-bit
>>> segment duration may overflow for even for rather small segment duration
>>> (about 4 seconds long). Therefore we use 64-bit values for segment
>>> duration.
>>> ---
>>>  libavformat/dashenc.c | 6 +++---
>>>  1 file changed, 3 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c
>>> index d151921175..8d0bc4baa2 100644
>>> --- a/libavformat/dashenc.c
>>> +++ b/libavformat/dashenc.c
>>> @@ -59,7 +59,7 @@ typedef struct Segment {
>>>  int64_t start_pos;
>>>  int range_length, index_length;
>>>  int64_t time;
>>> -int duration;
>>> +int64_t duration;
>>>  int n;
>>>  } Segment;
>>>
>>> @@ -428,7 +428,7 @@ static void output_segment_list(OutputStream *os,
>>> AVIOContext *out, AVFormatCont
>>>  cur_time = seg->time;
>>>  avio_printf(out, "t=\"%"PRId64"\" ", seg->time);
>>>  }
>>> -avio_printf(out, "d=\"%d\" ", seg->duration);
>>> +avio_printf(out, "d=\"%"PRId64"\" ", seg->duration);
>>>  while (i + repeat + 1 < os->nb_segments &&
>>> os->segments[i + repeat + 1]->duration ==
>>> seg->duration &&
>>> os->segments[i + repeat + 1]->time ==
>>> os->segments[i + repeat]->time + os->segments[i + repeat]->duration)
>>> @@ -1149,7 +1149,7 @@ static int dash_write_header(AVFormatContext *s)
>>>  }
>>>
>>>  static int add_segment(OutputStream *os, const char *file,
>>> -   int64_t time, int duration,
>>> +   int64_t time, int64_t duration,
>>> int64_t start_pos, int64_t range_length,
>>> int64_t index_length, int next_exp_index)
>>>  {
>>
>> LGTM.
>
> Please commit the patch if it is ok.
Sure. I am just waiting for 3 days to complete as per the ffmpeg developer 
guidelines.
Will push it tomorrow. Let me know if it is urgent for some reason, in which 
case I will push it earlier.
>
> Carl Eugen
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

[FFmpeg-devel] [PATCH V3 0/7] Misc change V3

[Jun Zhao]

V3: - add rc_max_rate to AVStream and bump the version
- use AVStream.rc_max_rate for MOV/MP4 esds box.
- use AVStream.rc_max_rate for ffprobe to fix can't get max bit rate issue.

V2: - fix max_bit_rate dump change break the fate test. 
  (based on Micheal/Moritz's review) 

V1: - indet ffmpeg/buffersrc
- add auto threads flag for kvazaar
- delete the unused code from ffmpeg
- fix max_bit_rate dump warning for ffprobe

Jun Zhao (7):
  lavfi/buffersrc: Indent the code.
  fftools/ffprobe: Indent the code.
  fftools/ffmpeg: delete the unused code.
  lavc/kvazaar: fix auto thread flag in kvazaar wrapper.
  avformat: add rc_max_rate to AVStream
  lavf/isom: use AVStream.rc_max_rate to save max bit rate for esds box
  fftools/ffprobe: fix max_bit_rate dump.

 doc/APIchanges  |3 +++
 fftools/ffmpeg.c|9 +
 fftools/ffprobe.c   |   35 +--
 libavcodec/libkvazaar.c |2 +-
 libavfilter/buffersrc.c |   30 +++---
 libavformat/avformat.h  |6 ++
 libavformat/isom.c  |7 +--
 libavformat/version.h   |2 +-
 8 files changed, 45 insertions(+), 49 deletions(-)

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

[FFmpeg-devel] [PATCH V3 1/7] lavfi/buffersrc: Indent the code.

[Jun Zhao]

commit b0012de420f missed reindent.

Signed-off-by: Jun Zhao 
---
 libavfilter/buffersrc.c |   30 +++---
 1 files changed, 15 insertions(+), 15 deletions(-)

diff --git a/libavfilter/buffersrc.c b/libavfilter/buffersrc.c
index cd56f8c..0c12650 100644
--- a/libavfilter/buffersrc.c
+++ b/libavfilter/buffersrc.c
@@ -205,21 +205,21 @@ static int 
av_buffersrc_add_frame_internal(AVFilterContext *ctx,
 
 if (!(flags & AV_BUFFERSRC_FLAG_NO_CHECK_FORMAT)) {
 
-switch (ctx->outputs[0]->type) {
-case AVMEDIA_TYPE_VIDEO:
-CHECK_VIDEO_PARAM_CHANGE(ctx, s, frame->width, frame->height,
- frame->format);
-break;
-case AVMEDIA_TYPE_AUDIO:
-/* For layouts unknown on input but known on link after negotiation. */
-if (!frame->channel_layout)
-frame->channel_layout = s->channel_layout;
-CHECK_AUDIO_PARAM_CHANGE(ctx, s, frame->sample_rate, 
frame->channel_layout,
- frame->channels, frame->format);
-break;
-default:
-return AVERROR(EINVAL);
-}
+switch (ctx->outputs[0]->type) {
+case AVMEDIA_TYPE_VIDEO:
+CHECK_VIDEO_PARAM_CHANGE(ctx, s, frame->width, frame->height,
+ frame->format);
+break;
+case AVMEDIA_TYPE_AUDIO:
+/* For layouts unknown on input but known on link after 
negotiation. */
+if (!frame->channel_layout)
+frame->channel_layout = s->channel_layout;
+CHECK_AUDIO_PARAM_CHANGE(ctx, s, frame->sample_rate, 
frame->channel_layout,
+ frame->channels, frame->format);
+break;
+default:
+return AVERROR(EINVAL);
+}
 
 }
 
-- 
1.7.1

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

[FFmpeg-devel] [PATCH V3 3/7] fftools/ffmpeg: delete the unused code.

[Jun Zhao]

There are come from 2012 ago and have never been used from this
time.

Signed-off-by: Jun Zhao 
---
 fftools/ffmpeg.c |9 +
 1 files changed, 1 insertions(+), 8 deletions(-)

diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
index a12208c..085d6d2 100644
--- a/fftools/ffmpeg.c
+++ b/fftools/ffmpeg.c
@@ -1485,8 +1485,6 @@ static int reap_filters(int flush)
 av_rescale_q(filtered_frame->pts, filter_tb, 
enc->time_base) -
 av_rescale_q(start_time, AV_TIME_BASE_Q, enc->time_base);
 }
-//if (ost->source_index >= 0)
-//*filtered_frame= 
*input_streams[ost->source_index]->decoded_frame; //for me_threshold
 
 switch (av_buffersink_get_type(filter)) {
 case AVMEDIA_TYPE_VIDEO:
@@ -3340,7 +3338,7 @@ static int init_output_stream_encode(OutputStream *ost)
"if you want a different framerate.\n",
ost->file_index, ost->index);
 }
-//  ost->frame_rate = ist->st->avg_frame_rate.num ? 
ist->st->avg_frame_rate : (AVRational){25, 1};
+
 if (ost->enc->supported_framerates && !ost->force_fps) {
 int idx = av_find_nearest_q_idx(ost->frame_rate, 
ost->enc->supported_framerates);
 ost->frame_rate = ost->enc->supported_framerates[idx];
@@ -4879,11 +4877,6 @@ int main(int argc, char **argv)
 exit_program(1);
 }
 
-// if (nb_input_files == 0) {
-// av_log(NULL, AV_LOG_FATAL, "At least one input file must be 
specified\n");
-// exit_program(1);
-// }
-
 for (i = 0; i < nb_output_files; i++) {
 if (strcmp(output_files[i]->ctx->oformat->name, "rtp"))
 want_sdp = 0;
-- 
1.7.1

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

[FFmpeg-devel] [PATCH V3 7/7] fftools/ffprobe: fix max_bit_rate dump.

[Jun Zhao]

‘codec’ is deprecated in AVStream, so used the dec_ctx to dump
max_bit_rate in ffprobe. Clean the warning like:
"warning: ‘codec’ is deprecated [-Wdeprecated-declarations]"

Reviewed-by: Moritz Barsnick 
Signed-off-by: Jun Zhao 
---
 fftools/ffprobe.c |7 +++
 1 files changed, 3 insertions(+), 4 deletions(-)

diff --git a/fftools/ffprobe.c b/fftools/ffprobe.c
index dea489d..349ea9f 100644
--- a/fftools/ffprobe.c
+++ b/fftools/ffprobe.c
@@ -2622,10 +2622,8 @@ static int show_stream(WriterContext *w, AVFormatContext 
*fmt_ctx, int stream_id
 print_time("duration",stream->duration, &stream->time_base);
 if (par->bit_rate > 0) print_val("bit_rate", par->bit_rate, 
unit_bit_per_second_str);
 else   print_str_opt("bit_rate", "N/A");
-#if FF_API_LAVF_AVCTX
-if (stream->codec->rc_max_rate > 0) print_val ("max_bit_rate", 
stream->codec->rc_max_rate, unit_bit_per_second_str);
-elseprint_str_opt("max_bit_rate", "N/A");
-#endif
+if (dec_ctx && dec_ctx->rc_max_rate >0) print_val("max_bit_rate", 
dec_ctx->rc_max_rate, unit_bit_per_second_str);
+elseprint_str_opt("max_bit_rate", 
"N/A");
 if (dec_ctx && dec_ctx->bits_per_raw_sample > 0) 
print_fmt("bits_per_raw_sample", "%d", dec_ctx->bits_per_raw_sample);
 else 
print_str_opt("bits_per_raw_sample", "N/A");
 if (stream->nb_frames) print_fmt("nb_frames", "%"PRId64, 
stream->nb_frames);
@@ -2915,6 +2913,7 @@ static int open_input_file(InputFile *ifile, const char 
*filename)
 
 ist->dec_ctx->pkt_timebase = stream->time_base;
 ist->dec_ctx->framerate = stream->avg_frame_rate;
+ist->dec_ctx->rc_max_rate = stream->rc_max_rate;
 #if FF_API_LAVF_AVCTX
 ist->dec_ctx->coded_width = stream->codec->coded_width;
 ist->dec_ctx->coded_height = stream->codec->coded_height;
-- 
1.7.1

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

[FFmpeg-devel] [PATCH V3 6/7] lavf/isom: use AVStream.rc_max_rate to save max bit rate for esds box

[Jun Zhao]

Use AVStream.rc_max_rate to save max bit rate for esds box. Now we
don't need to use the AVStream.codec for max bit rate.

Signed-off-by: Jun Zhao 
---
 libavformat/isom.c |7 +--
 1 files changed, 1 insertions(+), 6 deletions(-)

diff --git a/libavformat/isom.c b/libavformat/isom.c
index ca9d22e..6de30c3 100644
--- a/libavformat/isom.c
+++ b/libavformat/isom.c
@@ -513,13 +513,8 @@ int ff_mp4_read_dec_config_descr(AVFormatContext *fc, 
AVStream *st, AVIOContext
 
 v = avio_rb32(pb);
 
-// TODO: fix this with codecpar
-#if FF_API_LAVF_AVCTX
-FF_DISABLE_DEPRECATION_WARNINGS
 if (v < INT32_MAX)
-st->codec->rc_max_rate = v;
-FF_ENABLE_DEPRECATION_WARNINGS
-#endif
+st->rc_max_rate = v; /* max bitrate */
 
 st->codecpar->bit_rate = avio_rb32(pb); /* avg bitrate */
 
-- 
1.7.1

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

[FFmpeg-devel] [PATCH V3 2/7] fftools/ffprobe: Indent the code.

[Jun Zhao]

commit 196765a7cc4 missed the reindet.

Signed-off-by: Jun Zhao 
---
 fftools/ffprobe.c |   28 ++--
 1 files changed, 14 insertions(+), 14 deletions(-)

diff --git a/fftools/ffprobe.c b/fftools/ffprobe.c
index 544786e..dea489d 100644
--- a/fftools/ffprobe.c
+++ b/fftools/ffprobe.c
@@ -2646,20 +2646,20 @@ static int show_stream(WriterContext *w, 
AVFormatContext *fmt_ctx, int stream_id
 } while (0)
 
 if (do_show_stream_disposition) {
-writer_print_section_header(w, in_program ? 
SECTION_ID_PROGRAM_STREAM_DISPOSITION : SECTION_ID_STREAM_DISPOSITION);
-PRINT_DISPOSITION(DEFAULT,  "default");
-PRINT_DISPOSITION(DUB,  "dub");
-PRINT_DISPOSITION(ORIGINAL, "original");
-PRINT_DISPOSITION(COMMENT,  "comment");
-PRINT_DISPOSITION(LYRICS,   "lyrics");
-PRINT_DISPOSITION(KARAOKE,  "karaoke");
-PRINT_DISPOSITION(FORCED,   "forced");
-PRINT_DISPOSITION(HEARING_IMPAIRED, "hearing_impaired");
-PRINT_DISPOSITION(VISUAL_IMPAIRED,  "visual_impaired");
-PRINT_DISPOSITION(CLEAN_EFFECTS,"clean_effects");
-PRINT_DISPOSITION(ATTACHED_PIC, "attached_pic");
-PRINT_DISPOSITION(TIMED_THUMBNAILS, "timed_thumbnails");
-writer_print_section_footer(w);
+writer_print_section_header(w, in_program ? 
SECTION_ID_PROGRAM_STREAM_DISPOSITION : SECTION_ID_STREAM_DISPOSITION);
+PRINT_DISPOSITION(DEFAULT,  "default");
+PRINT_DISPOSITION(DUB,  "dub");
+PRINT_DISPOSITION(ORIGINAL, "original");
+PRINT_DISPOSITION(COMMENT,  "comment");
+PRINT_DISPOSITION(LYRICS,   "lyrics");
+PRINT_DISPOSITION(KARAOKE,  "karaoke");
+PRINT_DISPOSITION(FORCED,   "forced");
+PRINT_DISPOSITION(HEARING_IMPAIRED, "hearing_impaired");
+PRINT_DISPOSITION(VISUAL_IMPAIRED,  "visual_impaired");
+PRINT_DISPOSITION(CLEAN_EFFECTS,"clean_effects");
+PRINT_DISPOSITION(ATTACHED_PIC, "attached_pic");
+PRINT_DISPOSITION(TIMED_THUMBNAILS, "timed_thumbnails");
+writer_print_section_footer(w);
 }
 
 if (do_show_stream_tags)
-- 
1.7.1

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

[FFmpeg-devel] [PATCH V3 5/7] avformat: add rc_max_rate to AVStream

[Jun Zhao]

This field will be used in demuxer to expose the max bit rate, e,g
in MOV/MP4 esds box.

Signed-off-by: Jun Zhao 
---
 doc/APIchanges |3 +++
 libavformat/avformat.h |6 ++
 libavformat/version.h  |2 +-
 3 files changed, 10 insertions(+), 1 deletions(-)

diff --git a/doc/APIchanges b/doc/APIchanges
index db1879e..0921da1 100644
--- a/doc/APIchanges
+++ b/doc/APIchanges
@@ -15,6 +15,9 @@ libavutil: 2017-10-21
 
 API changes, most recent first:
 
+2018-11-xx - xx - lavf 58.23.100 - avformat.h
+  Add rc_max_rate to AVStream
+
  8< - FFmpeg 4.1 was cut here  8< -
 
 2018-10-27 - 718044dc19 - lavu 56.21.100 - pixdesc.h
diff --git a/libavformat/avformat.h b/libavformat/avformat.h
index fdaffa5..1732c24 100644
--- a/libavformat/avformat.h
+++ b/libavformat/avformat.h
@@ -938,6 +938,12 @@ typedef struct AVStream {
 AVRational avg_frame_rate;
 
 /**
+ * The max bitrate of the encoded data (in bits per second).
+ * - decoding: set by libavformat
+ */
+int64_t rc_max_rate;
+
+/**
  * For streams with AV_DISPOSITION_ATTACHED_PIC disposition, this packet
  * will contain the attached picture.
  *
diff --git a/libavformat/version.h b/libavformat/version.h
index 843f922..70e868f 100644
--- a/libavformat/version.h
+++ b/libavformat/version.h
@@ -32,7 +32,7 @@
 // Major bumping may affect Ticket5467, 5421, 5451(compatibility with Chromium)
 // Also please add any ticket numbers that you believe might be affected here
 #define LIBAVFORMAT_VERSION_MAJOR  58
-#define LIBAVFORMAT_VERSION_MINOR  22
+#define LIBAVFORMAT_VERSION_MINOR  23
 #define LIBAVFORMAT_VERSION_MICRO 100
 
 #define LIBAVFORMAT_VERSION_INT AV_VERSION_INT(LIBAVFORMAT_VERSION_MAJOR, \
-- 
1.7.1

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

[FFmpeg-devel] [PATCH V3 4/7] lavc/kvazaar: fix auto thread flag in kvazaar wrapper.

[Jun Zhao]

Now the kvazaar warpper didn't setting the threads for kvazaar API,
and kavzaar will auto selecte the thread number.

Signed-off-by: Jun Zhao 
---
 libavcodec/libkvazaar.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/libavcodec/libkvazaar.c b/libavcodec/libkvazaar.c
index 5bc5b4e..8f50bef 100644
--- a/libavcodec/libkvazaar.c
+++ b/libavcodec/libkvazaar.c
@@ -293,7 +293,7 @@ AVCodec ff_libkvazaar_encoder = {
 .long_name= NULL_IF_CONFIG_SMALL("libkvazaar H.265 / HEVC"),
 .type = AVMEDIA_TYPE_VIDEO,
 .id   = AV_CODEC_ID_HEVC,
-.capabilities = AV_CODEC_CAP_DELAY,
+.capabilities = AV_CODEC_CAP_DELAY | AV_CODEC_CAP_AUTO_THREADS,
 .pix_fmts = pix_fmts,
 
 .priv_class   = &class,
-- 
1.7.1

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

Re: [FFmpeg-devel] [PATCH V3 5/7] avformat: add rc_max_rate to AVStream

[Hendrik Leppkes]

On Thu, Nov 22, 2018 at 4:04 PM Jun Zhao  wrote:
>
> This field will be used in demuxer to expose the max bit rate, e,g
> in MOV/MP4 esds box.
>
> Signed-off-by: Jun Zhao 
> ---
>  doc/APIchanges |3 +++
>  libavformat/avformat.h |6 ++
>  libavformat/version.h  |2 +-
>  3 files changed, 10 insertions(+), 1 deletions(-)
>
> diff --git a/doc/APIchanges b/doc/APIchanges
> index db1879e..0921da1 100644
> --- a/doc/APIchanges
> +++ b/doc/APIchanges
> @@ -15,6 +15,9 @@ libavutil: 2017-10-21
>
>  API changes, most recent first:
>
> +2018-11-xx - xx - lavf 58.23.100 - avformat.h
> +  Add rc_max_rate to AVStream
> +
>   8< - FFmpeg 4.1 was cut here  8< -
>
>  2018-10-27 - 718044dc19 - lavu 56.21.100 - pixdesc.h
> diff --git a/libavformat/avformat.h b/libavformat/avformat.h
> index fdaffa5..1732c24 100644
> --- a/libavformat/avformat.h
> +++ b/libavformat/avformat.h
> @@ -938,6 +938,12 @@ typedef struct AVStream {
>  AVRational avg_frame_rate;
>
>  /**
> + * The max bitrate of the encoded data (in bits per second).
> + * - decoding: set by libavformat
> + */
> +int64_t rc_max_rate;
> +


We have AV_PKT_DATA_CPB_PROPERTIES / AVCPBProperties side-data for that.

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

Re: [FFmpeg-devel] [PATCH 2/3] flvdec: Mark the demuxer as allowing discontinuous timestamps

[Derek Buitenhuis]

On 22/11/2018 12:55, Carl Eugen Hoyos wrote:
> Only the downstreams that expect invalid files, no?

It's the generic way to handle containers which can have
discontinuous timestamps. Nothing to do with expecting invalid
files.

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

Re: [FFmpeg-devel] [PATCH 2/3] flvdec: Mark the demuxer as allowing discontinuous timestamps

[Jan Ekström]

On Thu, Nov 22, 2018 at 4:17 AM Michael Niedermayer
 wrote:
>
> On Wed, Nov 21, 2018 at 03:58:47PM +, Derek Buitenhuis wrote:
> > Any FLV file, not necessarily valid, but in extremely common use for live
> > or archived live purposes, may output discontinuous timestamps. As it 
> > currently
> > is, only files produced by NGINX's RTMP module will be marked as supporting
> > discontinuous timestamps, which is obviously untrue, and the fix was only
> > ever put in place for a single bug report / file. The FLV demuxer, however
> > will happily ingest any FLV, and output discontinuous timestamps, regardless
> > of whether this "live" demuxer is used, making the current set of flags 
> > untrue.
> >
> > Add the flag to the main demuxer, as this is how it *actually* works. Lying 
> > to
> > downstream API users about a demuxer's behavior is not OK.
> >
> > Also set AVFMT_NOBINSEARCH, as this should be true given discontinuous 
> > timetsamps.
> >
> > Signed-off-by: Derek Buitenhuis 
> > ---
> >  libavformat/flvdec.c | 14 --
> >  1 file changed, 4 insertions(+), 10 deletions(-)
>
> the specification says this:
> "Timestamp UI24 Time in milliseconds at which the data in this tag
>applies. This is relative to the first tag in the FLV file,
>which always has a timestamp of 0.
> "
> So flv does not seem to allow discontinuities. Any tool writing files with
> discontinuities would be faulty

How do you separate FLV files that came from RTMP originally (be it
live or VOD) from files that were "just files"?

Additionally, wasn't FLV with a time base of 1000 and a 32bit (signed
in "file" format and unsigned in RTMP (?!?!)) time stamp. See
4d3dd167dfdfa2f36724f5613f05f46e3477c0d1 .

I think I'm trying to sit down and note that FLV is a colossal mess
for everyone at this point.

>
> declaring files which have no discontinuities as having some would
> result in worse performing seeking in some cases. Both slower and or less
> accurate. Also flv IIRC allows gaps in tracks like no packets where there is
> silence. This may interfere with discontinuities as it looks
> like a discontinuity.

Yes, timestamps jumping is valid and I don't see this being similar to
discontinuities. The fact that ffmpeg.c doesn't like intra-stream
timestamp jumps in case this flag is set is orthogonal to this
specific thing IMHO.

>
> Can these files with discontinuities be detected somehow from the headers?
> If so then the probe function could be changed so they get the discontinuity
> flag while valid files do not have the disadvantages from having it set
>

Not that I know, unless FLV dumped from RTMP somehow magically has
some special identifier. I have not noticed any so far.

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

[FFmpeg-devel] [RFC] VDD FFmpeg session and community survey

[Thilo Borgmann]

Hi all,

I'm very sorry that it took me so long to send this to the list, finally.
Since this is an everlasting topic for years, I wanted to deal
thoroughly with it to have a chance to actually influence the situation.

Like in many previous years/sessions about FFmpeg development, the topic of
hostility at the ML and IRC channel was discussed yet another time. There
have been several voices at this year's session that are still unhappy
with the current hostility in the FFmpeg community. So this point has been
discussed in the audience for a while. However, there has also been a voice
claiming that the current situation and regulation by our CoC is ok and working.

According to my experience, these discussions lead to two ends. First,
is considering the FFmpeg community to be a hostile environment shared by a
majority of the community so that any further thoughts to try to change this are
valid or not? Second, assuming it is a majority that dislikes current hostility,
what to do about it to improve the situation?

Long ago, JB made a proposal to overcome this by getting a community committee
to act upon hostile behavior in our environment and sanction the respective
authors. This proposal has been brought up again regarding the question of how
to proceed and like in the previous years, this proposal raised no rejections
from anybody present (this and in the previous years).

In the end, the outcome of this VDDs FFmpeg session has been that I bring this
proposal to the mailing list, finally. Therefore, I took the time to talk to
several people not only about the proposal itself but also about the experience
of other communities having such a committee driven mechanism of dealing with
CoC conflicts. From that the idea emerged to get an overview of the actual 
community
opinion of things is to conduct a simple survey about this question. So this is
exactly what I'd like to do next to giving the mere proposal.

The proposal of a community committee summarized:

- A committee is to be created consisting of community members that are voted
into it
- This committee can (upon request) sanction violations of our CoC by its given
powers
- The committee is object to reelection every year

A more detailed possible implementation of the proposal is attached as a patch 
to
our developers documentation. The survey is done to get an idea of what the 
community
thinks about that matter and its proposed solution.

The survey shall be conducted for everyone to participate freely, so a simple
thread on the mailing list would hardly be suitable and will most likely end in
endless discussions. To help with that, we've set up a survey that can be done 
completely
anonymously by sending out private tokens to all possible participants. Even 
the survey
admins cannot map given survey answers to a person/token.

Please note that this survey is _not_ meant to be a vote about the proposal. It 
is to
determine if we should actually have a refinement/vote on instantiating such a
community committee - depending on the community's point of view.

I will start this survey and sending out tokens directly to every subscriber of
the ffmpeg-devel mailing list on this Friday, Nov 23rd. If you don't want to
participate in the survey, you can send me a private mail before that data to
exclude your mail address from the participants lists. Afterwards you can click
the link in the mails to opt out of the survey yourself. The survey will end on
Mondday, Dez 3nd (a little more than a week). Afterwards, I will post the 
results
of the survey here in this thread. 

I'd really appreciate participation in the survey from everyone. I'd like to 
ask to file
just one survey for every mail address you might have registered here - you can 
opt-out
or just ignore additional mails. I'm sorry for spam for everyone not reading 
this thread.
Many thanks to the KDE community and Lydia in particular for discussion and 
supporting us
with the survey infrastructure.

Thanks,
Thilo
From 777631a9181ccb549170409b7cf9c5934ab6aeb8 Mon Sep 17 00:00:00 2001
From: Thilo Borgmann 
Date: Thu, 22 Nov 2018 19:49:18 +0100
Subject: [PATCH] doc/developers: Add Community Committee

---
 doc/developer.texi | 64 ++
 1 file changed, 64 insertions(+)

diff --git a/doc/developer.texi b/doc/developer.texi
index 5c342c9106..5c4014b7de 100644
--- a/doc/developer.texi
+++ b/doc/developer.texi
@@ -451,6 +451,70 @@ instead and point them in the right direction.
 Finally, keep in mind the immortal words of Bill and Ted,
 "Be excellent to each other."
 
+@chapter Community Committee
+
+The objective of the community committee is to sustain an environment as 
described
+by the code of conduct. It is to protect the dignity of each member of the 
community
+and to stop personal harassment of any kind. It is not to interfere with any 
other
+aspects of the development process.
+
+Further on it is to impose any sanctions related to violations of the code of

[FFmpeg-devel] Budding developer

[Sid Sharma]

So I am currently pursuing my degree in computer science but I believe I
have a pretty good foundation in C and also know my way around assembly and
was wondering if the GSoC is the right place for me or am I aiming too
high. I am currenty in first year but a super geek. So can you guide me how
this  works as I am new to opensource and would like to have a project
under my belt. Please let me know if I also have to create a CV for the
same.

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

Re: [FFmpeg-devel] Budding developer

[Tomas Härdin]

fre 2018-11-23 klockan 00:58 +0530 skrev Sid Sharma:
> So I am currently pursuing my degree in computer science but I believe I
> have a pretty good foundation in C and also know my way around assembly and
> was wondering if the GSoC is the right place for me or am I aiming too
> high.

C + asm are certainly very relevant skills

> I am currenty in first year but a super geek. So can you guide me how
> this  works as I am new to opensource and would like to have a project
> under my belt. Please let me know if I also have to create a CV for the
> same.

I don't know how far along the plans for GSoC 2019 are, but if you have
a project idea you could pitch it. There's also some useful information
and ideas on the wiki(s):

https://trac.ffmpeg.org/wiki/WikiStart
https://trac.ffmpeg.org/wiki/SponsoringPrograms/GSoC/2018
https://wiki.multimedia.cx/index.php/FFmpeg_Summer_Of_Code
https://wiki.multimedia.cx/index.php/Small_FFmpeg_Tasks

Not all of this may be up to date, and it might not be all of it, but
it should give an idea at least.

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

[FFmpeg-devel] [PATCH] avformat: add DHAV demuxer

[Paul B Mahol]

Missing pts handling and correct codec detection.
More samples wanted.

Signed-off-by: Paul B Mahol 
---
 libavformat/Makefile |   1 +
 libavformat/allformats.c |   1 +
 libavformat/dhav.c   | 136 +++
 3 files changed, 138 insertions(+)
 create mode 100644 libavformat/dhav.c

diff --git a/libavformat/Makefile b/libavformat/Makefile
index e4d997c4a0..a6c5ea9aa3 100644
--- a/libavformat/Makefile
+++ b/libavformat/Makefile
@@ -149,6 +149,7 @@ OBJS-$(CONFIG_DAUD_DEMUXER)  += dauddec.o
 OBJS-$(CONFIG_DAUD_MUXER)+= daudenc.o
 OBJS-$(CONFIG_DCSTR_DEMUXER) += dcstr.o
 OBJS-$(CONFIG_DFA_DEMUXER)   += dfa.o
+OBJS-$(CONFIG_DHAV_DEMUXER)  += dhav.o
 OBJS-$(CONFIG_DIRAC_DEMUXER) += diracdec.o rawdec.o
 OBJS-$(CONFIG_DIRAC_MUXER)   += rawenc.o
 OBJS-$(CONFIG_DNXHD_DEMUXER) += dnxhddec.o rawdec.o
diff --git a/libavformat/allformats.c b/libavformat/allformats.c
index 498077e1de..5fb5bf17c6 100644
--- a/libavformat/allformats.c
+++ b/libavformat/allformats.c
@@ -110,6 +110,7 @@ extern AVInputFormat  ff_daud_demuxer;
 extern AVOutputFormat ff_daud_muxer;
 extern AVInputFormat  ff_dcstr_demuxer;
 extern AVInputFormat  ff_dfa_demuxer;
+extern AVInputFormat  ff_dhav_demuxer;
 extern AVInputFormat  ff_dirac_demuxer;
 extern AVOutputFormat ff_dirac_muxer;
 extern AVInputFormat  ff_dnxhd_demuxer;
diff --git a/libavformat/dhav.c b/libavformat/dhav.c
new file mode 100644
index 00..ad27949d0f
--- /dev/null
+++ b/libavformat/dhav.c
@@ -0,0 +1,136 @@
+/*
+ * DHAV demuxer
+ *
+ * Copyright (c) 2017 Paul B Mahol
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include "avformat.h"
+#include "internal.h"
+
+typedef struct DHAVContext {
+unsigned type;
+int64_t apts;
+int64_t vpts;
+} DHAVContext;
+
+static int dhav_probe(AVProbeData *p)
+{
+if (memcmp(p->buf, "DHAV", 4))
+return 0;
+
+return AVPROBE_SCORE_MAX;
+}
+
+static int dhav_read_header(AVFormatContext *s)
+{
+AVStream *st, *ast;
+
+st = avformat_new_stream(s, NULL);
+if (!st)
+return AVERROR(ENOMEM);
+
+st->codecpar->codec_type  = AVMEDIA_TYPE_VIDEO;
+st->codecpar->codec_id= AV_CODEC_ID_H264;
+st->need_parsing  = AVSTREAM_PARSE_FULL_RAW;
+avpriv_set_pts_info(st, 64, 1, 25);
+
+ast = avformat_new_stream(s, NULL);
+if (!ast)
+return AVERROR(ENOMEM);
+
+ast->codecpar->codec_type  = AVMEDIA_TYPE_AUDIO;
+ast->codecpar->codec_id= AV_CODEC_ID_PCM_ALAW;
+ast->codecpar->channels= 1;
+ast->codecpar->sample_rate = 8000;
+avpriv_set_pts_info(ast, 64, 1, 8000);
+
+s->ctx_flags |= AVFMTCTX_NOHEADER;
+
+return 0;
+}
+
+static int read_chunk(AVFormatContext *s)
+{
+DHAVContext *dhav = s->priv_data;
+unsigned size, skip;
+int64_t start, end;
+
+start = avio_tell(s->pb);
+
+if (avio_feof(s->pb))
+return AVERROR_EOF;
+
+if (avio_rl32(s->pb) != MKTAG('D','H','A','V'))
+return AVERROR_INVALIDDATA;
+
+dhav->type = avio_r8(s->pb);
+avio_skip(s->pb, 3);
+avio_rl32(s->pb);
+size = avio_rl32(s->pb);
+if (dhav->type == 0xf1) {
+avio_skip(s->pb, size - 16);
+return 0;
+}
+
+avio_rl32(s->pb);
+avio_skip(s->pb, 2);
+skip = avio_r8(s->pb);
+avio_skip(s->pb, 1);
+avio_skip(s->pb, skip);
+
+end = avio_tell(s->pb);
+
+return size - 8 - (end - start);
+}
+
+static int dhav_read_packet(AVFormatContext *s, AVPacket *pkt)
+{
+DHAVContext *dhav = s->priv_data;
+int64_t start;
+int ret;
+
+start = avio_tell(s->pb);
+
+while ((ret = read_chunk(s)) == 0)
+;
+
+if (ret < 0)
+return ret;
+ret = av_get_packet(s->pb, pkt, ret);
+if (ret < 0)
+return ret;
+pkt->stream_index = dhav->type == 0xF0 ? 1 : 0;
+pkt->pos = start;
+if (avio_rl32(s->pb) != MKTAG('d','h','a','v'))
+return AVERROR_INVALIDDATA;
+avio_skip(s->pb, 4);
+
+return ret;
+}
+
+AVInputFormat ff_dhav_demuxer = {
+.name   = "dhav",
+.long_name  = NULL_IF_CONFIG_SMALL("DHAV"),
+.priv_data_size = sizeof(DHAVContext),
+.read_probe = dhav_probe,
+.re

Re: [FFmpeg-devel] Budding developer

[Thilo Borgmann]

Am 22.11.18 um 21:17 schrieb Tomas Härdin:
> fre 2018-11-23 klockan 00:58 +0530 skrev Sid Sharma:
>> So I am currently pursuing my degree in computer science but I believe I
>> have a pretty good foundation in C and also know my way around assembly and
>> was wondering if the GSoC is the right place for me or am I aiming too
>> high.
> 
> C + asm are certainly very relevant skills

Indeed. There is an easy way to figure out if your knowledge is sufficient -
just pic a topic/patch/whatever and try to submit a fixing patch for the issue.
You will find some ideas at the links Tomas had written.

You can always ask for guidance if in doubt, in the bugtracker or the ML.


>> I am currenty in first year but a super geek. So can you guide me how
>> this  works as I am new to opensource and would like to have a project
>> under my belt. Please let me know if I also have to create a CV for the
>> same.

Nothing alike will be needed. You are just welcome to contribute.


> I don't know how far along the plans for GSoC 2019 are, but if you have
> a project idea you could pitch it. There's also some useful information
> and ideas on the wiki(s):
> 
> https://trac.ffmpeg.org/wiki/WikiStart
> https://trac.ffmpeg.org/wiki/SponsoringPrograms/GSoC/2018
> https://wiki.multimedia.cx/index.php/FFmpeg_Summer_Of_Code
> https://wiki.multimedia.cx/index.php/Small_FFmpeg_Tasks
> 
> Not all of this may be up to date, and it might not be all of it, but
> it should give an idea at least.

Well all we know is that there will be a GSoC 2019. Nobody knows if FFmpeg gets 
selected as an org again.
As Tomas said, you can absolutely create your own project proposal like the 
ones you will find on trac.
Makes little sense before knowing if FFmpeg will participate again, though.

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

Re: [FFmpeg-devel] Cryo APC Files (How to convert WAV files to APC files) ?

[Thomas Tgames]

Thanks again a lot Tomas Hardin.

I have just send what you need =)

Really cool for Atlantis The Lost Tales players !

De : Thomas Tgames
Envoyé le :mercredi 21 novembre 2018 14:38
À : FFmpeg development discussions and patches
Objet :Re: [FFmpeg-devel] Cryo APC Files (How to convert WAV files to APC 
files) ?

Thanks a lot if you can do this Tomas Härdin !!
It will be very cool for the game.

Best Regards.

De : Tomas Härdin
Envoyé le :mercredi 21 novembre 2018 14:09
À : ffmpeg-devel@ffmpeg.org
Objet :Re: [FFmpeg-devel] Cryo APC Files (How to convert WAV files to APC 
files) ?

ons 2018-11-21 klockan 11:19 + skrev Thomas Tgames:
> Hi,
>
> It’s only for a fan project.
> We already almost finish the project but we want to include this
> music in the game.
> Like ffmpeg include the possibility to decode APC files, i ask if
> someone on ffmpeg development team can include the encoding to APC
> files into ffmpeg.

The code looks like it might not be too much work to adapt for APC, as
Michael says. There's already encoders for other IMA ADPCM variants in
there

Maybe someone (me) might get bored enough to take a closer look this
weekend

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

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

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

Re: [FFmpeg-devel] [RFC] VDD FFmpeg session and community survey

[Rostislav Pehlivanov]

On Thu, 22 Nov 2018 at 19:02, Thilo Borgmann  wrote:

>
> Please note that this survey is _not_ meant to be a vote about the
> proposal. It is to
> determine if we should actually have a refinement/vote on instantiating
> such a
> community committee - depending on the community's point of view.
>

Spamming (which this would certainly be a textbook definition of) every
subscriber ever (including those who forgot) is unacceptable.


+Further on it is to impose any sanctions related to violations of the code of
> +conduct only if these incidents are brought up to its attention from directly
> +involved parties of such an incident.
>
> Violations should be limited to publicly logged IRC channels or the ML.
Otherwise without proof this will end up as a "but they said" situation.

++ at subheading 
Committee members
> +
> +The community committee consists of three elected individuals. Committee 
> members are
> +elected for a period of one year and are automatically removed from the 
> committee after
> +that period. Reelection of committee members for the following period is 
> possible.
>
> Three members is far too low and would be prone to bias. 5 or 7 would be
better.


> +
> +If for any reason a current member of the committee wishes to leave the 
> committee, the
> +whole committee is to be reelected. No former committee members having left 
> the committee
> +on their own wish can be a candidate for the successor committee.
>
> That last sentence is random.

+The vote has to implement a direct, free, equal and secret election.
> +The results are to be publicly available.
> +The election should be completed not later than the end of the ongoing 
> period.
> +Any community member can call on itself or any other person to be a 
> candidate for an election.
>
> What if a majority of the committee is biased and bans everyone they
disagree with to take over the project? They certainly could.
What if the committee's decision is something the majority of the
developers disagree with?

This is why I'm against formalizing such prodecures. They're too inflexible
and absolute, and end up being abused or overused (like videolan's weekly
temporary bannings I've heard of).
Furthermore why do you bring this up now at all? We haven't had accidents
of this nature in quite some time. In fact the last time it was the ML
admin's random incorrect decision to block a discussion which ended up
being a problem that everyone disagreed with. And that was 11 months ago.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] configure: Avoid use of nonstandard features of sed

[Mark Thompson]

Standard sed does not support EREs.
---
The Darwin version script part was only tested by running it on the version 
scripts and looking at the output, not actually building on that platform - it 
would be helpful if someone could check that it actually works.

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

diff --git a/configure b/configure
index b4f944cfb0..370c6e9993 100755
--- a/configure
+++ b/configure
@@ -3723,8 +3723,7 @@ find_things_extern(){
 
 find_filters_extern(){
 file=$source_path/$1
-#sed -n "s/^extern AVFilter 
ff_\([avfsinkrc]\{2,5\}\)_\(\w\+\);/\2_filter/p" $file
-sed -E -n "s/^extern AVFilter 
ff_([avfsinkrc]{2,5})_([a-zA-Z0-9_]+);/\2_filter/p" $file
+sed -n 's/^extern AVFilter 
ff_[avfsinkrc]\{2,5\}_\([[:alnum:]_]\{1,\}\);/\1_filter/p' $file
 }
 
 FILTER_LIST=$(find_filters_extern libavfilter/allfilters.c)
@@ -5190,7 +5189,7 @@ case $target_os in
 is_in -isysroot $ld $LDFLAGS  || check_ldflags  -isysroot 
$sysroot
 fi
 version_script='-exported_symbols_list'
-VERSION_SCRIPT_POSTPROCESS_CMD='tr " " "\n" | sed -n 
/global:/,/local:/p | grep ";" | tr ";" "\n" | sed -E "s/(.+)/_\1/g" | sed -E 
"s/(.+[^*])/\1*/"'
+VERSION_SCRIPT_POSTPROCESS_CMD='tr " " "\n" | sed -n 
/global:/,/local:/p | grep ";" | tr ";" "\n" | sed "s/\(.\{1,\}\)/_\1/g" | sed 
"s/\(.\{1,\}[^*]\)/\1*/"'
 ;;
 msys*)
 die "Native MSYS builds are discouraged, please use the MINGW 
environment."
-- 
2.19.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/3] cbs_h2645: Avoid memcpy when splitting fragment

[Mark Thompson]

On 21/11/18 18:34, Andreas Rheinhardt wrote:
> Now memcpy is avoided for NAL units that don't contain 0x03 escape
> characters.
> 
> Improves performance of cbs_h2645_fragment_add_nals from 36940
> decicycles to 6364 decicycles based on 8 runs with a 5.1 Mb/s H.264
> sample (262144 runs each).
> 
> Signed-off-by: Andreas Rheinhardt 
> ---
>  libavcodec/cbs_h2645.c   | 29 +
>  libavcodec/h2645_parse.h |  5 +
>  2 files changed, 22 insertions(+), 12 deletions(-)
> 
> diff --git a/libavcodec/cbs_h2645.c b/libavcodec/cbs_h2645.c
> index a2d0170e97..6846cad0bb 100644
> --- a/libavcodec/cbs_h2645.c
> +++ b/libavcodec/cbs_h2645.c
> @@ -532,24 +532,29 @@ static int 
> cbs_h2645_fragment_add_nals(CodedBitstreamContext *ctx,
>  for (i = 0; i < packet->nb_nals; i++) {
>  const H2645NAL *nal = &packet->nals[i];
>  size_t size = nal->size;
> -uint8_t *data;
> -
>  // Remove trailing zeroes.
>  while (size > 0 && nal->data[size - 1] == 0)
>  --size;
>  av_assert0(size > 0);
>  
> -data = av_malloc(size + AV_INPUT_BUFFER_PADDING_SIZE);
> -if (!data)
> -return AVERROR(ENOMEM);
> -memcpy(data, nal->data, size);
> -memset(data + size, 0, AV_INPUT_BUFFER_PADDING_SIZE);
> +if (nal->data == nal->raw_data) {
> +err = ff_cbs_insert_unit_data(ctx, frag, -1, nal->type,
> +(uint8_t*)nal->data, size, frag->data_ref);
> +if (err < 0)
> +return err;
> +} else {
> +uint8_t *data = av_malloc(size + AV_INPUT_BUFFER_PADDING_SIZE);
> +if (!data)
> +return AVERROR(ENOMEM);
> +memcpy(data, nal->data, size);
> +memset(data + size, 0, AV_INPUT_BUFFER_PADDING_SIZE);
>  
> -err = ff_cbs_insert_unit_data(ctx, frag, -1, nal->type,
> -  data, size, NULL);
> -if (err < 0) {
> -av_freep(&data);
> -return err;
> +err = ff_cbs_insert_unit_data(ctx, frag, -1, nal->type,
> +  data, size, NULL);
> +if (err < 0) {
> +av_freep(&data);
> +return err;
> +}
>  }
>  }
>  
> diff --git a/libavcodec/h2645_parse.h b/libavcodec/h2645_parse.h
> index 2e29ad26cb..a0a5ca5868 100644
> --- a/libavcodec/h2645_parse.h
> +++ b/libavcodec/h2645_parse.h
> @@ -86,6 +86,11 @@ int ff_h2645_extract_rbsp(const uint8_t *src, int length, 
> H2645RBSP *rbsp,
>  
>  /**
>   * Split an input packet into NAL units.
> + * If data == raw_data holds true for a NAL unit of the returned pkt, then
> + * said NAL unit does not contain any emulation_prevention_three_byte and
> + * the data is contained in the input buffer pointed to by buf.
> + * Otherwise, the unescaped data is part of the rbsp_buffer described by the
> + * packet's H2645RBSP.
>   */
>  int ff_h2645_packet_split(H2645Packet *pkt, const uint8_t *buf, int length,
>void *logctx, int is_nalff, int nal_length_size,
> 

LGTM, tested, applied.

Thanks,

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

Re: [FFmpeg-devel] [PATCH 2/3] h2645_parse: Make ff_h2645_packet_split reference-compatible

[Mark Thompson]

On 21/11/18 18:34, Andreas Rheinhardt wrote:
> This is in preparation for a patch for cbs_h2645. Now the packet's
> rbsp_buffer can be owned by an AVBuffer.
> 
> Signed-off-by: Andreas Rheinhardt 
> ---
>  libavcodec/cbs_h2645.c | 12 -
>  libavcodec/extract_extradata_bsf.c |  4 +--
>  libavcodec/h2645_parse.c   | 43 +++---
>  libavcodec/h2645_parse.h   | 10 +--
>  libavcodec/h264_parse.c|  4 +--
>  libavcodec/h264dec.c   |  6 ++---
>  libavcodec/hevc_parse.c|  5 ++--
>  libavcodec/hevc_parser.c   |  4 +--
>  libavcodec/hevcdec.c   |  4 +--
>  9 files changed, 67 insertions(+), 25 deletions(-)
> 
> ...
> diff --git a/libavcodec/h2645_parse.c b/libavcodec/h2645_parse.c
> index aaa4b8f443..ad5d04f0a4 100644
> --- a/libavcodec/h2645_parse.c
> +++ b/libavcodec/h2645_parse.c
> @@ -343,9 +343,37 @@ static int find_next_start_code(const uint8_t *buf, 
> const uint8_t *next_avc)
>  return i + 3;
>  }
>  
> +static void handle_ref_buffer(H2645RBSP *rbsp, AVBufferRef **ref, int size)
> +{
> +if (size + AV_INPUT_BUFFER_PADDING_SIZE <= 0)
> +goto fail;
> +
> +size += AV_INPUT_BUFFER_PADDING_SIZE;
> +
> +if (*ref && (*ref)->size >= size && av_buffer_is_writable(*ref))
> +return;
> +
> +av_buffer_unref(ref);
> +
> +size = FFMAX(size + (size >> 4) + 32, size);
> +
> +*ref = av_buffer_alloc(size);
> +if (*ref) {
> +rbsp->rbsp_buffer= (*ref)->data;
> +rbsp->rbsp_buffer_alloc_size = size;
> +return;
> +}
> +
> +fail:
> +av_buffer_unref(ref);
> +rbsp->rbsp_buffer= NULL;
> +rbsp->rbsp_buffer_alloc_size = 0;
> +return;
> +}
> +
>  int ff_h2645_packet_split(H2645Packet *pkt, const uint8_t *buf, int length,
>void *logctx, int is_nalff, int nal_length_size,
> -  enum AVCodecID codec_id, int small_padding)
> +  enum AVCodecID codec_id, int small_padding, 
> AVBufferRef **ref)
>  {
>  GetByteContext bc;
>  int consumed, ret = 0;
> @@ -353,7 +381,11 @@ int ff_h2645_packet_split(H2645Packet *pkt, const 
> uint8_t *buf, int length,
>  int64_t padding = small_padding ? 0 : MAX_MBPAIR_SIZE;
>  
>  bytestream2_init(&bc, buf, length);
> -av_fast_padded_malloc(&pkt->rbsp.rbsp_buffer, 
> &pkt->rbsp.rbsp_buffer_alloc_size, length + padding);
> +if (!ref)
> +av_fast_padded_malloc(&pkt->rbsp.rbsp_buffer, 
> &pkt->rbsp.rbsp_buffer_alloc_size, length + padding);
> +else
> +handle_ref_buffer(&pkt->rbsp, ref, length + padding);
> +
>  if (!pkt->rbsp.rbsp_buffer)
>  return AVERROR(ENOMEM);
>  
> @@ -466,7 +498,7 @@ int ff_h2645_packet_split(H2645Packet *pkt, const uint8_t 
> *buf, int length,
>  return 0;
>  }
>  
> -void ff_h2645_packet_uninit(H2645Packet *pkt)
> +void ff_h2645_packet_uninit(H2645Packet *pkt, AVBufferRef *ref)
>  {
>  int i;
>  for (i = 0; i < pkt->nals_allocated; i++) {
> @@ -474,6 +506,9 @@ void ff_h2645_packet_uninit(H2645Packet *pkt)
>  }
>  av_freep(&pkt->nals);
>  pkt->nals_allocated = 0;
> -av_freep(&pkt->rbsp.rbsp_buffer);
> +if (!ref)
> +av_freep(&pkt->rbsp.rbsp_buffer);
> +else
> +pkt->rbsp.rbsp_buffer = NULL;
>  pkt->rbsp.rbsp_buffer_alloc_size = pkt->rbsp.rbsp_buffer_size = 0;
>  }

I don't think I like how you've ended up with this dummy argument to uninit 
saying whether the content should be freed or not.

Can we instead move the AVBufferRef into the H2645Packet structure itself, so 
the user doesn't have to separately keep track of it?  Since the same packet 
structure is reused in cbs_h2645.c without an uninit, I think that avoids 
having to pass an extra argument to either function.

Thanks,

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

Re: [FFmpeg-devel] [PATCH] configure: Avoid use of nonstandard features of sed

[Carl Eugen Hoyos]

2018-11-22 23:47 GMT+01:00, Mark Thompson :
> Standard sed does not support EREs.

Please mention ticket #7310 in the commit message.

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

[FFmpeg-devel] [PATCH 1/2] avcodec/tiff: Limit filtering to decoded data

[Michael Niedermayer]

Fixes: Timeout
Fixes: 
11068/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_TIFF_fuzzer-5698456681709568

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

diff --git a/libavcodec/tiff.c b/libavcodec/tiff.c
index 74b76c9fdf..6271c937c3 100644
--- a/libavcodec/tiff.c
+++ b/libavcodec/tiff.c
@@ -1421,6 +1421,7 @@ again:
 planes = s->planar ? s->bppcount : 1;
 for (plane = 0; plane < planes; plane++) {
 int remaining = avpkt->size;
+int decoded_height;
 stride = p->linesize[plane];
 dst = p->data[plane];
 for (i = 0; i < s->height; i += s->rps) {
@@ -1448,6 +1449,8 @@ again:
 break;
 }
 }
+decoded_height = FFMIN(i, s->height);
+
 if (s->predictor == 2) {
 if (s->photometric == TIFF_PHOTOMETRIC_YCBCR) {
 av_log(s->avctx, AV_LOG_ERROR, "predictor == 2 with YUV is 
unsupported");
@@ -1464,7 +1467,7 @@ again:
 s->avctx->pix_fmt == AV_PIX_FMT_YA16LE ||
 s->avctx->pix_fmt == AV_PIX_FMT_GBRP16LE ||
 s->avctx->pix_fmt == AV_PIX_FMT_GBRAP16LE) {
-for (i = 0; i < s->height; i++) {
+for (i = 0; i < decoded_height; i++) {
 for (j = soff; j < ssize; j += 2)
 AV_WL16(dst + j, AV_RL16(dst + j) + AV_RL16(dst + j - 
soff));
 dst += stride;
@@ -1475,13 +1478,13 @@ again:
s->avctx->pix_fmt == AV_PIX_FMT_YA16BE ||
s->avctx->pix_fmt == AV_PIX_FMT_GBRP16BE ||
s->avctx->pix_fmt == AV_PIX_FMT_GBRAP16BE) {
-for (i = 0; i < s->height; i++) {
+for (i = 0; i < decoded_height; i++) {
 for (j = soff; j < ssize; j += 2)
 AV_WB16(dst + j, AV_RB16(dst + j) + AV_RB16(dst + j - 
soff));
 dst += stride;
 }
 } else {
-for (i = 0; i < s->height; i++) {
+for (i = 0; i < decoded_height; i++) {
 for (j = soff; j < ssize; j++)
 dst[j] += dst[j - soff];
 dst += stride;
-- 
2.19.1

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

[FFmpeg-devel] [PATCH 2/2] avcodec/tiff: Fix integer overflows in left shift in init_image()

[Michael Niedermayer]

Fixes: left shift of 255 by 24 places cannot be represented in type 'int'
Fixes: 
11377/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_TIFF_fuzzer-5694319101476864

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

diff --git a/libavcodec/tiff.c b/libavcodec/tiff.c
index 6271c937c3..64a3261fd9 100644
--- a/libavcodec/tiff.c
+++ b/libavcodec/tiff.c
@@ -706,7 +706,7 @@ static int init_image(TiffContext *s, ThreadFrame *frame)
 s->avctx->pix_fmt = s->palette_is_set ? AV_PIX_FMT_PAL8 : 
AV_PIX_FMT_GRAY8;
 break;
 case 10081:
-switch (s->pattern[0] | (s->pattern[1] << 8) | (s->pattern[2] << 16) | 
(s->pattern[3] << 24)) {
+switch (s->pattern[0] | (s->pattern[1] << 8) | (s->pattern[2] << 16) | 
((unsigned)s->pattern[3] << 24)) {
 case 0x02010100:
 s->avctx->pix_fmt = AV_PIX_FMT_BAYER_RGGB8;
 break;
@@ -721,7 +721,7 @@ static int init_image(TiffContext *s, ThreadFrame *frame)
 break;
 default:
 av_log(s->avctx, AV_LOG_ERROR, "Unsupported Bayer pattern: 0x%X\n",
-   s->pattern[0] | s->pattern[1] << 8 | s->pattern[2] << 16 | 
s->pattern[3] << 24);
+   s->pattern[0] | s->pattern[1] << 8 | s->pattern[2] << 16 | 
(unsigned)s->pattern[3] << 24);
 return AVERROR_PATCHWELCOME;
 }
 break;
@@ -741,12 +741,12 @@ static int init_image(TiffContext *s, ThreadFrame *frame)
 break;
 default:
 av_log(s->avctx, AV_LOG_ERROR, "Unsupported Bayer pattern: 0x%X\n",
-   s->pattern[0] | s->pattern[1] << 8 | s->pattern[2] << 16 | 
s->pattern[3] << 24);
+   s->pattern[0] | s->pattern[1] << 8 | s->pattern[2] << 16 | 
(unsigned)s->pattern[3] << 24);
 return AVERROR_PATCHWELCOME;
 }
 break;
 case 10161:
-switch (s->pattern[0] | s->pattern[1] << 8 | s->pattern[2] << 16 | 
s->pattern[3] << 24) {
+switch (s->pattern[0] | s->pattern[1] << 8 | s->pattern[2] << 16 | 
(unsigned)s->pattern[3] << 24) {
 case 0x02010100:
 s->avctx->pix_fmt = s->le ? AV_PIX_FMT_BAYER_RGGB16LE : 
AV_PIX_FMT_BAYER_RGGB16BE;
 break;
@@ -761,7 +761,7 @@ static int init_image(TiffContext *s, ThreadFrame *frame)
 break;
 default:
 av_log(s->avctx, AV_LOG_ERROR, "Unsupported Bayer pattern: 0x%X\n",
-   s->pattern[0] | s->pattern[1] << 8 | s->pattern[2] << 16 | 
s->pattern[3] << 24);
+   s->pattern[0] | s->pattern[1] << 8 | s->pattern[2] << 16 | 
(unsigned)s->pattern[3] << 24);
 return AVERROR_PATCHWELCOME;
 }
 break;
-- 
2.19.1

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

Re: [FFmpeg-devel] [PATCH 2/3] flvdec: Mark the demuxer as allowing discontinuous timestamps

[Michael Niedermayer]

On Thu, Nov 22, 2018 at 07:18:04PM +0200, Jan Ekström wrote:
> On Thu, Nov 22, 2018 at 4:17 AM Michael Niedermayer
>  wrote:
> >
> > On Wed, Nov 21, 2018 at 03:58:47PM +, Derek Buitenhuis wrote:
> > > Any FLV file, not necessarily valid, but in extremely common use for live
> > > or archived live purposes, may output discontinuous timestamps. As it 
> > > currently
> > > is, only files produced by NGINX's RTMP module will be marked as 
> > > supporting
> > > discontinuous timestamps, which is obviously untrue, and the fix was only
> > > ever put in place for a single bug report / file. The FLV demuxer, however
> > > will happily ingest any FLV, and output discontinuous timestamps, 
> > > regardless
> > > of whether this "live" demuxer is used, making the current set of flags 
> > > untrue.
> > >
> > > Add the flag to the main demuxer, as this is how it *actually* works. 
> > > Lying to
> > > downstream API users about a demuxer's behavior is not OK.
> > >
> > > Also set AVFMT_NOBINSEARCH, as this should be true given discontinuous 
> > > timetsamps.
> > >
> > > Signed-off-by: Derek Buitenhuis 
> > > ---
> > >  libavformat/flvdec.c | 14 --
> > >  1 file changed, 4 insertions(+), 10 deletions(-)
> >
> > the specification says this:
> > "Timestamp UI24 Time in milliseconds at which the data in this tag
> >applies. This is relative to the first tag in the FLV file,
> >which always has a timestamp of 0.
> > "
> > So flv does not seem to allow discontinuities. Any tool writing files with
> > discontinuities would be faulty
> 
> How do you separate FLV files that came from RTMP originally (be it
> live or VOD) from files that were "just files"?
> 
> Additionally, wasn't FLV with a time base of 1000 and a 32bit (signed
> in "file" format and unsigned in RTMP (?!?!)) time stamp. See
> 4d3dd167dfdfa2f36724f5613f05f46e3477c0d1 .
> 
> I think I'm trying to sit down and note that FLV is a colossal mess
> for everyone at this point.
> 

> >
> > declaring files which have no discontinuities as having some would
> > result in worse performing seeking in some cases. Both slower and or less
> > accurate. Also flv IIRC allows gaps in tracks like no packets where there is
> > silence. This may interfere with discontinuities as it looks
> > like a discontinuity.
> 
> Yes, timestamps jumping is valid and I don't see this being similar to
> discontinuities. The fact that ffmpeg.c doesn't like intra-stream
> timestamp jumps in case this flag is set is orthogonal to this
> specific thing IMHO.

a simple example:
0,1,2,3,4,403,404,405
these are a files timestamps, is this a discontinuity or a gap of silence?

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

I know you won't believe me, but the highest form of Human Excellence is
to question oneself and others. -- Socrates


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

Re: [FFmpeg-devel] [PATCH 2/3] flvdec: Mark the demuxer as allowing discontinuous timestamps

[Michael Niedermayer]

On Thu, Nov 22, 2018 at 10:27:18AM +, Derek Buitenhuis wrote:
> On 22/11/2018 02:16, Michael Niedermayer wrote:
> > the specification says this:
> > "Timestamp UI24 Time in milliseconds at which the data in this tag
> > applies. This is relative to the first tag in the FLV file,
> > which always has a timestamp of 0.
> > "
> > So flv does not seem to allow discontinuities. Any tool writing files with
> > discontinuities would be faulty
> 
> I know they're not valid, however in the real world, tons and tons of these 
> files
> exists, since this is how live FLV is done quite often.
> 
> > declaring files which have no discontinuities as having some would
> > result in worse performing seeking in some cases. Both slower and or less
> > accurate. Also flv IIRC allows gaps in tracks like no packets where there is
> > silence. This may interfere with discontinuities as it looks
> > like a discontinuity.
> 
> I agree, but then how do you propose we handle FLVs that do have 
> discontinuites?
> Currently the demuxer just outputs the discontinuiting (negative or positive),
> and it breaks, since codebases expect that demuxers which do this will be 
> properly
> marked with the DISCONT flag.
> 

> > Can these files with discontinuities be detected somehow from the headers?
> > If so then the probe function could be changed so they get the discontinuity
> > flag while valid files do not have the disadvantages from having it set
> 
> As far as I am aware, no, they cannot be detected by header. FLV is crappy 
> like that.

do we have some sample flv files that require this patchset / that have
discontinuites.

another thing i just realize now, why is this discontinuity issues coming up
now? flv support is very old. This should be a long standing issue 

thanks

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Take away the freedom of one citizen and you will be jailed, take away
the freedom of all citizens and you will be congratulated by your peers
in Parliament.


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

Re: [FFmpeg-devel] [PATCH v2] swscale/output: Altivec-optimize yuv2plane1_8

[Michael Niedermayer]

On Wed, Nov 21, 2018 at 07:19:45PM +0200, Lauri Kasanen wrote:
> On Wed, 21 Nov 2018 17:22:36 +0100
> Michael Niedermayer  wrote:
> 
> > the full fate tests must be run, many of these tests use swscale without
> > having "scale" in their name
> > and yes on lower end hardware 20min and longer is possible
> 
> I get failures on the baseline, without my patch. What is the procedure
> here? Is there a var to skip those tests, or?

procedure ?
First i try to convince you to attempt to fix some of these failures ;)
because well, everyone would benefit if they are fixed ...


> 
> First I ran with THREADS=3, baseline blew up in
> fate-h264-conformance-frext-hpcafl_bcrm_c
> 
> Then I ran without THREADS, it got further, but blew up in
> fate-rv20-1239

you can use make -k  to continue testing in presence of failures
this is not guranteed to run all tests, it may skip dependant tests
which dependent on a failing target.

Thanks

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

I am the wisest man alive, for I know one thing, and that is that I know
nothing. -- Socrates


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

Re: [FFmpeg-devel] [PATCH V3 5/7] avformat: add rc_max_rate to AVStream

[myp...@gmail.com]

On Thu, Nov 22, 2018 at 11:12 PM Hendrik Leppkes  wrote:
>
> On Thu, Nov 22, 2018 at 4:04 PM Jun Zhao  wrote:
> >
> > This field will be used in demuxer to expose the max bit rate, e,g
> > in MOV/MP4 esds box.
> >
> > Signed-off-by: Jun Zhao 
> > ---
> >  doc/APIchanges |3 +++
> >  libavformat/avformat.h |6 ++
> >  libavformat/version.h  |2 +-
> >  3 files changed, 10 insertions(+), 1 deletions(-)
> >
> > diff --git a/doc/APIchanges b/doc/APIchanges
> > index db1879e..0921da1 100644
> > --- a/doc/APIchanges
> > +++ b/doc/APIchanges
> > @@ -15,6 +15,9 @@ libavutil: 2017-10-21
> >
> >  API changes, most recent first:
> >
> > +2018-11-xx - xx - lavf 58.23.100 - avformat.h
> > +  Add rc_max_rate to AVStream
> > +
> >   8< - FFmpeg 4.1 was cut here  8< -
> >
> >  2018-10-27 - 718044dc19 - lavu 56.21.100 - pixdesc.h
> > diff --git a/libavformat/avformat.h b/libavformat/avformat.h
> > index fdaffa5..1732c24 100644
> > --- a/libavformat/avformat.h
> > +++ b/libavformat/avformat.h
> > @@ -938,6 +938,12 @@ typedef struct AVStream {
> >  AVRational avg_frame_rate;
> >
> >  /**
> > + * The max bitrate of the encoded data (in bits per second).
> > + * - decoding: set by libavformat
> > + */
> > +int64_t rc_max_rate;
> > +
>
>
> We have AV_PKT_DATA_CPB_PROPERTIES / AVCPBProperties side-data for that.
>
> - Hendrik

I suppose AV_PKT_DATA_CPB_PROPERTIES / AVCPBProperties side-data just
expose the data from  encoder like lib264, but now I need to expose
the max bit rate data from container like MOV/MP4, This is the reason
add a new field in AVStream.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] build inconsitencies on macOS

[Helmut K. C. Tessarek]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hello,

I'm doing the ffmpeg binaries for macOS, but I've noticed something
very strange today after my build:

Several libraries (AVFoundation, CoreVideo, CoreGraphics, QuartzCore,
AudioToolbox, VideoToolbox) are no longer linked (even though
videotoolbox and audiotoolbox are found during configure).

my config.log is here: https://evermeet.cx/pub/tmp/config.log

./ffmpeg:
/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version
400.9.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current
version 1252.50.4)
/System/Library/Frameworks/Accelerate.framework/Versions/A/Accelerate
(compatibility version 1.0.0, current version 4.0.0)
/System/Library/Frameworks/CoreText.framework/Versions/A/CoreText
(compatibility version 1.0.0, current version 1.0.0)

/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation 
(compatibility version 150.0.0, current version 1454.93.0)
/System/Library/Frameworks/Security.framework/Versions/A/Security
(compatibility version 1.0.0, current version 58286.70.9)

My last binary 92486-g8f875a90c4 looked like this :

./ffmpeg:
/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version
400.9.0)
/System/Library/Frameworks/Foundation.framework/Versions/C/Foundation
(compatibility version 300.0.0, current version 1454.93.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current
version 1252.50.4)

/System/Library/Frameworks/AVFoundation.framework/Versions/A/AVFoundation 
(compatibility version 1.0.0, current version 2.0.0)
/System/Library/Frameworks/CoreVideo.framework/Versions/A/CoreVideo
(compatibility version 1.2.0, current version 1.5.0)
/System/Library/Frameworks/CoreMedia.framework/Versions/A/CoreMedia
(compatibility version 1.0.0, current version 1.0.0)

/System/Library/Frameworks/CoreGraphics.framework/Versions/A/CoreGraphics 
(compatibility version 64.0.0, current version 1161.21.0)
/System/Library/Frameworks/OpenGL.framework/Versions/A/OpenGL
(compatibility version 1.0.0, current version 1.0.0)
/System/Library/Frameworks/Accelerate.framework/Versions/A/Accelerate
(compatibility version 1.0.0, current version 4.0.0)
/System/Library/Frameworks/QuartzCore.framework/Versions/A/QuartzCore
(compatibility version 1.0.1, current version 5.0.0)
/System/Library/Frameworks/AppKit.framework/Versions/C/AppKit
(compatibility version 45.0.0, current version 1561.60.100)

/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation 
(compatibility version 150.0.0, current version 1454.93.0)
/System/Library/Frameworks/Security.framework/Versions/A/Security
(compatibility version 1.0.0, current version 58286.70.9)

/System/Library/Frameworks/AudioToolbox.framework/Versions/A/AudioToolbox 
(compatibility version 1.0.0, current version 492.0.0)

/System/Library/Frameworks/VideoToolbox.framework/Versions/A/VideoToolbox 
(compatibility version 1.0.0, current version 1.0.0)

/System/Library/Frameworks/CoreServices.framework/Versions/A/CoreServices 
(compatibility version 1.0.0, current version 822.37.0)
/System/Library/Frameworks/CoreText.framework/Versions/A/CoreText
(compatibility version 1.0.0, current version 1.0.0)
/usr/lib/libobjc.A.dylib (compatibility version 1.0.0, current
version 228.0.0)

I'm really puzzled as to why this is happening. Did someone change the
configure script?
Also, all of a sudden /usr/lib/libobjc is no longer linked either.

Cheers,
  K. C.

- -- 
regards Helmut K. C. Tessarek  KeyID 0x172380A011EF4944
Key fingerprint = 8A55 70C1 BD85 D34E ADBC 386C 1723 80A0 11EF 4944

/*
   Thou shalt not follow the NULL pointer for chaos and madness
   await thee at its end.
*/
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEE191csiqpm8f5Ln9WvgmFNJ1E3QAFAlv3gj8ACgkQvgmFNJ1E
3QBuARAAgqZAYG0G+qU6NDVwns0Cn2QWERAtEzVkcaZTWaIzSyW45y30zw3wou/g
XuOLcHiDwe5U+7Ju1sltjqAWAMBZb0/5dyUWAXN/auK1daJvBsQdRrtyBMrddCBw
d2b2R+JXgypcGheCQL1U2wwj+Ew0p88pYD7Xog8XNeuIILq14eH95ymYsBXF35fq
EWrpYjLkGEmt5MudjxSNbtQNZ60wNtIQrlKAT2fbPFzgRcZRedqmAIAWG7hudq96
DpWCbDoTG8oMyZ4c+ef1yP+rCYqwh+d62Vl76xrWTnB3I70W74C7WDTGEVkEQEA0
Ucaa9ZxgPYptteLCog4rqi7nr+kniHzTXe0FR5ECczYFfwBB5ksMNi95wU+VXn43
BzuB5jSDA7R3Raf5L6prnfVou2niLOUZUB88J8Vivv+q/2yIL/CUKReEK5pMD9ga
y00VjSW+S/W/Ezkz9qQn+2036qioHAPK8K6vFbx9u0M/GNy12/qpPLrd9tW93x/M
kb+SbjI4PZPDJJe3l2ioUEaHT5aQZ90k4klwJy6fjk9zZKP5YF9nTsdFTBF6v5/B
o5CZXgKqM5tX4PNwbYgCquY3Q8wO+G7wt7z4mW4ZyS9KyscsdqKwr2X8CNQ3wo1q
jC5MuXe2QmKlfmwjWIiGCtGVdjKPEZwwxupI9SPkp5EH5fPodQ8=
=q50f
-END PGP SIGNATURE-
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] build inconsitencies on macOS

[James Almer]

On 11/23/2018 1:29 AM, Helmut K. C. Tessarek wrote:
> Hello,
> 
> I'm doing the ffmpeg binaries for macOS, but I've noticed something
> very strange today after my build:
> 
> Several libraries (AVFoundation, CoreVideo, CoreGraphics, QuartzCore,
> AudioToolbox, VideoToolbox) are no longer linked (even though
> videotoolbox and audiotoolbox are found during configure).
> 
> my config.log is here: https://evermeet.cx/pub/tmp/config.log
> 
> ./ffmpeg:
>   /usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version
> 400.9.0)
>   /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current
> version 1252.50.4)
>   /System/Library/Frameworks/Accelerate.framework/Versions/A/Accelerate
> (compatibility version 1.0.0, current version 4.0.0)
>   /System/Library/Frameworks/CoreText.framework/Versions/A/CoreText
> (compatibility version 1.0.0, current version 1.0.0)
>   
> /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation 
> (compatibility version 150.0.0, current version 1454.93.0)
>   /System/Library/Frameworks/Security.framework/Versions/A/Security
> (compatibility version 1.0.0, current version 58286.70.9)
> 
> My last binary 92486-g8f875a90c4 looked like this :
> 
> ./ffmpeg:
>   /usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version
> 400.9.0)
>   /System/Library/Frameworks/Foundation.framework/Versions/C/Foundation
> (compatibility version 300.0.0, current version 1454.93.0)
>   /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current
> version 1252.50.4)
>   
> /System/Library/Frameworks/AVFoundation.framework/Versions/A/AVFoundation 
> (compatibility version 1.0.0, current version 2.0.0)
>   /System/Library/Frameworks/CoreVideo.framework/Versions/A/CoreVideo
> (compatibility version 1.2.0, current version 1.5.0)
>   /System/Library/Frameworks/CoreMedia.framework/Versions/A/CoreMedia
> (compatibility version 1.0.0, current version 1.0.0)
>   
> /System/Library/Frameworks/CoreGraphics.framework/Versions/A/CoreGraphics 
> (compatibility version 64.0.0, current version 1161.21.0)
>   /System/Library/Frameworks/OpenGL.framework/Versions/A/OpenGL
> (compatibility version 1.0.0, current version 1.0.0)
>   /System/Library/Frameworks/Accelerate.framework/Versions/A/Accelerate
> (compatibility version 1.0.0, current version 4.0.0)
>   /System/Library/Frameworks/QuartzCore.framework/Versions/A/QuartzCore
> (compatibility version 1.0.1, current version 5.0.0)
>   /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit
> (compatibility version 45.0.0, current version 1561.60.100)
>   
> /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation 
> (compatibility version 150.0.0, current version 1454.93.0)
>   /System/Library/Frameworks/Security.framework/Versions/A/Security
> (compatibility version 1.0.0, current version 58286.70.9)
>   
> /System/Library/Frameworks/AudioToolbox.framework/Versions/A/AudioToolbox 
> (compatibility version 1.0.0, current version 492.0.0)
>   
> /System/Library/Frameworks/VideoToolbox.framework/Versions/A/VideoToolbox 
> (compatibility version 1.0.0, current version 1.0.0)
>   
> /System/Library/Frameworks/CoreServices.framework/Versions/A/CoreServices 
> (compatibility version 1.0.0, current version 822.37.0)
>   /System/Library/Frameworks/CoreText.framework/Versions/A/CoreText
> (compatibility version 1.0.0, current version 1.0.0)
>   /usr/lib/libobjc.A.dylib (compatibility version 1.0.0, current
> version 228.0.0)
> 
> I'm really puzzled as to why this is happening. Did someone change the
> configure script?
> Also, all of a sudden /usr/lib/libobjc is no longer linked either.
> 
> Cheers,
>   K. C.

Your config.log has a lot of errors like

/usr/include/hfs/hfs_format.h:794:2: error: unknown type name
'uuid_string_t'; did you mean 'io_string_t'?

when checking for Apple frameworks like AudioToolbox, AVFoundation,
VideoToolbox and more, so configure is evidently not enabling them.

What these errors mean or if they are consequence of a configure change
or some system/environment update in your Mac, i can't say.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] build inconsitencies on macOS

[Helmut K. C. Tessarek]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 2018-11-22 23:37, James Almer wrote:
> when checking for Apple frameworks like AudioToolbox,
> AVFoundation, VideoToolbox and more, so configure is evidently not
> enabling them.
> 
> What these errors mean or if they are consequence of a configure
> change or some system/environment update in your Mac, i can't say.

Hmm, this is really weird. Not quite sure why this is happening all of
a sudden. But you gave me a great pointer. I was only looking for
"toolbox" in the log file, thus I haven't seen these errors.

Cheers,
  K. C.

- -- 
regards Helmut K. C. Tessarek  KeyID 0x172380A011EF4944
Key fingerprint = 8A55 70C1 BD85 D34E ADBC 386C 1723 80A0 11EF 4944

/*
   Thou shalt not follow the NULL pointer for chaos and madness
   await thee at its end.
*/
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEE191csiqpm8f5Ln9WvgmFNJ1E3QAFAlv3pykACgkQvgmFNJ1E
3QCK4A/8C36KfnhtyDDdp9TyWfc0GPjg/6F+NL609rgA1Kz7ZpcPKKH9Bm4y6bBU
xmCTxAnDoqyNoBOjzVxGZlUX4UhqXfTFlVzriftks+UktevAGRAh1/rBlNpYUj5t
JJRdKQfWZg9tMiavOki961PelWitG1MrRfuphUyitpf2bmF/x7fyURmXQ1aB344h
cA9nluN2f5QdqyzP8nJMJ6FYxlQg/IT9UZWbxmTcR3KdRWJ5XXFkR3fdHv0kWNPx
zqNJLCxHb205hekyhnBYOejFTWo3J7PPL/12F/KUj8Hd7iBaF3hMbhNRgogKXljr
AEtpS6cdGMk15bzwDiGQVfDx6IUVRFuJXFyttntCSG4JM44Q2B+MyOHvtO0mJjR3
LO70wh7TQHVMduYEiz5EztW/oqIgzJ46TS+Me5IHN3HoIHSzio5J7x6AnCtM0C1W
E28NO/ZBAkM07x60/XlcncxA24UgHPYTUw3L1JzOfvC66IEW4OQ3L7A3D+IbyQ05
Z5mPaVtx1yBe73BO9XbRZS2vvf3+TZP42vNO4EZcQ9qAglCXS9GKe4WX/hF09Bem
3H6y+Nq6re5YqDaz9ghWkPMBpZvfSnt93yp3Kjrzr6ZJ6O4O/oUD6XotL8ONa+Es
LZNIYCs1RHBd+RCBJtnxAepbXqntuRefYFKLKiNVWC8KjInqEQg=
=fBZQ
-END PGP SIGNATURE-
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH V3 5/7] avformat: add rc_max_rate to AVStream

[Hendrik Leppkes]

On Fri, Nov 23, 2018 at 4:16 AM myp...@gmail.com  wrote:
>
> On Thu, Nov 22, 2018 at 11:12 PM Hendrik Leppkes  wrote:
> >
> > On Thu, Nov 22, 2018 at 4:04 PM Jun Zhao  wrote:
> > >
> > > This field will be used in demuxer to expose the max bit rate, e,g
> > > in MOV/MP4 esds box.
> > >
> > > Signed-off-by: Jun Zhao 
> > > ---
> > >  doc/APIchanges |3 +++
> > >  libavformat/avformat.h |6 ++
> > >  libavformat/version.h  |2 +-
> > >  3 files changed, 10 insertions(+), 1 deletions(-)
> > >
> > > diff --git a/doc/APIchanges b/doc/APIchanges
> > > index db1879e..0921da1 100644
> > > --- a/doc/APIchanges
> > > +++ b/doc/APIchanges
> > > @@ -15,6 +15,9 @@ libavutil: 2017-10-21
> > >
> > >  API changes, most recent first:
> > >
> > > +2018-11-xx - xx - lavf 58.23.100 - avformat.h
> > > +  Add rc_max_rate to AVStream
> > > +
> > >   8< - FFmpeg 4.1 was cut here  8< -
> > >
> > >  2018-10-27 - 718044dc19 - lavu 56.21.100 - pixdesc.h
> > > diff --git a/libavformat/avformat.h b/libavformat/avformat.h
> > > index fdaffa5..1732c24 100644
> > > --- a/libavformat/avformat.h
> > > +++ b/libavformat/avformat.h
> > > @@ -938,6 +938,12 @@ typedef struct AVStream {
> > >  AVRational avg_frame_rate;
> > >
> > >  /**
> > > + * The max bitrate of the encoded data (in bits per second).
> > > + * - decoding: set by libavformat
> > > + */
> > > +int64_t rc_max_rate;
> > > +
> >
> >
> > We have AV_PKT_DATA_CPB_PROPERTIES / AVCPBProperties side-data for that.
> >
> > - Hendrik
>
> I suppose AV_PKT_DATA_CPB_PROPERTIES / AVCPBProperties side-data just
> expose the data from  encoder like lib264, but now I need to expose
> the max bit rate data from container like MOV/MP4, This is the reason
> add a new field in AVStream.

The side-data can be used from either a demuxer or an encoder - one
describes the original stream, one the newly encoded stream. In fact
movenc already uses it to write this particular field to esds, so
movdec should use the same structure to read it.
See av_stream_new_side_data

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