[FFmpeg-devel] [PATCH] avformat/dashenc: reopen new http session for http_persistent

[Siyuan Huang]

Hello Chris Ribble

 

Looks you are working for http patch , 

Can you share a test script for it ?

 

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

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

[FFmpeg-devel] [PATCH] avformat/dashenc: reopen new http session for http_persistent

[Chris Ribble]

Fix ticket: 8693
Based on implementation in hlsenc.c

Signed-off-by: Chris Ribble 
---
 libavformat/dashenc.c | 67 ++-
 1 file changed, 53 insertions(+), 14 deletions(-)

diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c
index 00a37b175d..a45d9bc7d0 100644
--- a/libavformat/dashenc.c
+++ b/libavformat/dashenc.c
@@ -121,6 +121,7 @@ typedef struct OutputStream {
 const char *single_file_name;  /* file names selected for this particular 
stream */
 const char *init_seg_name;
 const char *media_seg_name;
+uint8_t *temp_buffer;
 
 char codec_str[100];
 int written_len;
@@ -239,12 +240,13 @@ static int dashenc_io_open(AVFormatContext *s, 
AVIOContext **pb, char *filename,
 return err;
 }
 
-static void dashenc_io_close(AVFormatContext *s, AVIOContext **pb, char 
*filename) {
+static int dashenc_io_close(AVFormatContext *s, AVIOContext **pb, char 
*filename) {
 DASHContext *c = s->priv_data;
 int http_base_proto = filename ? ff_is_http_proto(filename) : 0;
 
+int ret = 0;
 if (!*pb)
-return;
+return ret;
 
 if (!http_base_proto || !c->http_persistent) {
 ff_format_io_close(s, pb);
@@ -254,8 +256,10 @@ static void dashenc_io_close(AVFormatContext *s, 
AVIOContext **pb, char *filenam
 av_assert0(http_url_context);
 avio_flush(*pb);
 ffurl_shutdown(http_url_context, AVIO_FLAG_WRITE);
+ret = ff_http_get_shutdown_status(http_url_context);
 #endif
 }
+return ret;
 }
 
 static const char *get_format_str(SegmentType segment_type) {
@@ -453,33 +457,38 @@ static void set_codec_str(AVFormatContext *s, 
AVCodecParameters *par,
 
 static int flush_dynbuf(DASHContext *c, OutputStream *os, int *range_length)
 {
-uint8_t *buffer;
+AVFormatContext *ctx = os->ctx;
 
-if (!os->ctx->pb) {
+if (!ctx->pb) {
 return AVERROR(EINVAL);
 }
 
 // flush
-av_write_frame(os->ctx, NULL);
-avio_flush(os->ctx->pb);
+av_write_frame(ctx, NULL);
+avio_flush(ctx->pb);
 
 if (!c->single_file) {
 // write out to file
-*range_length = avio_close_dyn_buf(os->ctx->pb, );
-os->ctx->pb = NULL;
+*range_length = avio_close_dyn_buf(ctx->pb, >temp_buffer);
+ctx->pb = NULL;
 if (os->out)
-avio_write(os->out, buffer + os->written_len, *range_length - 
os->written_len);
+avio_write(os->out, os->temp_buffer + os->written_len, 
*range_length - os->written_len);
 os->written_len = 0;
-av_free(buffer);
 
 // re-open buffer
-return avio_open_dyn_buf(>ctx->pb);
+return avio_open_dyn_buf(>pb);
 } else {
-*range_length = avio_tell(os->ctx->pb) - os->pos;
+*range_length = avio_tell(ctx->pb) - os->pos;
 return 0;
 }
 }
 
+static void reflush_dynbuf(OutputStream *os, int *range_length)
+{
+// re-open buffer
+avio_write(os->out, os->temp_buffer, *range_length);;
+}
+
 static void set_http_options(AVDictionary **options, DASHContext *c)
 {
 if (c->method)
@@ -596,6 +605,7 @@ static int flush_init_segment(AVFormatContext *s, 
OutputStream *os)
 int ret, range_length;
 
 ret = flush_dynbuf(c, os, _length);
+av_freep(>temp_buffer);
 if (ret < 0)
 return ret;
 
@@ -642,6 +652,7 @@ static void dash_free(AVFormatContext *s)
 av_freep(>single_file_name);
 av_freep(>init_seg_name);
 av_freep(>media_seg_name);
+av_freep(>temp_buffer);
 }
 av_freep(>streams);
 
@@ -1241,7 +1252,18 @@ static int write_manifest(AVFormatContext *s, int final)
 
 avio_printf(out, "\n");
 avio_flush(out);
-dashenc_io_close(s, >mpd_out, temp_filename);
+ret = dashenc_io_close(s, >mpd_out, temp_filename);
+if (ret < 0) {
+av_log(s, AV_LOG_WARNING, "upload manifest failed, will retry with a 
new http session.\n");
+ff_format_io_close(s, >mpd_out);
+
+set_http_options(, c);
+dashenc_io_open(s, >mpd_out, temp_filename, );
+av_dict_free();
+
+dashenc_io_close(s, >mpd_out, temp_filename);
+return ret;
+}
 
 if (use_rename) {
 if ((ret = ff_rename(temp_filename, s->url, s)) < 0)
@@ -1939,7 +1961,21 @@ static int dash_flush(AVFormatContext *s, int final, int 
stream)
 if (c->single_file) {
 find_index_range(s, os->full_path, os->pos, _length);
 } else {
-dashenc_io_close(s, >out, os->temp_path);
+ret = dashenc_io_close(s, >out, os->temp_path);
+if (ret < 0) {
+AVDictionary *http_opts = NULL;
+
+av_log(s, AV_LOG_WARNING, "upload segment failed, will retry 
with a new http session.\n");
+ff_format_io_close(s, >out);
+
+set_http_options(_opts, c);
+ret = dashenc_io_open(s, >out, os->temp_path, _opts);
+av_dict_free(_opts);
+
+

Re: [FFmpeg-devel] [PATCH 1/2] avcodec: Add AV_CODEC_FLAG2_FAST_UNSAFE, move unsafe uses of FAST to it

[Michael Niedermayer]

On Mon, Jun 01, 2020 at 02:30:20PM +0100, Kieran Kunhya wrote:
> On Mon, 1 Jun 2020 at 14:02, Anton Khirnov  wrote:
> 
> > Quoting Paul B Mahol (2020-05-29 18:46:18)
> > > I see no aggression at all here.
> >
> > Same here. People have disagreeing opinions and are expressing them.
> > That does not imply aggression or uncivility.
> >
> 
> There is no aggression here.

So. let me clarify this as it seems several people didnt notice it.

Calling a submitted feature a bug, is aggression.

A bug is unintended behavior. The user would turn this only on
when its intended

This thread started from me suggesting the change and asking about better 
suggestions
I suggest to add a AV_CODEC_FLAG2_FAST_UNSAFE and split the current
uses of the flag up between the 2

will submit a patch doing that unless i hear objections / a better
suggestion.

Zero replies 

Please, if you see an issue in a patch or suggestion in the future, 
explain that issue, write a clear argument.
Simply caling a feature a bug or adding your agreement below such
statement is not helpfull. Its even less helpfull than just saying
you are against it.

If you say you are against it i can count that, if you say its something
that it is not what would that tell me ? 

Thanks

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

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


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

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

Re: [FFmpeg-devel] [PATCH 1/4] avcodec/jpeg2000dec: clear pointer which become stale in get_ppt()

[Michael Niedermayer]

On Mon, Jun 01, 2020 at 12:10:54AM +0530, Gautam Ramakrishnan wrote:
> On Sun, May 31, 2020 at 7:21 PM Michael Niedermayer
>  wrote:
> >
> > Fixes: use after free
> > Fixes: 
> > 22484/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_JPEG2000_fuzzer-5671488765296640
> >
> > Found-by: continuous fuzzing process 
> > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> > Signed-off-by: Michael Niedermayer 
> > ---
> >  libavcodec/jpeg2000dec.c | 1 +
> >  1 file changed, 1 insertion(+)
> >
> > diff --git a/libavcodec/jpeg2000dec.c b/libavcodec/jpeg2000dec.c
> > index 6424ed..b7766459c4 100644
> > --- a/libavcodec/jpeg2000dec.c
> > +++ b/libavcodec/jpeg2000dec.c
> > @@ -928,6 +928,7 @@ static int get_ppt(Jpeg2000DecoderContext *s, int n)
> >  tile->packed_headers = new;
> >  } else
> >  return AVERROR(ENOMEM);
> > +memset(>packed_headers_stream, 0, 
> > sizeof(tile->packed_headers_stream));
> >  memcpy(tile->packed_headers + tile->packed_headers_size,
> > s->g.buffer, n - 3);
> >  tile->packed_headers_size += n - 3;
> > --
> > 2.17.1
> >
> > ___
> > ffmpeg-devel mailing list
> > ffmpeg-devel@ffmpeg.org
> > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> >
> > To unsubscribe, visit link above, or email
> > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
> 
> Looks good to me

will apply

thx

[...]
-- 
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
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [PATCH] fate: add adpcm_ima_ssi encoding test

[Michael Niedermayer]

On Sun, May 31, 2020 at 05:24:11AM +, Zane van Iperen wrote:
> Signed-off-by: Zane van Iperen 
> ---
>  tests/fate/acodec.mak  | 2 ++
>  tests/ref/acodec/adpcm-ima_ssi | 4 
>  2 files changed, 6 insertions(+)
>  create mode 100644 tests/ref/acodec/adpcm-ima_ssi

will apply

thx

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

While the State exists there can be no freedom; when there is freedom there
will be no State. -- Vladimir Lenin


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

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

Re: [FFmpeg-devel] [PATCH 3/4] avformat/mlvdec: fail reading a packet with 0 streams

[Michael Niedermayer]

On Sun, May 31, 2020 at 07:07:11PM -0300, James Almer wrote:
> On 5/31/2020 6:48 PM, Michael Niedermayer wrote:
> > On Sun, May 31, 2020 at 10:58:16AM -0300, James Almer wrote:
> >> On 5/31/2020 10:50 AM, Michael Niedermayer wrote:
> >>> Fixes: NULL pointer dereference
> >>> Fixes: 
> >>> 22604/clusterfuzz-testcase-minimized-ffmpeg_DEMUXER_fuzzer-5667739074297856.fuzz
> >>>
> >>> Found-by: continuous fuzzing process 
> >>> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> >>> Signed-off-by: Michael Niedermayer 
> >>> ---
> >>>  libavformat/mlvdec.c | 6 +-
> >>>  1 file changed, 5 insertions(+), 1 deletion(-)
> >>>
> >>> diff --git a/libavformat/mlvdec.c b/libavformat/mlvdec.c
> >>> index dae13cae53..03aed71024 100644
> >>> --- a/libavformat/mlvdec.c
> >>> +++ b/libavformat/mlvdec.c
> >>> @@ -393,10 +393,14 @@ static int read_packet(AVFormatContext *avctx, 
> >>> AVPacket *pkt)
> >>>  {
> >>>  MlvContext *mlv = avctx->priv_data;
> >>>  AVIOContext *pb;
> >>> -AVStream *st = avctx->streams[mlv->stream_index];
> >>> +AVStream *st;
> >>>  int index, ret;
> >>>  unsigned int size, space;
> >>>  
> >>> +if (!avctx->nb_streams)
> >>> +return AVERROR_EOF;
> >>
> >> Shouldn't you abort during read_header() instead if no streams are ever
> >> allocated?
> > 
> > read_header() should fail if the haeder is invalid.
> > is there something which says that "no streams" is invalid ?
> > 
> > As it is the read_header() code contains a if()  which only make
> > a difference for a "no stream" case. Which gave me the feeling that
> > it wasnt intended to fail in that case
> 
> The checks i'm seeing are all considering video only, audio only, or
> both, like the very last check in the function where there's no last
> resort else that would cover a no streams case.

if (vst && ast)
A
else if (vst)
B
else if (ast)
C

if one didnt think of "no streams" this would be
if (vst && ast)
A
else if (vst)
B
else
C

if one wanted to reject "no streams" this would be

if (vst && ast)
A
else if (vst)
B
else if (ast)
C
else
FAIL

to me this looked like the intend was to support that

I have no preferrance between any of this, just wanted to not error
out on a path that seemed the author didnt want it to error ...


> 
> > but i can add the check for no streams in there where theres already
> > a check for that in read_header ...
> 
> Unless there's something in a file that could be signaled without
> streams (All the metadata strings in scan_file() look like they
> definitely apply to some video or audio stream), such a file seems odd
> to me, and if the end result will be just signaling EOF as soon as the
> first attempt at fetching a packet, then might as well just abort in
> read_header() and save the library caller further processing.
> 
> Maybe Peter Ross can comment. But in any case, no strong feelings about
> it, so apply whatever you think is best.

ok, ill wait for peter to reply then or in absence of a reply, next time
i remember ill apply something

thanks

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

Those who are best at talking, realize last or never when they are wrong.


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

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

Re: [FFmpeg-devel] [PATCH] ffmpeg:Accelerated hardware decode support on Jetson

[Philip Langdale]

On Mon, 1 Jun 2020 09:50:56 +
Amit Pandya  wrote:

> Hi all,
> 
> This patch can support hardware-accelerated decode in ffmpeg on
> Jetson platforms.

Hi Amit,

I appreciate you sending this in. People have asked about Jetson
support a few times.

Is there any plan to enable the normal nvdec/nvenc APIs on jetson?
There is support on 'normal' ARM systems.

More specifically to this change, we already have a v4l2m2m driver. Why
is this completely separate? Can it share code? Can it be written to
just conditionalise the parts that are different? What are those parts?

> ffmpeg application can use accelerated decode to read video files in
> the following elementary/container formats and dump them in YUV 420
> format: H.264, H.265, VP8, VP9. MPEG2, MPEG4 (NOTE: The ffmpeg
> package does not support MPEG4 container files).

What is the problem with mpeg4 containers? Is this the annex b thing?
if so, you need to enable the bitstream filter.

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

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

[FFmpeg-devel] [PATCH] added sei side data

[Daniel Loman]

Added seperate side data field to allow adding per packet side data
message to support MISB 604 encoding
---
 libavcodec/avpacket.c  |   1 +
 libavcodec/h264_metadata_bsf.c | 116 +++--
 libavcodec/packet.h|   5 ++
 3 files changed, 72 insertions(+), 50 deletions(-)

diff --git a/libavcodec/avpacket.c b/libavcodec/avpacket.c
index 033f2d8f26..a530dc6779 100644
--- a/libavcodec/avpacket.c
+++ b/libavcodec/avpacket.c
@@ -395,6 +395,7 @@ const char *av_packet_side_data_name(enum 
AVPacketSideDataType type)
 case AV_PKT_DATA_A53_CC: return "A53 Closed Captions";
 case AV_PKT_DATA_ENCRYPTION_INIT_INFO:   return "Encryption 
initialization data";
 case AV_PKT_DATA_ENCRYPTION_INFO:return "Encryption info";
+case AV_PKT_DATA_SEI_USER:   return "SEI unregistered 
data";
 case AV_PKT_DATA_AFD:return "Active Format 
Description data";
 case AV_PKT_DATA_PRFT:   return "Producer Reference 
Time";
 case AV_PKT_DATA_ICC_PROFILE:return "ICC Profile";
diff --git a/libavcodec/h264_metadata_bsf.c b/libavcodec/h264_metadata_bsf.c
index 99017653d0..e90b82793b 100644
--- a/libavcodec/h264_metadata_bsf.c
+++ b/libavcodec/h264_metadata_bsf.c
@@ -276,6 +276,65 @@ static int h264_metadata_update_sps(AVBSFContext *bsf,
 return 0;
 }
 
+static int write_sei_user_data(AVBSFContext *bsf, const uint8_t *data, int 
size)
+{
+H264MetadataContext *ctx = bsf->priv_data;
+CodedBitstreamFragment *au = >access_unit;
+int err = 0, i, j;
+
+H264RawSEIPayload payload = {
+.payload_type = H264_SEI_TYPE_USER_DATA_UNREGISTERED,
+};
+H264RawSEIUserDataUnregistered *udu =
+_data_unregistered;
+
+for (i = j = 0; j < 32 && data[i]; i++) {
+int c, v;
+c = data[i];
+if (c == '-') {
+continue;
+} else if (av_isxdigit(c)) {
+c = av_tolower(c);
+v = (c <= '9' ? c - '0' : c - 'a' + 10);
+} else {
+goto invalid_user_data;
+}
+if (i & 1)
+udu->uuid_iso_iec_11578[j / 2] |= v;
+else
+udu->uuid_iso_iec_11578[j / 2] = v << 4;
+++j;
+}
+if (j == 32 && data[i] == '+') {
+size_t len = size - i - 1;
+
+udu->data_ref = av_buffer_alloc(len + 1);
+if (!udu->data_ref) {
+err = AVERROR(ENOMEM);
+return err;
+}
+
+udu->data= udu->data_ref->data;
+udu->data_length = len + 1;
+memcpy(udu->data, data + i + 1, len + 1);
+
+err = ff_cbs_h264_add_sei_message(ctx->cbc, au, );
+if (err < 0) {
+av_log(bsf, AV_LOG_ERROR, "Failed to add user data SEI "
+   "message to access unit.\n");
+return err;
+}
+
+} else {
+invalid_user_data:
+av_log(bsf, AV_LOG_ERROR, "Invalid user data: "
+   "must be \"UUID+string\".\n");
+err = AVERROR(EINVAL);
+return err;
+}
+return err;
+}
+
 static int h264_metadata_update_side_data(AVBSFContext *bsf, AVPacket *pkt)
 {
 H264MetadataContext *ctx = bsf->priv_data;
@@ -412,56 +471,7 @@ static int h264_metadata_filter(AVBSFContext *bsf, 
AVPacket *pkt)
 // Only insert the SEI in access units containing SPSs, and also
 // unconditionally in the first access unit we ever see.
 if (ctx->sei_user_data && (has_sps || !ctx->done_first_au)) {
-H264RawSEIPayload payload = {
-.payload_type = H264_SEI_TYPE_USER_DATA_UNREGISTERED,
-};
-H264RawSEIUserDataUnregistered *udu =
-_data_unregistered;
-
-for (i = j = 0; j < 32 && ctx->sei_user_data[i]; i++) {
-int c, v;
-c = ctx->sei_user_data[i];
-if (c == '-') {
-continue;
-} else if (av_isxdigit(c)) {
-c = av_tolower(c);
-v = (c <= '9' ? c - '0' : c - 'a' + 10);
-} else {
-goto invalid_user_data;
-}
-if (j & 1)
-udu->uuid_iso_iec_11578[j / 2] |= v;
-else
-udu->uuid_iso_iec_11578[j / 2] = v << 4;
-++j;
-}
-if (j == 32 && ctx->sei_user_data[i] == '+') {
-size_t len = strlen(ctx->sei_user_data + i + 1);
-
-udu->data_ref = av_buffer_alloc(len + 1);
-if (!udu->data_ref) {
-err = AVERROR(ENOMEM);
-goto fail;
-}
-
-udu->data= udu->data_ref->data;
-udu->data_length = len + 1;
-memcpy(udu->data, ctx->sei_user_data + i + 1, len + 1);
-
-err = ff_cbs_h264_add_sei_message(ctx->cbc, au, );
-if (err < 0) {
-av_log(bsf, AV_LOG_ERROR, "Failed to add user data SEI "
-   "message to access 

Re: [FFmpeg-devel] [PoC][PATCH 1/2] avutil/buffer: add av_buffer_create2() to allow AVBufferRef to store complex structures

[James Almer]

On 6/1/2020 5:20 PM, Anton Khirnov wrote:
> Quoting James Almer (2020-06-01 18:35:39)
>> Signed-off-by: James Almer 
>> ---
>> This is an attempt at solving the annoying constrain of only supporting flat
>> arrays within any given AVBufferRef. It introduces a new function to create
>> buffers that accepts two new callback functions, one to allocate a new buffer
>> when a new writable reference needs to be created, and one to copy data to 
>> it.
> 
> This makes me rather uneasy.
> Is this constraint really so limiting that we need to get rid of it? In
> my experience the limitation actually tends to be beneficial - it
> serves as a powerful hint that maybe you're doing things in a way you
> shouldn't.
> 
> What use cases do you imagine this would allow that are not possible
> currently?

Seeing the way the video enc params was designed and the side data types
it replaces (qp table properties and qp table data as separate types)
made me think we're constrained by the current AVBuffer API, and new API
designs (especially those meant to be used as side data) being affected
by it.
Then there's some recent changes in CBS that Mark sent to the ML that in
essence are an attempt to work around this limitation, and would
hopefully be simplified by something like this.

Also, i've noticed the way the buffer pools in some of the hwcontext
implementations are used is very wtf, being both extremely fragile/hacky
and depending on undocumented behavior. I didn't test, but i suspect
that configuring with --enable-memory-poisoning will break a few of
them, like d3d11, as they depend on the buffer returned by the pool to
be in the exact same state as it was last time it was returned to the
pool, which is not how the pools are meant to work. But i also don't
think this patch here would help much in that regard.

> The video enc params thing has been implemented as a flat
> array without that much ugliness. It is a bit more convoluted than it
> could be with this change, but then again making it a flat memcpyable
> array also has advantages.
> 
> More generally, looking back at AVBuffer I have come to regret some
> design choices about it. It was a mistake to (ab)use it as a base for ALL
> refcounting everywhere. Instead, I should have added an AVRefcount for a
> thread safe counter+opaque+destructor and then used that as a base for
> anything that needed to be refcounted.
> The bottom line is that I believe AVBuffer should remain as close as
> possible to its original idea of "refcounted data buffer". If we want
> more complex refcounted structures, we should make them separate
> objects.

This could be a good alternative solution, yeah.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [RFC PATCH] libavcodec/jpeg2000_parser: Add jpeg2000 parser

[Carl Eugen Hoyos]

Am Mo., 1. Juni 2020 um 21:26 Uhr schrieb Gautam Ramakrishnan
:

> > > > can you add some test to fate for this ?
> > > > (doesnt need to be related to the tests you did, but can of course)
> > > > such a test would also make it easy for others to test the code on
> > > > less common hardware like big endian ...
> > > > This can also be very simple test if its not easy
> > > Small doubt, so the jpeg2000 stream to be parsed goes in the
> > > test-suite directory and the corresponding framecrc goes into the
> > > test/ref directory? Is my understanding right?
> >
> > ideally the teststream is generated by our muxers / encoders, that way
> > it doesnt need to be added to the fate suite
> > and it also teste more code as a side effect
> I did not understand this clearly. Do you mean the test should take some
> images already there in the test-suite, create a teststream, and run the test
> on that teststream?

This is possible but using -f lavfi -i testsr2 as input may be simpler.

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

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

Re: [FFmpeg-devel] [PoC][PATCH 1/2] avutil/buffer: add av_buffer_create2() to allow AVBufferRef to store complex structures

[Anton Khirnov]

Quoting James Almer (2020-06-01 18:35:39)
> Signed-off-by: James Almer 
> ---
> This is an attempt at solving the annoying constrain of only supporting flat
> arrays within any given AVBufferRef. It introduces a new function to create
> buffers that accepts two new callback functions, one to allocate a new buffer
> when a new writable reference needs to be created, and one to copy data to it.

This makes me rather uneasy.
Is this constraint really so limiting that we need to get rid of it? In
my experience the limitation actually tends to be beneficial - it
serves as a powerful hint that maybe you're doing things in a way you
shouldn't.

What use cases do you imagine this would allow that are not possible
currently? The video enc params thing has been implemented as a flat
array without that much ugliness. It is a bit more convoluted than it
could be with this change, but then again making it a flat memcpyable
array also has advantages.

More generally, looking back at AVBuffer I have come to regret some
design choices about it. It was a mistake to (ab)use it as a base for ALL
refcounting everywhere. Instead, I should have added an AVRefcount for a
thread safe counter+opaque+destructor and then used that as a base for
anything that needed to be refcounted.
The bottom line is that I believe AVBuffer should remain as close as
possible to its original idea of "refcounted data buffer". If we want
more complex refcounted structures, we should make them separate
objects.

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

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

Re: [FFmpeg-devel] [RFC PATCH] libavcodec/jpeg2000_parser: Add jpeg2000 parser

[Gautam Ramakrishnan]

On Fri, May 29, 2020 at 11:54 PM Michael Niedermayer
 wrote:
>
> On Fri, May 29, 2020 at 11:23:20PM +0530, Gautam Ramakrishnan wrote:
> > On Fri, May 29, 2020 at 5:01 AM Michael Niedermayer
> >  wrote:
> > >
> > > On Fri, May 29, 2020 at 12:33:01AM +0530, gautamr...@gmail.com wrote:
> > > > From: Gautam Ramakrishnan 
> > > >
> > > > I have attempted to write a JPEG2000 Parser. Have tested
> > > > by generating a file containing 14 frames, as mentioned
> > > > by Micheal. Have also tried testing with various packet
> > > > sizes by setting -frame_size option. Need feedback on the
> > > > code and on further testing.
> > > > ---
> > > >  libavcodec/Makefile  |   1 +
> > > >  libavcodec/jpeg2000_parser.c | 190 +++
> > > >  libavcodec/parsers.c |   1 +
> > > >  3 files changed, 192 insertions(+)
> > > >  create mode 100644 libavcodec/jpeg2000_parser.c
> > >
> > > can you add some test to fate for this ?
> > > (doesnt need to be related to the tests you did, but can of course)
> > > such a test would also make it easy for others to test the code on
> > > less common hardware like big endian ...
> > > This can also be very simple test if its not easy
> > Small doubt, so the jpeg2000 stream to be parsed goes in the
> > test-suite directory and the corresponding framecrc goes into the
> > test/ref directory? Is my understanding right?
>
> ideally the teststream is generated by our muxers / encoders, that way
> it doesnt need to be added to the fate suite
> and it also teste more code as a side effect
I did not understand this clearly. Do you mean the test should take some
images already there in the test-suite, create a teststream, and run the test
on that teststream?
>
> thx
>
> [...]
> --
> 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.
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".


https://trac.ffmpeg.org/wiki/FATE/AddingATest
Is this what I should be looking at?
-- 
-
Gautam |
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [PATCH v2] avcodec/h264_parser: Try to avoid (un)referencing

[James Almer]

On 6/1/2020 6:49 AM, Anton Khirnov wrote:
> Quoting Andreas Rheinhardt (2020-05-29 18:31:57)
>> When a slice is encountered, the H.264 parser up until now always
>> unreferenced and reset the currently active PPS; immediately
>> afterwards, the currently active PPS is set again which includes
>> referencing it. Given that it is typical for the active parameter
>> sets to change only seldomly, most of the time the new active PPS will
>> be the old one. Therefore this commit checks for this and only
>> unreferences the PPS if it changed.
>>
>> Signed-off-by: Andreas Rheinhardt 
>> ---
>> New and much simplified version of [1]. This has been made possible by
>> 5e316096fa9ba4493d9dbb48847ad8e0b0e188c3.
>>
>> [1]: https://ffmpeg.org/pipermail/ffmpeg-devel/2019-August/248374.html
>>
>>  libavcodec/h264_parser.c | 2 ++
>>  1 file changed, 2 insertions(+)
> 
> I've been considering a utility function along the lines of:
> 
> int av_buffer_update(AVBufferRef **dst, AVBufferRef *src)
> {
> if ((*dst)->buffer == src->buffer)
> return 0;
> av_buffer_unref(dst);
> *dst = av_buffer_ref(src);
> return 1;
> }
> 
> which would help avoid unnecessary unrefs+refs in such cases. Thoughts?

I'd call it av_buffer_replace() instead, and i think you could reuse the
buffer_replace() function already in buffer.c for this.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [PATCH 2/3] avcodec/v4l2_m2m_enc: Avoid ;;

[Andriy Gelman]

On Mon, 01. Jun 13:32, Andreas Rheinhardt wrote:
> Inside a function, the second ; in a double ;; is a null statement, but
> outside of functions a double ;; is simply invalid C that compilers
> happen to accept. v4l2_m2m_enc.c contained several ;; as a result of
> macro-expansion. So change the underlying macro so that it doesn't
> happen any longer.
> 
> This fixes warnings when compiling with -pedantic: "ISO C does not allow
> extra ‘;’ outside of a function".
> 
> Signed-off-by: Andreas Rheinhardt 
> ---
>  libavcodec/v4l2_m2m_enc.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/libavcodec/v4l2_m2m_enc.c b/libavcodec/v4l2_m2m_enc.c
> index a21a7b6c65..32321f392f 100644
> --- a/libavcodec/v4l2_m2m_enc.c
> +++ b/libavcodec/v4l2_m2m_enc.c
> @@ -417,7 +417,7 @@ static const AVCodecDefault v4l2_m2m_defaults[] = {
>  .defaults   = v4l2_m2m_defaults, \
>  .capabilities   = AV_CODEC_CAP_HARDWARE | AV_CODEC_CAP_DELAY, \
>  .wrapper_name   = "v4l2m2m", \
> -};
> +}
>  
>  M2MENC(mpeg4,"MPEG4", mpeg4_options, AV_CODEC_ID_MPEG4);
>  M2MENC(h263, "H.263", options,   AV_CODEC_ID_H263);
> -- 
> 2.20.1
> 

lgtm

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

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

Re: [FFmpeg-devel] [PATCH] fftools/ffmpeg: update text requesting samples

[Andriy Gelman]

On Sun, 31. May 19:16, Marton Balint wrote:
> 
> 
> On Fri, 29 May 2020, Andriy Gelman wrote:
> 
> > On Sun, 10. May 15:01, Andriy Gelman wrote:
> > > From: Andriy Gelman 
> > > 
> > > Signed-off-by: Andriy Gelman 
> > > ---
> > > 
> > > Same as commit d1e52e396b8aa778bd8d12bf25864beca0937d0a
> > > 
> > >  doc/developer.texi | 2 +-
> > >  fftools/cmdutils.c | 2 +-
> > >  fftools/ffmpeg.c   | 2 +-
> > >  3 files changed, 3 insertions(+), 3 deletions(-)
> > > 
> > > diff --git a/doc/developer.texi b/doc/developer.texi
> > > index 51e7299b1d..b33cab0fc7 100644
> > > --- a/doc/developer.texi
> > > +++ b/doc/developer.texi
> > > @@ -625,7 +625,7 @@ If the patch fixes a bug, did you provide a verbose 
> > > analysis of the bug?
> > >  If the patch fixes a bug, did you provide enough information, including
> > >  a sample, so the bug can be reproduced and the fix can be verified?
> > >  Note please do not attach samples >100k to mails but rather provide a
> > > -URL, you can upload to ftp://upload.ffmpeg.org.
> > > +URL, you can upload to @url{https://streams.videolan.org/upload/}.
> > > 
> > >  @item
> > >  Did you provide a verbose summary about what the patch does change?
> > > diff --git a/fftools/cmdutils.c b/fftools/cmdutils.c
> > > index 7f5a5ca664..072589e358 100644
> > > --- a/fftools/cmdutils.c
> > > +++ b/fftools/cmdutils.c
> > > @@ -2217,7 +2217,7 @@ double get_rotation(AVStream *st)
> > >  if (fabs(theta - 90*round(theta/90)) > 2)
> > >  av_log(NULL, AV_LOG_WARNING, "Odd rotation angle.\n"
> > > "If you want to help, upload a sample "
> > > -   "of this file to ftp://upload.ffmpeg.org/incoming/ "
> > > +   "of this file to https://streams.videolan.org/upload/ "
> > > "and contact the ffmpeg-devel mailing list. 
> > > (ffmpeg-devel@ffmpeg.org)");
> > > 
> > >  return theta;
> > > diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
> > > index f697460a30..c86b413f73 100644
> > > --- a/fftools/ffmpeg.c
> > > +++ b/fftools/ffmpeg.c
> > > @@ -2370,7 +2370,7 @@ static int decode_video(InputStream *ist, AVPacket 
> > > *pkt, int *got_output, int64_
> > >  av_log(ist->dec_ctx, AV_LOG_WARNING,
> > > "video_delay is larger in decoder than demuxer %d > 
> > > %d.\n"
> > > "If you want to help, upload a sample "
> > > -   "of this file to ftp://upload.ffmpeg.org/incoming/ "
> > > +   "of this file to https://streams.videolan.org/upload/ 
> > > "
> > > "and contact the ffmpeg-devel mailing list. 
> > > (ffmpeg-devel@ffmpeg.org)\n",
> > > ist->dec_ctx->has_b_frames,
> > > ist->st->codecpar->video_delay);
> > 
> > ping
> 
> LGTM, thanks.
> 

Thanks, applied.

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

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

Re: [FFmpeg-devel] [PATCH] compat/cuda/ptx2c: remove shell loop; fix BSD sed compat

[Timo Rothenpieler]

On 26.05.2020 19:42, rcombs wrote:

This improves build times dramatically, and fixes building on macOS
---
  compat/cuda/ptx2c.sh | 8 +++-
  1 file changed, 3 insertions(+), 5 deletions(-)

diff --git a/compat/cuda/ptx2c.sh b/compat/cuda/ptx2c.sh
index 0750e7a3b7..c41875a2d4 100755
--- a/compat/cuda/ptx2c.sh
+++ b/compat/cuda/ptx2c.sh
@@ -27,10 +27,8 @@ IN="$2"
  NAME="$(basename "$IN" | sed 's/\..*//')"
  
  printf "const char %s_ptx[] = \\" "$NAME" > "$OUT"

-while IFS= read -r LINE
-do
-printf "\n\t\"%s\\\n\"" "$(printf "%s" "$LINE" | sed -e 's/\r//g' -e 's/["\\]/\\&/g')" 
>> "$OUT"
-done < "$IN"
-printf ";\n" >> "$OUT"
+echo >> "$OUT"
+sed -e $'s/\r//g' -e 's/["\\]/\\&/g' -e $'s/^[[:space:]]*/\t"/' -e 's/$/\\n"/' < "$IN" 
>> "$OUT"
+echo ";" >> "$OUT"
  
  exit 0




Produces broken .ptx.c files:


CC  libavfilter/vf_overlay_cuda.ptx.o
libavfilter/vf_overlay_cuda.ptx.c:5:1: error: stray ‘\’ in program
5 | \n"
  | ^
libavfilter/vf_overlay_cuda.ptx.c:5:3: warning: missing terminating " character
5 | \n"
  |   ^
libavfilter/vf_overlay_cuda.ptx.c:5:3: error: missing terminating " character
libavfilter/vf_overlay_cuda.ptx.c:5:2: error: ‘n’ undeclared here (not in a 
function)
5 | \n"
  |  ^
libavfilter/vf_overlay_cuda.ptx.c:6:10: error: expected ‘,’ or ‘;’ before 
numeric constant
6 | .version 3.2\n"
  |  ^~~
libavfilter/vf_overlay_cuda.ptx.c:6:13: error: stray ‘\’ in program
6 | .version 3.2\n"
  | ^
libavfilter/vf_overlay_cuda.ptx.c:6:15: warning: missing terminating " character
6 | .version 3.2\n"
  |   ^
libavfilter/vf_overlay_cuda.ptx.c:6:15: error: missing terminating " character
libavfilter/vf_overlay_cuda.ptx.c:7:14: error: stray ‘\’ in program
7 | .target sm_30\n"
  |  ^
libavfilter/vf_overlay_cuda.ptx.c:7:16: warning: missing terminating " character
7 | .target sm_30\n"
  |^
libavfilter/vf_overlay_cuda.ptx.c:7:16: error: missing terminating " character
libavfilter/vf_overlay_cuda.ptx.c:8:17: error: stray ‘\’ in program
8 | .address_size 64\n"
  | ^
libavfilter/vf_overlay_cuda.ptx.c:8:19: warning: missing terminating " character
8 | .address_size 64\n"
  |   ^
libavfilter/vf_overlay_cuda.ptx.c:8:19: error: missing terminating " character
libavfilter/vf_overlay_cuda.ptx.c:9:1: error: stray ‘\’ in program
9 | \n"
  | ^
libavfilter/vf_overlay_cuda.ptx.c:9:3: warning: missing terminating " character
9 | \n"
  |   ^
libavfilter/vf_overlay_cuda.ptx.c:9:3: error: missing terminating " character
libavfilter/vf_overlay_cuda.ptx.c:11:1: error: stray ‘\’ in program
   11 | \n"
  | ^


And a lot more of the same.

The generated .ptx.c file also looks horribly garbled up all over.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

[FFmpeg-devel] [PATCH] lavc/nvenc: disable FMO unconditionally...

[Pavel Koshevoy]

because ff_h264_decode_picture_parameter_set doesn't support FMO
---
 libavcodec/nvenc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavcodec/nvenc.c b/libavcodec/nvenc.c
index cb33f9..c21c6dc567 100644
--- a/libavcodec/nvenc.c
+++ b/libavcodec/nvenc.c
@@ -997,12 +997,12 @@ static av_cold int nvenc_setup_h264_config(AVCodecContext 
*avctx)
 }
 
 h264->outputPictureTimingSEI = 1;
+h264->fmoMode = NV_ENC_H264_FMO_DISABLE;
 
 if (cc->rcParams.rateControlMode == NV_ENC_PARAMS_RC_CBR_LOWDELAY_HQ ||
 cc->rcParams.rateControlMode == NV_ENC_PARAMS_RC_CBR_HQ ||
 cc->rcParams.rateControlMode == NV_ENC_PARAMS_RC_VBR_HQ) {
 h264->adaptiveTransformMode = NV_ENC_H264_ADAPTIVE_TRANSFORM_ENABLE;
-h264->fmoMode = NV_ENC_H264_FMO_DISABLE;
 }
 
 if (ctx->flags & NVENC_LOSSLESS) {
-- 
2.26.2

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

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

Re: [FFmpeg-devel] [PATCH] avcodec/nvenc: set average and max bitrate values to zero when in CQ rate control mode

[Timo Rothenpieler]

applied and backported to 4.2, thanks
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [PATCH] [PATCH] POWER8 VSX vectorization libswscale/input.c Track ticket 5570

[Pestov Vyacheslav]

Hi!

There is a patch that I sent you a couple of months ago to check. I did it for 
the platform bountysource.com. There is a reward for this task, but I can’t get 
it for quite some time, since the patch is in pending status. All tests were 
passed, and the correct operation of the functions was checked. I also sent my 
scripts for these tests. Please tell me how to close this task.

Issue from bountysource:

https://www.bountysource.com/issues/34315232-power8-vsx-vectorization-libswscale-input-c

Patch pending status:

https://patchwork.ffmpeg.org/project/ffmpeg/patch/1585056463-7934-1-git-send-email-pestov.vy...@yandex.ru/

Trac ticket:

https://trac.ffmpeg.org/ticket/5570



With best regards, Vyacheslav Pestov

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

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

Re: [FFmpeg-devel] [PoC][PATCH 2/2] avutil/video_enc_params: make use of the complex AVBufferRef allocator

[James Almer]

On 6/1/2020 2:17 PM, Andreas Rheinhardt wrote:
> James Almer:
>> Signed-off-by: James Almer 
>> ---
>> As mentioned in Patch 1/2, this is an example for the complex structure
>> handling in AVBufferRef.
>> It doesn't need to be applied, even if it could (Despite being public, it's 
>> new
>> enough that we can change it if we do it now).
>>
>>  libavutil/video_enc_params.c | 37 ++--
>>  libavutil/video_enc_params.h | 67 ++--
>>  2 files changed, 68 insertions(+), 36 deletions(-)
>>
>> diff --git a/libavutil/video_enc_params.c b/libavutil/video_enc_params.c
>> index c46c0f1dc6..9e64ad4d59 100644
>> --- a/libavutil/video_enc_params.c
>> +++ b/libavutil/video_enc_params.c
>> @@ -32,6 +32,9 @@ AVVideoEncParams *av_video_enc_params_alloc(enum 
>> AVVideoEncParamsType type,
>>  AVVideoEncParams *par;
>>  size_t size;
>>  
>> +// Ensure blocks is the last field in the struct
>> +av_assert0(offsetof(AVVideoEncParams, blocks) == sizeof(*par) - 
>> sizeof(AVVideoBlockParams*));
>> +
> This check only works if blocks is the last field in the struct and if
> there is no padding after blocks (e.g. if AVVideoEncParams contained any
> [u]int64_t, then one could run into this assert even when blocks were
> the last element (namely when one is on a 32bit system)).

There are no [u]int64_t fields in the struct, but i guess it's better to
be safe than sorry, so a notice in the header might just be enough instead.
It's after all aimed at libav* developers rather than users.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

[FFmpeg-devel] [PATCH 1/4 v2] avutil/buffer: change public function and struct size parameter types to size_t

[James Almer]

Signed-off-by: James Almer 
---
No changes since v1.

 doc/APIchanges  |  4 
 libavutil/buffer.c  | 25 +
 libavutil/buffer.h  | 31 +++
 libavutil/buffer_internal.h | 13 +
 libavutil/version.h |  3 +++
 5 files changed, 76 insertions(+)

diff --git a/doc/APIchanges b/doc/APIchanges
index fb5534b5f5..9de23744c0 100644
--- a/doc/APIchanges
+++ b/doc/APIchanges
@@ -15,6 +15,10 @@ libavutil: 2017-10-21
 
 API changes, most recent first:
 
+2020-06-xx - xx
+  Change AVBufferRef related function and struct size parameter and fields
+  type to size_t at next major bump.
+
 2020-xx-xx - xx - lavc 58.88.100 - avcodec.h codec.h
   Move AVCodec-related public API to new header codec.h.
 
diff --git a/libavutil/buffer.c b/libavutil/buffer.c
index 6d9cb7428e..0a29430381 100644
--- a/libavutil/buffer.c
+++ b/libavutil/buffer.c
@@ -26,7 +26,11 @@
 #include "mem.h"
 #include "thread.h"
 
+#if FF_API_BUFFER_SIZE_T
 AVBufferRef *av_buffer_create(uint8_t *data, int size,
+#else
+AVBufferRef *av_buffer_create(uint8_t *data, size_t size,
+#endif
   void (*free)(void *opaque, uint8_t *data),
   void *opaque, int flags)
 {
@@ -65,7 +69,11 @@ void av_buffer_default_free(void *opaque, uint8_t *data)
 av_free(data);
 }
 
+#if FF_API_BUFFER_SIZE_T
 AVBufferRef *av_buffer_alloc(int size)
+#else
+AVBufferRef *av_buffer_alloc(size_t size)
+#endif
 {
 AVBufferRef *ret = NULL;
 uint8_t*data = NULL;
@@ -81,7 +89,11 @@ AVBufferRef *av_buffer_alloc(int size)
 return ret;
 }
 
+#if FF_API_BUFFER_SIZE_T
 AVBufferRef *av_buffer_allocz(int size)
+#else
+AVBufferRef *av_buffer_allocz(size_t size)
+#endif
 {
 AVBufferRef *ret = av_buffer_alloc(size);
 if (!ret)
@@ -167,7 +179,11 @@ int av_buffer_make_writable(AVBufferRef **pbuf)
 return 0;
 }
 
+#if FF_API_BUFFER_SIZE_T
 int av_buffer_realloc(AVBufferRef **pbuf, int size)
+#else
+int av_buffer_realloc(AVBufferRef **pbuf, size_t size)
+#endif
 {
 AVBufferRef *buf = *pbuf;
 uint8_t *tmp;
@@ -216,8 +232,13 @@ int av_buffer_realloc(AVBufferRef **pbuf, int size)
 return 0;
 }
 
+#if FF_API_BUFFER_SIZE_T
 AVBufferPool *av_buffer_pool_init2(int size, void *opaque,
AVBufferRef* (*alloc)(void *opaque, int 
size),
+#else
+AVBufferPool *av_buffer_pool_init2(size_t size, void *opaque,
+   AVBufferRef* (*alloc)(void *opaque, size_t 
size),
+#endif
void (*pool_free)(void *opaque))
 {
 AVBufferPool *pool = av_mallocz(sizeof(*pool));
@@ -236,7 +257,11 @@ AVBufferPool *av_buffer_pool_init2(int size, void *opaque,
 return pool;
 }
 
+#if FF_API_BUFFER_SIZE_T
 AVBufferPool *av_buffer_pool_init(int size, AVBufferRef* (*alloc)(int size))
+#else
+AVBufferPool *av_buffer_pool_init(size_t size, AVBufferRef* (*alloc)(size_t 
size))
+#endif
 {
 AVBufferPool *pool = av_mallocz(sizeof(*pool));
 if (!pool)
diff --git a/libavutil/buffer.h b/libavutil/buffer.h
index e0f94314f4..547c376439 100644
--- a/libavutil/buffer.h
+++ b/libavutil/buffer.h
@@ -27,6 +27,8 @@
 
 #include 
 
+#include "version.h"
+
 /**
  * @defgroup lavu_buffer AVBuffer
  * @ingroup lavu_data
@@ -90,7 +92,11 @@ typedef struct AVBufferRef {
 /**
  * Size of data in bytes.
  */
+#if FF_API_BUFFER_SIZE_T
 int  size;
+#else
+size_t   size;
+#endif
 } AVBufferRef;
 
 /**
@@ -98,13 +104,21 @@ typedef struct AVBufferRef {
  *
  * @return an AVBufferRef of given size or NULL when out of memory
  */
+#if FF_API_BUFFER_SIZE_T
 AVBufferRef *av_buffer_alloc(int size);
+#else
+AVBufferRef *av_buffer_alloc(size_t size);
+#endif
 
 /**
  * Same as av_buffer_alloc(), except the returned buffer will be initialized
  * to zero.
  */
+#if FF_API_BUFFER_SIZE_T
 AVBufferRef *av_buffer_allocz(int size);
+#else
+AVBufferRef *av_buffer_alloc(size_t size);
+#endif
 
 /**
  * Always treat the buffer as read-only, even when it has only one
@@ -127,7 +141,11 @@ AVBufferRef *av_buffer_allocz(int size);
  *
  * @return an AVBufferRef referring to data on success, NULL on failure.
  */
+#if FF_API_BUFFER_SIZE_T
 AVBufferRef *av_buffer_create(uint8_t *data, int size,
+#else
+AVBufferRef *av_buffer_create(uint8_t *data, size_t size,
+#endif
   void (*free)(void *opaque, uint8_t *data),
   void *opaque, int flags);
 
@@ -195,7 +213,11 @@ int av_buffer_make_writable(AVBufferRef **buf);
  * reference to it (i.e. the one passed to this function). In all other cases
  * a new buffer is allocated and the data is copied.
  */
+#if FF_API_BUFFER_SIZE_T
 int av_buffer_realloc(AVBufferRef **buf, int size);
+#else
+int av_buffer_realloc(AVBufferRef **buf, size_t size);
+#endif
 
 /**
  * @}
@@ -246,7 +268,11 @@ typedef struct AVBufferPool AVBufferPool;
  * (av_buffer_alloc()).
  * 

[FFmpeg-devel] [PATCH 3/4] avcodec/packet: change side data related public function and struct size types to size_t

[James Almer]

av_packet_add_side_data() already defines size as a size_t, so this makes it
consistent across all side data functions.

Signed-off-by: James Almer 
---
I could either add ifdeffery to every size argument used in
av_packet_get_side_data() calls within the libraries, add an internal typedef
that goes int -> size_t depending on FF_API_BUFFER_SIZE_T and use that, or just
not bother with them right now and change them after the bump in the same
commit that removes FF_API_BUFFER_SIZE_T.

In this patch i went the ifdef route for ff_side_data_set_encoder_stats() and
ff_side_data_set_prft().

 doc/APIchanges|  4 ++--
 libavcodec/avpacket.c | 28 
 libavcodec/packet.h   |  4 
 3 files changed, 34 insertions(+), 2 deletions(-)

diff --git a/doc/APIchanges b/doc/APIchanges
index dbf21c1d1e..d616594ff6 100644
--- a/doc/APIchanges
+++ b/doc/APIchanges
@@ -16,8 +16,8 @@ libavutil: 2017-10-21
 API changes, most recent first:
 
 2020-06-xx - xx
-  Change AVBufferRef and relevant AVFrameSideData function and struct size
-  parameter and fields type to size_t at next major bump.
+  Change AVBufferRef and relevant AVFrameSideData and AVPacketSideData 
function and
+  struct size parameter and fields type to size_t at next major bump.
 
 2020-xx-xx - xx - lavc 58.88.100 - avcodec.h codec.h
   Move AVCodec-related public API to new header codec.h.
diff --git a/libavcodec/avpacket.c b/libavcodec/avpacket.c
index 033f2d8f26..db9c947b62 100644
--- a/libavcodec/avpacket.c
+++ b/libavcodec/avpacket.c
@@ -329,12 +329,20 @@ int av_packet_add_side_data(AVPacket *pkt, enum 
AVPacketSideDataType type,
 
 
 uint8_t *av_packet_new_side_data(AVPacket *pkt, enum AVPacketSideDataType type,
+#if FF_API_BUFFER_SIZE_T
  int size)
+#else
+ size_t size)
+#endif
 {
 int ret;
 uint8_t *data;
 
+#if FF_API_BUFFER_SIZE_T
 if ((unsigned)size > INT_MAX - AV_INPUT_BUFFER_PADDING_SIZE)
+#else
+if (size > SIZE_MAX - AV_INPUT_BUFFER_PADDING_SIZE)
+#endif
 return NULL;
 data = av_mallocz(size + AV_INPUT_BUFFER_PADDING_SIZE);
 if (!data)
@@ -350,7 +358,11 @@ uint8_t *av_packet_new_side_data(AVPacket *pkt, enum 
AVPacketSideDataType type,
 }
 
 uint8_t *av_packet_get_side_data(const AVPacket *pkt, enum 
AVPacketSideDataType type,
+#if FF_API_BUFFER_SIZE_T
  int *size)
+#else
+ size_t *size)
+#endif
 {
 int i;
 
@@ -552,7 +564,11 @@ int av_packet_unpack_dictionary(const uint8_t *data, int 
size, AVDictionary **di
 }
 
 int av_packet_shrink_side_data(AVPacket *pkt, enum AVPacketSideDataType type,
+#if FF_API_BUFFER_SIZE_T
int size)
+#else
+   size_t size)
+#endif
 {
 int i;
 
@@ -587,7 +603,11 @@ FF_ENABLE_DEPRECATION_WARNINGS
 dst->side_data_elems  = 0;
 for (i = 0; i < src->side_data_elems; i++) {
 enum AVPacketSideDataType type = src->side_data[i].type;
+#if FF_API_BUFFER_SIZE_T
 int size  = src->side_data[i].size;
+#else
+size_t size   = src->side_data[i].size;
+#endif
 uint8_t *src_data = src->side_data[i].data;
 uint8_t *dst_data = av_packet_new_side_data(dst, type, size);
 
@@ -727,7 +747,11 @@ FF_ENABLE_DEPRECATION_WARNINGS
 int ff_side_data_set_encoder_stats(AVPacket *pkt, int quality, int64_t *error, 
int error_count, int pict_type)
 {
 uint8_t *side_data;
+#if FF_API_BUFFER_SIZE_T
 int side_data_size;
+#else
+size_t side_data_size;
+#endif
 int i;
 
 side_data = av_packet_get_side_data(pkt, AV_PKT_DATA_QUALITY_STATS, 
_data_size);
@@ -753,7 +777,11 @@ int ff_side_data_set_prft(AVPacket *pkt, int64_t timestamp)
 {
 AVProducerReferenceTime *prft;
 uint8_t *side_data;
+#if FF_API_BUFFER_SIZE_T
 int side_data_size;
+#else
+size_t side_data_size;
+#endif
 
 side_data = av_packet_get_side_data(pkt, AV_PKT_DATA_PRFT, 
_data_size);
 if (!side_data) {
diff --git a/libavcodec/packet.h b/libavcodec/packet.h
index 41485f4527..5b98ae812e 100644
--- a/libavcodec/packet.h
+++ b/libavcodec/packet.h
@@ -297,7 +297,11 @@ enum AVPacketSideDataType {
 
 typedef struct AVPacketSideData {
 uint8_t *data;
+#if FF_API_BUFFER_SIZE_T
 int  size;
+#else
+size_t   size;
+#endif
 enum AVPacketSideDataType type;
 } AVPacketSideData;
 
-- 
2.26.2

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

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

[FFmpeg-devel] [PATCH 4/4] avformat/utils: change stream side data related public functions and struct size types to size_t

[James Almer]

av_stream_add_side_data() already defines size as a size_t, so this makes it
consistent across all side data functions.

Signed-off-by: James Almer 
---
Same sitaution as Patch 3/4 but for av_stream_get_side_data().

 libavformat/avformat.h | 8 
 libavformat/utils.c| 8 
 2 files changed, 16 insertions(+)

diff --git a/libavformat/avformat.h b/libavformat/avformat.h
index 21c282a100..ae00c50a32 100644
--- a/libavformat/avformat.h
+++ b/libavformat/avformat.h
@@ -2183,7 +2183,11 @@ int av_stream_add_side_data(AVStream *st, enum 
AVPacketSideDataType type,
  * @return pointer to fresh allocated data or NULL otherwise
  */
 uint8_t *av_stream_new_side_data(AVStream *stream,
+#if FF_API_BUFFER_SIZE_T
  enum AVPacketSideDataType type, int size);
+#else
+ enum AVPacketSideDataType type, size_t size);
+#endif
 /**
  * Get side information from stream.
  *
@@ -2193,7 +2197,11 @@ uint8_t *av_stream_new_side_data(AVStream *stream,
  * @return pointer to data if present or NULL otherwise
  */
 uint8_t *av_stream_get_side_data(const AVStream *stream,
+#if FF_API_BUFFER_SIZE_T
  enum AVPacketSideDataType type, int *size);
+#else
+ enum AVPacketSideDataType type, size_t *size);
+#endif
 
 AVProgram *av_new_program(AVFormatContext *s, int id);
 
diff --git a/libavformat/utils.c b/libavformat/utils.c
index c9385318f6..03ddf955a2 100644
--- a/libavformat/utils.c
+++ b/libavformat/utils.c
@@ -5496,7 +5496,11 @@ int ff_generate_avci_extradata(AVStream *st)
 }
 
 uint8_t *av_stream_get_side_data(const AVStream *st,
+#if FF_API_BUFFER_SIZE_T
  enum AVPacketSideDataType type, int *size)
+#else
+ enum AVPacketSideDataType type, size_t *size)
+#endif
 {
 int i;
 
@@ -5549,7 +5553,11 @@ int av_stream_add_side_data(AVStream *st, enum 
AVPacketSideDataType type,
 }
 
 uint8_t *av_stream_new_side_data(AVStream *st, enum AVPacketSideDataType type,
+#if FF_API_BUFFER_SIZE_T
  int size)
+#else
+ size_t size)
+#endif
 {
 int ret;
 uint8_t *data = av_malloc(size);
-- 
2.26.2

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

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

[FFmpeg-devel] [PATCH 2/4 v2] avutil/frame: change av_frame_new_side_data() size parameter type to size_t

[James Almer]

Signed-off-by: James Almer 
---
No changes since v1.

 doc/APIchanges| 4 ++--
 libavutil/frame.c | 4 
 libavutil/frame.h | 8 
 3 files changed, 14 insertions(+), 2 deletions(-)

diff --git a/doc/APIchanges b/doc/APIchanges
index 9de23744c0..dbf21c1d1e 100644
--- a/doc/APIchanges
+++ b/doc/APIchanges
@@ -16,8 +16,8 @@ libavutil: 2017-10-21
 API changes, most recent first:
 
 2020-06-xx - xx
-  Change AVBufferRef related function and struct size parameter and fields
-  type to size_t at next major bump.
+  Change AVBufferRef and relevant AVFrameSideData function and struct size
+  parameter and fields type to size_t at next major bump.
 
 2020-xx-xx - xx - lavc 58.88.100 - avcodec.h codec.h
   Move AVCodec-related public API to new header codec.h.
diff --git a/libavutil/frame.c b/libavutil/frame.c
index 2e952edd29..489e46dd93 100644
--- a/libavutil/frame.c
+++ b/libavutil/frame.c
@@ -726,7 +726,11 @@ AVFrameSideData *av_frame_new_side_data_from_buf(AVFrame 
*frame,
 
 AVFrameSideData *av_frame_new_side_data(AVFrame *frame,
 enum AVFrameSideDataType type,
+#if FF_API_BUFFER_SIZE_T
 int size)
+#else
+size_t size)
+#endif
 {
 AVFrameSideData *ret;
 AVBufferRef *buf = av_buffer_alloc(size);
diff --git a/libavutil/frame.h b/libavutil/frame.h
index fc67db0f6c..fa4931edb8 100644
--- a/libavutil/frame.h
+++ b/libavutil/frame.h
@@ -206,7 +206,11 @@ enum AVActiveFormatDescription {
 typedef struct AVFrameSideData {
 enum AVFrameSideDataType type;
 uint8_t *data;
+#if FF_API_BUFFER_SIZE_T
 int  size;
+#else
+size_t   size;
+#endif
 AVDictionary *metadata;
 AVBufferRef *buf;
 } AVFrameSideData;
@@ -899,7 +903,11 @@ AVBufferRef *av_frame_get_plane_buffer(AVFrame *frame, int 
plane);
  */
 AVFrameSideData *av_frame_new_side_data(AVFrame *frame,
 enum AVFrameSideDataType type,
+#if FF_API_BUFFER_SIZE_T
 int size);
+#else
+size_t size);
+#endif
 
 /**
  * Add a new side data to a frame from an existing AVBufferRef
-- 
2.26.2

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

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

Re: [FFmpeg-devel] [PoC][PATCH 2/2] avutil/video_enc_params: make use of the complex AVBufferRef allocator

[Andreas Rheinhardt]

James Almer:
> Signed-off-by: James Almer 
> ---
> As mentioned in Patch 1/2, this is an example for the complex structure
> handling in AVBufferRef.
> It doesn't need to be applied, even if it could (Despite being public, it's 
> new
> enough that we can change it if we do it now).
> 
>  libavutil/video_enc_params.c | 37 ++--
>  libavutil/video_enc_params.h | 67 ++--
>  2 files changed, 68 insertions(+), 36 deletions(-)
> 
> diff --git a/libavutil/video_enc_params.c b/libavutil/video_enc_params.c
> index c46c0f1dc6..9e64ad4d59 100644
> --- a/libavutil/video_enc_params.c
> +++ b/libavutil/video_enc_params.c
> @@ -32,6 +32,9 @@ AVVideoEncParams *av_video_enc_params_alloc(enum 
> AVVideoEncParamsType type,
>  AVVideoEncParams *par;
>  size_t size;
>  
> +// Ensure blocks is the last field in the struct
> +av_assert0(offsetof(AVVideoEncParams, blocks) == sizeof(*par) - 
> sizeof(AVVideoBlockParams*));
> +
This check only works if blocks is the last field in the struct and if
there is no padding after blocks (e.g. if AVVideoEncParams contained any
[u]int64_t, then one could run into this assert even when blocks were
the last element (namely when one is on a 32bit system)).

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

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

[FFmpeg-devel] [PoC][PATCH 1/2] avutil/buffer: add av_buffer_create2() to allow AVBufferRef to store complex structures

[James Almer]

Signed-off-by: James Almer 
---
This is an attempt at solving the annoying constrain of only supporting flat
arrays within any given AVBufferRef. It introduces a new function to create
buffers that accepts two new callback functions, one to allocate a new buffer
when a new writable reference needs to be created, and one to copy data to it.

In the default scenario, the alloc and copy callbacks simply call
av_buffer_alloc() and memcpy() respectively, which is the current behavior of
treating the buffer as a flat array. In a more complex scenario, the real
benefit comes from the copy callback, which will let a custom implementation
set up the new buffer how it pleases, including handling pointers within the
complex struct it may be storing.

Patch 2/2 is an example implementation of this.

 libavutil/buffer.c  | 39 ++-
 libavutil/buffer.h  | 41 +
 libavutil/buffer_internal.h | 10 +
 3 files changed, 85 insertions(+), 5 deletions(-)

diff --git a/libavutil/buffer.c b/libavutil/buffer.c
index 7ff6adc2ec..b048e168e8 100644
--- a/libavutil/buffer.c
+++ b/libavutil/buffer.c
@@ -26,9 +26,12 @@
 #include "mem.h"
 #include "thread.h"
 
-AVBufferRef *av_buffer_create(uint8_t *data, int size,
-  void (*free)(void *opaque, uint8_t *data),
-  void *opaque, int flags)
+AVBufferRef *av_buffer_create2(uint8_t *data, int size,
+   AVBufferRef* (*alloc)(void *opaque, int size),
+   int (*copy)(void *opaque, AVBufferRef *dst,
+   const uint8_t *src, int size),
+   void (*free)(void *opaque, uint8_t *data),
+   void *opaque, int flags)
 {
 AVBufferRef *ref = NULL;
 AVBuffer*buf = NULL;
@@ -39,6 +42,8 @@ AVBufferRef *av_buffer_create(uint8_t *data, int size,
 
 buf->data = data;
 buf->size = size;
+buf->alloc= alloc ? alloc : av_buffer_default_alloc;
+buf->copy = copy ? copy : av_buffer_default_copy;
 buf->free = free ? free : av_buffer_default_free;
 buf->opaque   = opaque;
 
@@ -59,11 +64,29 @@ AVBufferRef *av_buffer_create(uint8_t *data, int size,
 return ref;
 }
 
+AVBufferRef *av_buffer_create(uint8_t *data, int size,
+  void (*free)(void *opaque, uint8_t *data),
+  void *opaque, int flags)
+{
+return av_buffer_create2(data, size, NULL, NULL, free, opaque, flags);
+}
+
 void av_buffer_default_free(void *opaque, uint8_t *data)
 {
 av_free(data);
 }
 
+AVBufferRef *av_buffer_default_alloc(void *opaque, int size)
+{
+return av_buffer_alloc(size);
+}
+
+int av_buffer_default_copy(void *opaque, AVBufferRef *dst, const uint8_t *src, 
int size)
+{
+memcpy(dst->data, src, size);
+return 0;
+}
+
 AVBufferRef *av_buffer_alloc(int size)
 {
 AVBufferRef *ret = NULL;
@@ -151,15 +174,21 @@ int av_buffer_get_ref_count(const AVBufferRef *buf)
 int av_buffer_make_writable(AVBufferRef **pbuf)
 {
 AVBufferRef *newbuf, *buf = *pbuf;
+AVBuffer *b = buf->buffer;
+int ret;
 
 if (av_buffer_is_writable(buf))
 return 0;
 
-newbuf = av_buffer_alloc(buf->size);
+newbuf = b->alloc(b->opaque, buf->size);
 if (!newbuf)
 return AVERROR(ENOMEM);
 
-memcpy(newbuf->data, buf->data, buf->size);
+ret = b->copy(b->opaque, newbuf, buf->data, buf->size);
+if (ret < 0) {
+av_buffer_unref();
+return ret;
+}
 
 buffer_replace(pbuf, );
 
diff --git a/libavutil/buffer.h b/libavutil/buffer.h
index e0f94314f4..375e04034a 100644
--- a/libavutil/buffer.h
+++ b/libavutil/buffer.h
@@ -131,6 +131,47 @@ AVBufferRef *av_buffer_create(uint8_t *data, int size,
   void (*free)(void *opaque, uint8_t *data),
   void *opaque, int flags);
 
+/**
+ * Create an AVBuffer from an existing array.
+ *
+ * If this function is successful, data is owned by the AVBuffer. The caller 
may
+ * only access data through the returned AVBufferRef and references derived 
from
+ * it.
+ * If this function fails, data is left untouched.
+ * @param data   data array
+ * @param size   size of data in bytes
+ * @param alloc  a callback for allocating a new buffer when a new writable
+ *   reference for this buffer is created
+ * @param copy   a callback for copying this buffer's data into the newly
+ *   allocated buffer by the alloc callback
+ * @param free   a callback for freeing this buffer's data
+ * @param opaque parameter to be got for processing or passed to 
alloc/copy/free
+ * @param flags  a combination of AV_BUFFER_FLAG_*
+ *
+ * @return an AVBufferRef referring to data on success, NULL on failure.
+ */
+AVBufferRef *av_buffer_create2(uint8_t *data, int size,
+   AVBufferRef* 

[FFmpeg-devel] [PoC][PATCH 2/2] avutil/video_enc_params: make use of the complex AVBufferRef allocator

[James Almer]

Signed-off-by: James Almer 
---
As mentioned in Patch 1/2, this is an example for the complex structure
handling in AVBufferRef.
It doesn't need to be applied, even if it could (Despite being public, it's new
enough that we can change it if we do it now).

 libavutil/video_enc_params.c | 37 ++--
 libavutil/video_enc_params.h | 67 ++--
 2 files changed, 68 insertions(+), 36 deletions(-)

diff --git a/libavutil/video_enc_params.c b/libavutil/video_enc_params.c
index c46c0f1dc6..9e64ad4d59 100644
--- a/libavutil/video_enc_params.c
+++ b/libavutil/video_enc_params.c
@@ -32,6 +32,9 @@ AVVideoEncParams *av_video_enc_params_alloc(enum 
AVVideoEncParamsType type,
 AVVideoEncParams *par;
 size_t size;
 
+// Ensure blocks is the last field in the struct
+av_assert0(offsetof(AVVideoEncParams, blocks) == sizeof(*par) - 
sizeof(AVVideoBlockParams*));
+
 size = sizeof(*par);
 if (nb_blocks > SIZE_MAX / sizeof(AVVideoBlockParams) ||
 nb_blocks * sizeof(AVVideoBlockParams) > SIZE_MAX - size)
@@ -45,7 +48,7 @@ AVVideoEncParams *av_video_enc_params_alloc(enum 
AVVideoEncParamsType type,
 par->type  = type;
 par->nb_blocks = nb_blocks;
 par->block_size= sizeof(AVVideoBlockParams);
-par->blocks_offset = sizeof(*par);
+par->blocks= par->nb_blocks ? (AVVideoBlockParams *)[1] : NULL;
 
 if (out_size)
 *out_size = size;
@@ -53,6 +56,35 @@ AVVideoEncParams *av_video_enc_params_alloc(enum 
AVVideoEncParamsType type,
 return par;
 }
 
+static int copy_callback(void *opaque, AVBufferRef *dst, const uint8_t *src, 
int size)
+{
+AVVideoEncParams *par_dst = (AVVideoEncParams *)dst->data;
+AVVideoEncParams *par_src = (AVVideoEncParams *)src;
+
+memcpy(par_dst, par_src, offsetof(AVVideoEncParams, blocks));
+par_dst->blocks = par_src->nb_blocks ? (AVVideoBlockParams *)_dst[1] : 
NULL;
+if (par_dst->blocks)
+memcpy(par_dst->blocks, par_src->blocks, par_src->nb_blocks * 
par_src->block_size);
+
+return 0;
+}
+
+static AVBufferRef *alloc_callback(void *opaque, int size)
+{
+AVBufferRef *buf;
+uint8_t *par;
+
+par = av_malloc(size);
+if (!par)
+return NULL;
+buf = av_buffer_create2(par, size, alloc_callback,
+copy_callback, NULL, NULL, 0);
+if (!buf)
+av_free(par);
+
+return buf;
+}
+
 AVVideoEncParams*
 av_video_enc_params_create_side_data(AVFrame *frame, enum AVVideoEncParamsType 
type,
  unsigned int nb_blocks)
@@ -64,7 +96,8 @@ av_video_enc_params_create_side_data(AVFrame *frame, enum 
AVVideoEncParamsType t
 par = av_video_enc_params_alloc(type, nb_blocks, );
 if (!par)
 return NULL;
-buf = av_buffer_create((uint8_t *)par, size, NULL, NULL, 0);
+buf = av_buffer_create2((uint8_t *)par, size, alloc_callback,
+copy_callback, NULL, NULL, 0);
 if (!buf) {
 av_freep();
 return NULL;
diff --git a/libavutil/video_enc_params.h b/libavutil/video_enc_params.h
index 43fa443154..b443dc50d9 100644
--- a/libavutil/video_enc_params.h
+++ b/libavutil/video_enc_params.h
@@ -57,6 +57,33 @@ enum AVVideoEncParamsType {
 AV_VIDEO_ENC_PARAMS_H264,
 };
 
+/**
+ * Data structure for storing block-level encoding information.
+ * It is allocated as a part of AVVideoEncParams and should be retrieved with
+ * av_video_enc_params_block().
+ *
+ * sizeof(AVVideoBlockParams) is not a part of the ABI and new fields may be
+ * added to it.
+ */
+typedef struct AVVideoBlockParams {
+/**
+ * Distance in luma pixels from the top-left corner of the visible frame
+ * to the top-left corner of the block.
+ * Can be negative if top/right padding is present on the coded frame.
+ */
+int src_x, src_y;
+/**
+ * Width and height of the block in luma pixels.
+ */
+int w, h;
+
+/**
+ * Difference between this block's final quantization parameter and the
+ * corresponding per-frame value.
+ */
+int32_t delta_qp;
+} AVVideoBlockParams;
+
 /**
  * Video encoding parameters for a given frame. This struct is allocated along
  * with an optional array of per-block AVVideoBlockParams descriptors.
@@ -67,15 +94,9 @@ typedef struct AVVideoEncParams {
  * Number of blocks in the array.
  *
  * May be 0, in which case no per-block information is present. In this 
case
- * the values of blocks_offset / block_size are unspecified and should not
- * be accessed.
+ * the value of block_size is unspecified and should not be accessed.
  */
 unsigned int nb_blocks;
-/**
- * Offset in bytes from the beginning of this structure at which the array
- * of blocks starts.
- */
-size_t blocks_offset;
 /*
  * Size of each block in bytes. May not match sizeof(AVVideoBlockParams).
  */
@@ -99,34 +120,13 @@ typedef struct AVVideoEncParams {
 

Re: [FFmpeg-devel] [PATCH] oggdec: add support for proper demuxing of chained Opus files and streams

[Michael Niedermayer]

On Tue, Apr 28, 2020 at 08:20:37PM +0200, Lynne wrote:
> Part of this patch is based on Paul B Mahol's patch from last year. 
> 
> This also allows for single-stream parameter/codec changes.
> 
> Must be applied on top of the latest version of other 3 patches I sent today.
> 

>  oggdec.c   |   45 +
>  oggdec.h   |1 +
>  oggparseopus.c |1 +
>  3 files changed, 27 insertions(+), 20 deletions(-)
> ce692abc11552b4c35772e57051378e0fd1ddece  
> 0001-oggdec-add-support-for-proper-demuxing-of-chained-Op.patch
> From 70dcc91b32c89cb580bf13f2c081fa8e74f226f9 Mon Sep 17 00:00:00 2001
> From: Lynne 
> Date: Tue, 28 Apr 2020 12:25:46 +0100
> Subject: [PATCH] oggdec: add support for proper demuxing of chained Opus files
>  and streams
> 
> Part of this patch is based on Paul B Mahol's patch from last year.
> 
> This also allows for single-stream parameter/codec changes.
> ---
>  libavformat/oggdec.c   | 45 +-
>  libavformat/oggdec.h   |  1 +
>  libavformat/oggparseopus.c |  1 +
>  3 files changed, 27 insertions(+), 20 deletions(-)

This causes out of array reads with
https://samples.ffmpeg.org/V-codecs/Theora/theora_testsuite_broken/multi2.ogg

==5283== Invalid read of size 8
==5283==at 0x640508: vorbis_packet (oggparsevorbis.c:413)
==5283==by 0x637546: ogg_packet (oggdec.c:589)
==5283==by 0x638392: ogg_read_packet (oggdec.c:824)
==5283==by 0x6A9211: ff_read_packet (utils.c:851)
==5283==by 0x6AC440: read_frame_internal (utils.c:1582)
==5283==by 0x6AD3F8: av_read_frame (utils.c:1784)
==5283==by 0x250B4B: get_input_packet (ffmpeg.c:4140)
==5283==by 0x251021: process_input (ffmpeg.c:4259)
==5283==by 0x253255: transcode_step (ffmpeg.c:4640)
==5283==by 0x2533D2: transcode (ffmpeg.c:4694)
==5283==by 0x253CE9: main (ffmpeg.c:4895)
==5283==  Address 0x1680af68 is 8 bytes after a block of size 32 in arena 
"client"
==5283== 


[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Those who are too smart to engage in politics are punished by being
governed by those who are dumber. -- Plato 


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

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

[FFmpeg-devel] [PATCH] avutil/buffer: separate public and internal flags inside AVBuffers

[James Almer]

It's better to not mix user provided flags and internal flags set by
AVBufferRef helper functions.

Signed-off-by: James Almer 
---
 libavutil/buffer.c  |  7 +++
 libavutil/buffer_internal.h | 13 +++--
 2 files changed, 10 insertions(+), 10 deletions(-)

diff --git a/libavutil/buffer.c b/libavutil/buffer.c
index 6d9cb7428e..7ff6adc2ec 100644
--- a/libavutil/buffer.c
+++ b/libavutil/buffer.c
@@ -44,8 +44,7 @@ AVBufferRef *av_buffer_create(uint8_t *data, int size,
 
 atomic_init(>refcount, 1);
 
-if (flags & AV_BUFFER_FLAG_READONLY)
-buf->flags |= BUFFER_FLAG_READONLY;
+buf->flags = flags;
 
 ref = av_mallocz(sizeof(*ref));
 if (!ref) {
@@ -185,14 +184,14 @@ int av_buffer_realloc(AVBufferRef **pbuf, int size)
 return AVERROR(ENOMEM);
 }
 
-buf->buffer->flags |= BUFFER_FLAG_REALLOCATABLE;
+buf->buffer->flags_internal |= BUFFER_FLAG_REALLOCATABLE;
 *pbuf = buf;
 
 return 0;
 } else if (buf->size == size)
 return 0;
 
-if (!(buf->buffer->flags & BUFFER_FLAG_REALLOCATABLE) ||
+if (!(buf->buffer->flags_internal & BUFFER_FLAG_REALLOCATABLE) ||
 !av_buffer_is_writable(buf) || buf->data != buf->buffer->data) {
 /* cannot realloc, allocate a new reallocable buffer and copy data */
 AVBufferRef *new = NULL;
diff --git a/libavutil/buffer_internal.h b/libavutil/buffer_internal.h
index 54b67047e5..70d2615a06 100644
--- a/libavutil/buffer_internal.h
+++ b/libavutil/buffer_internal.h
@@ -25,14 +25,10 @@
 #include "buffer.h"
 #include "thread.h"
 
-/**
- * The buffer is always treated as read-only.
- */
-#define BUFFER_FLAG_READONLY  (1 << 0)
 /**
  * The buffer was av_realloc()ed, so it is reallocatable.
  */
-#define BUFFER_FLAG_REALLOCATABLE (1 << 1)
+#define BUFFER_FLAG_REALLOCATABLE (1 << 0)
 
 struct AVBuffer {
 uint8_t *data; /**< data described by this buffer */
@@ -54,9 +50,14 @@ struct AVBuffer {
 void *opaque;
 
 /**
- * A combination of BUFFER_FLAG_*
+ * A combination of AV_BUFFER_FLAG_*
  */
 int flags;
+
+/**
+ * A combination of BUFFER_FLAG_*
+ */
+int flags_internal;
 };
 
 typedef struct BufferPoolEntry {
-- 
2.26.2

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

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

[FFmpeg-devel] [PATCH] avformat: Find a fallback probe decoder that will also match a forced decoder's codec.

[sfoss]

Prevent codecpar->codec_id from getting out of sync with the codec instantiated 
for probing.
---
 libavformat/utils.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavformat/utils.c b/libavformat/utils.c
index c9385318f6..b3d902c6b5 100644
--- a/libavformat/utils.c
+++ b/libavformat/utils.c
@@ -219,7 +219,7 @@ static const AVCodec *find_probe_decoder(AVFormatContext 
*s, const AVStream *st,
 const AVCodec *probe_codec = NULL;
 void *iter = NULL;
 while ((probe_codec = av_codec_iterate())) {
-if (probe_codec->id == codec_id &&
+if (probe_codec->id == codec->id &&
 av_codec_is_decoder(probe_codec) &&
 !(probe_codec->capabilities & (AV_CODEC_CAP_AVOID_PROBING 
| AV_CODEC_CAP_EXPERIMENTAL))) {
 return probe_codec;
-- 
2.27.0.rc2.251.g90737beb825-goog

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

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

[FFmpeg-devel] [PATCH] avcodec/ratecontrol: fix the integer overflow after long time run

[lance . lmwang]

From: Limin Wang 

Signed-off-by: Limin Wang 
---
 libavcodec/ratecontrol.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/libavcodec/ratecontrol.c b/libavcodec/ratecontrol.c
index 49d169b..6b77ccd 100644
--- a/libavcodec/ratecontrol.c
+++ b/libavcodec/ratecontrol.c
@@ -999,11 +999,11 @@ float ff_rate_estimate_qscale(MpegEncContext *s, int 
dry_run)
 
 if (s->avctx->debug & FF_DEBUG_RC) {
 av_log(s->avctx, AV_LOG_DEBUG,
-   "%c qp:%d<%2.1f<%d %d want:%d total:%d comp:%f st_q:%2.2f "
+   "%c qp:%d<%2.1f<%d %d want:%"PRId64" total:%"PRId64" comp:%f 
st_q:%2.2f "
"size:%d var:%"PRId64"/%"PRId64" br:%"PRId64" fps:%d\n",
av_get_picture_type_char(pict_type),
qmin, q, qmax, picture_number,
-   (int)wanted_bits / 1000, (int)s->total_bits / 1000,
+   wanted_bits / 1000, s->total_bits / 1000,
br_compensation, short_term_q, s->frame_bits,
pic->mb_var_sum, pic->mc_mb_var_sum,
s->bit_rate / 1000, (int)fps);
-- 
1.8.3.1

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

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

Re: [FFmpeg-devel] [PATCH 1/3] avutil/dict: av_realloc -> av_realloc_array()

[lance . lmwang]

On Sat, May 30, 2020 at 11:14:03AM -0300, James Almer wrote:
> On 5/30/2020 10:55 AM, lance.lmw...@gmail.com wrote:
> > On Sat, May 30, 2020 at 03:32:18PM +0200, Nicolas George wrote:
> >> lance.lmw...@gmail.com (12020-05-30):
> >>> From: Limin Wang 
> >>>
> >>> Signed-off-by: Limin Wang 
> >>> ---
> >>>  libavutil/dict.c | 4 ++--
> >>>  1 file changed, 2 insertions(+), 2 deletions(-)
> >>>
> >>> diff --git a/libavutil/dict.c b/libavutil/dict.c
> >>> index 0ea7138..a1107b1 100644
> >>> --- a/libavutil/dict.c
> >>> +++ b/libavutil/dict.c
> >>> @@ -103,8 +103,8 @@ int av_dict_set(AVDictionary **pm, const char *key, 
> >>> const char *value,
> >>>  av_free(tag->key);
> >>>  *tag = m->elems[--m->count];
> >>>  } else if (copy_value) {
> >>> -AVDictionaryEntry *tmp = av_realloc(m->elems,
> >>> -(m->count + 1) * 
> >>> sizeof(*m->elems));
> >>
> >>> +AVDictionaryEntry *tmp = av_realloc_array(m->elems,
> >>> +m->count + 1, 
> >>> sizeof(*m->elems));
> >>
> >> If you change something, make sure the alignment is correct.
> > I think it's cosmetic changes, so I didn't change the alignment for the 
> > first version.
> > If it's OK, I'll update with format changes also.
> 
> It makes sense to not bother with cosmetics when it reduces the amount
> of changed lines and a patch about functional changes, but in this case
> the line in question is going to be changed no matter what, so might as
> well just align it at the same time and save yourself an extra commit
> for it.

thanks, will follow it next time.

> 
> > 
> >>
> >>>  if (!tmp)
> >>>  goto err_out;
> >>>  m->elems = tmp;
> >>
> >> Regards,
> >>
> >> -- 
> >>   Nicolas George
> > 
> > 
> > 
> 
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

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

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

Re: [FFmpeg-devel] [PATCH] lavc/vaapi_encode_h265: add low_delay_b option for HEVC

[Fu, Linjie]

> From: ffmpeg-devel  On Behalf Of Fu,
> Linjie
> Sent: Tuesday, April 14, 2020 17:15
> To: FFmpeg development discussions and patches  de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH] lavc/vaapi_encode_h265: add
> low_delay_b option for HEVC
> 
> > From: ffmpeg-devel  On Behalf Of
> > Mark Thompson
> > Sent: Monday, April 13, 2020 20:20
> > To: ffmpeg-devel@ffmpeg.org
> > Subject: Re: [FFmpeg-devel] [PATCH] lavc/vaapi_encode_h265: add
> > low_delay_b option for HEVC
> >
> > On 13/04/2020 05:32, Linjie Fu wrote:
> > > Low delay B-frame is supported on ICL+ platform.
> > >
> > > For low power encoding, low_delay_b should be enabled by default.
> > >
> > > Low delay B:
> > >  > Video-Coding-HEVC-288.html>
> > >
> > > There is an on-going work in libva and media-driver to add querys
> > > support for low delay b, would add it once it's ready:
> > > https://github.com/intel/libva/pull/220
> > > https://github.com/intel/libva/pull/364
> > > https://github.com/intel/media-driver/issues/721
> > >
> > > Signed-off-by: Linjie Fu 
> > > ---
> > >  doc/encoders.texi  |  8 
> > >  libavcodec/vaapi_encode_h265.c | 19 +--
> > >  2 files changed, 25 insertions(+), 2 deletions(-)
> >
> > My understanding was that the only reason for this stuff existing was to
> work
> > around broken hardware which didn't support P frames.  Is this no longer
> > true?
> >
> > >
> > > diff --git a/doc/encoders.texi b/doc/encoders.texi
> > > index e23b6b3..b0812be 100644
> > > --- a/doc/encoders.texi
> > > +++ b/doc/encoders.texi
> > > @@ -3089,6 +3089,14 @@ Some combination of the following values:
> > >  Include HDR metadata if the input frames have it
> > >  (@emph{mastering_display_colour_volume} and
> > @emph{content_light_level}
> > >  messages).
> > > +
> > > +@item low_delay_b
> > > +Use low delay B-frames instead of P frames. Reordering of pictures is
> > > +not allowed. The first picture is encoded as an I picture and subsequent
> > > +pictures are encoded as B pictures. Moreover, since past B pictures are
> > > +used for prediction, a low coding delay but with higher coding efficiency
> > > +(because of bi-prediction) is achieved.
> >
> > This sounds like a marketing blurb.
> >
> > Not for the manual, but can you explain in detail what might actually make
> > this better, with actual numbers if possible?  Intuitively the coding
> efficiency
> > will be worse, because a number of the B-picture syntax elements are just
> > redundant but still have to be coded (picking between two options which
> are
> > actually identical).  The gain of allowing biprediction between two 
> > identical
> > pictures doesn't seem like a useful feature.
> >
> The story is, this is kind of the hardware limitation for VDENC as we've
> discussed
> on IRC.

Since the dependency in LIBVA and media-driver is addressed,  updated and resent
the patch.

> As to the performance/efficiency, I'm curious too and would take some
> experiments.
Did some quick experiments on ICL with IBBPBBP reference structure (not 
official data,
just to show the possible benefits):

Bdrate : -1.570% based on normal IPB structure if we convert P frames to B 
frames.

biprediction between two identical pictures seem to benefit the quality 
slightly.

Please help to comment:
https://patchwork.ffmpeg.org/project/ffmpeg/patch/1591019384-21910-1-git-send-email-linjie...@intel.com/

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

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

Re: [FFmpeg-devel] [PATCH v2 1/3] avformat/rtspdec: av_dict_set() -> av_dict_set_int()

[lance . lmwang]

On Wed, May 27, 2020 at 07:10:45PM +0800, lance.lmw...@gmail.com wrote:
> From: Limin Wang 
> 
> Signed-off-by: Limin Wang 
> ---
>  libavformat/rtspdec.c | 4 +---
>  1 file changed, 1 insertion(+), 3 deletions(-)
> 
> diff --git a/libavformat/rtspdec.c b/libavformat/rtspdec.c
> index bd2e8f4..dfa2991 100644
> --- a/libavformat/rtspdec.c
> +++ b/libavformat/rtspdec.c
> @@ -289,9 +289,7 @@ static int rtsp_read_setup(AVFormatContext *s, char* 
> host, char *controlurl)
>  } else {
>  do {
>  AVDictionary *opts = NULL;
> -char buf[256];
> -snprintf(buf, sizeof(buf), "%d", rt->buffer_size);
> -av_dict_set(, "buffer_size", buf, 0);
> +av_dict_set_int(, "buffer_size", rt->buffer_size, 0);
>  ff_url_join(url, sizeof(url), "rtp", NULL, host, localport, 
> NULL);
>  av_log(s, AV_LOG_TRACE, "Opening: %s", url);
>  ret = ffurl_open_whitelist(_st->rtp_handle, url, 
> AVIO_FLAG_READ_WRITE,
> -- 
> 1.8.3.1
> 

will apply the patchset tomorrow if no further comments.


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

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

[FFmpeg-devel] [PATCH] lavc/vaapi_encode: Convert P to B-frames if driver doesn't support

[Linjie Fu]

Automatically convert P-frames to B-frames according to the query
results of VAConfigAttribPredictionDirection.

If P-frames is not supported by driver, convert P-frames to B-frames
with 2 same ref_lists(forward-prediction only, low delay B-frames).

If query is not supported with current VAAPI version, convert P to B
by default for low power mode to avoid unexpected errors.

Signed-off-by: Linjie Fu 
---
Since the query support is ready in LIBVA and media-driver, this patch
is now ready for upstream:
https://github.com/intel/libva/commit/0014ada0eb0fd09a0dd928e5a132ecf12ed85c2e
https://github.com/intel/media-driver/commit/d7061b608ad4d55fccab00f8d80b852f20eab1d7

 libavcodec/vaapi_encode.c  | 61 +++---
 libavcodec/vaapi_encode.h  |  2 ++
 libavcodec/vaapi_encode_h265.c |  7 +
 3 files changed, 60 insertions(+), 10 deletions(-)

diff --git a/libavcodec/vaapi_encode.c b/libavcodec/vaapi_encode.c
index cb05ebd..0710be7 100644
--- a/libavcodec/vaapi_encode.c
+++ b/libavcodec/vaapi_encode.c
@@ -1768,26 +1768,57 @@ static av_cold int 
vaapi_encode_init_gop_structure(AVCodecContext *avctx)
 {
 VAAPIEncodeContext *ctx = avctx->priv_data;
 VAStatus vas;
-VAConfigAttrib attr = { VAConfigAttribEncMaxRefFrames };
-uint32_t ref_l0, ref_l1;
+VAConfigAttrib attr[2] = { { VAConfigAttribEncMaxRefFrames },
+#if VA_CHECK_VERSION(1, 8, 0)
+   { VAConfigAttribPredictionDirection }
+#else
+   { 0 }
+#endif
+ };
+uint32_t ref_l0, ref_l1, b_predict_direction;
 
 vas = vaGetConfigAttributes(ctx->hwctx->display,
 ctx->va_profile,
 ctx->va_entrypoint,
-, 1);
+attr, FF_ARRAY_ELEMS(attr));
 if (vas != VA_STATUS_SUCCESS) {
 av_log(avctx, AV_LOG_ERROR, "Failed to query reference frames "
"attribute: %d (%s).\n", vas, vaErrorStr(vas));
 return AVERROR_EXTERNAL;
 }
 
-if (attr.value == VA_ATTRIB_NOT_SUPPORTED) {
+if (attr[0].value == VA_ATTRIB_NOT_SUPPORTED) {
 ref_l0 = ref_l1 = 0;
 } else {
-ref_l0 = attr.value   & 0x;
-ref_l1 = attr.value >> 16 & 0x;
+ref_l0 = attr[0].value   & 0x;
+ref_l1 = attr[0].value >> 16 & 0x;
 }
+#if VA_CHECK_VERSION(1, 8, 0)
+if (attr[1].value != VA_ATTRIB_NOT_SUPPORTED)
+b_predict_direction =  attr[1].value;
+else
+b_predict_direction = 0;
 
+if (b_predict_direction & VA_PREDICTION_DIRECTION_BI_NOT_EMPTY) {
+av_log(avctx, AV_LOG_WARNING, "Driver does not support P "
+   "reference frames.\n");
+if (!ref_l0 || !ref_l1) {
+av_log(avctx, AV_LOG_ERROR, "Query result conflicts.\n");
+return AVERROR_EXTERNAL;
+}
+ctx->p_to_b = 1;
+av_log(avctx, AV_LOG_WARNING, "Convert P-frames to low delay "
+   "B frames.\n");
+}
+#else
+av_log(avctx, AV_LOG_WARNING, "B-frame prediction direction query "
+   "is not supported with this VAAPI version.\n");
+// P frames is not supported in low power encoding for HEVC,hence
+// we convert P-frames to low delay B-frames if query is not
+// available with this VAAPI version.
+if (ctx->low_power)
+ctx->p_to_b = 1;
+#endif
 if (ctx->codec->flags & FLAG_INTRA_ONLY ||
 avctx->gop_size <= 1) {
 av_log(avctx, AV_LOG_VERBOSE, "Using intra frames only.\n");
@@ -1798,14 +1829,24 @@ static av_cold int 
vaapi_encode_init_gop_structure(AVCodecContext *avctx)
 return AVERROR(EINVAL);
 } else if (!(ctx->codec->flags & FLAG_B_PICTURES) ||
ref_l1 < 1 || avctx->max_b_frames < 1) {
-av_log(avctx, AV_LOG_VERBOSE, "Using intra and P-frames "
-   "(supported references: %d / %d).\n", ref_l0, ref_l1);
+if (ctx->p_to_b)
+av_log(avctx, AV_LOG_VERBOSE, "Using intra and low delay "
+   "B-frames (supported references: %d / %d).\n",
+   ref_l0, ref_l1);
+else
+av_log(avctx, AV_LOG_VERBOSE, "Using intra and P-frames "
+   "(supported references: %d / %d).\n", ref_l0, ref_l1);
 ctx->gop_size = avctx->gop_size;
 ctx->p_per_i  = INT_MAX;
 ctx->b_per_p  = 0;
 } else {
-av_log(avctx, AV_LOG_VERBOSE, "Using intra, P- and B-frames "
-   "(supported references: %d / %d).\n", ref_l0, ref_l1);
+if (ctx->p_to_b)
+av_log(avctx, AV_LOG_VERBOSE, "Using intra, low delay B- and "
+   "B-frames (supported references: %d / %d).\n",
+   ref_l0, ref_l1);
+else
+av_log(avctx, AV_LOG_VERBOSE, "Using intra, P- and B-frames "
+   "(supported references: %d / %d).\n", ref_l0, ref_l1);
 

[FFmpeg-devel] [PATCH 2/2 v2] avutil/buffer: avutil/buffer: add a mention that some arguments from av_buffer_pool_init2() may be NULL

[James Almer]

Signed-off-by: James Almer 
---
 libavutil/buffer.h | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/libavutil/buffer.h b/libavutil/buffer.h
index e0f94314f4..c0f3f6cc9a 100644
--- a/libavutil/buffer.h
+++ b/libavutil/buffer.h
@@ -254,12 +254,13 @@ AVBufferPool *av_buffer_pool_init(int size, AVBufferRef* 
(*alloc)(int size));
  * @param size size of each buffer in this pool
  * @param opaque arbitrary user data used by the allocator
  * @param alloc a function that will be used to allocate new buffers when the
- *  pool is empty.
+ *  pool is empty. May be NULL, then the default allocator will be
+ *  used (av_buffer_alloc()).
  * @param pool_free a function that will be called immediately before the pool
  *  is freed. I.e. after av_buffer_pool_uninit() is called
  *  by the caller and all the frames are returned to the pool
  *  and freed. It is intended to uninitialize the user opaque
- *  data.
+ *  data. May be NULL.
  * @return newly created buffer pool on success, NULL on error.
  */
 AVBufferPool *av_buffer_pool_init2(int size, void *opaque,
-- 
2.26.2

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

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

[FFmpeg-devel] [PATCH 1/2] avutil/buffer: use the default allocator if none is provided to av_buffer_pool_init2()

[James Almer]

Signed-off-by: James Almer 
---
 doc/APIchanges  | 3 +++
 libavutil/buffer.c  | 3 +++
 libavutil/version.h | 2 +-
 3 files changed, 7 insertions(+), 1 deletion(-)

diff --git a/doc/APIchanges b/doc/APIchanges
index fb5534b5f5..c7e4ce3e6a 100644
--- a/doc/APIchanges
+++ b/doc/APIchanges
@@ -15,6 +15,9 @@ libavutil: 2017-10-21
 
 API changes, most recent first:
 
+2020-06-xx - xx - lavu 56.50.100 - buffer.h
+  Passing NULL as alloc argument to av_buffer_pool_init2() is now allowed.
+
 2020-xx-xx - xx - lavc 58.88.100 - avcodec.h codec.h
   Move AVCodec-related public API to new header codec.h.
 
diff --git a/libavutil/buffer.c b/libavutil/buffer.c
index 6d9cb7428e..b43cd179d7 100644
--- a/libavutil/buffer.c
+++ b/libavutil/buffer.c
@@ -229,6 +229,7 @@ AVBufferPool *av_buffer_pool_init2(int size, void *opaque,
 pool->size  = size;
 pool->opaque= opaque;
 pool->alloc2= alloc;
+pool->alloc = av_buffer_alloc; // fallback
 pool->pool_free = pool_free;
 
 atomic_init(>refcount, 1);
@@ -310,6 +311,8 @@ static AVBufferRef *pool_alloc_buffer(AVBufferPool *pool)
 BufferPoolEntry *buf;
 AVBufferRef *ret;
 
+av_assert0(pool->alloc || pool->alloc2);
+
 ret = pool->alloc2 ? pool->alloc2(pool->opaque, pool->size) :
  pool->alloc(pool->size);
 if (!ret)
diff --git a/libavutil/version.h b/libavutil/version.h
index 7acecf5a97..5d5cec62ab 100644
--- a/libavutil/version.h
+++ b/libavutil/version.h
@@ -79,7 +79,7 @@
  */
 
 #define LIBAVUTIL_VERSION_MAJOR  56
-#define LIBAVUTIL_VERSION_MINOR  49
+#define LIBAVUTIL_VERSION_MINOR  50
 #define LIBAVUTIL_VERSION_MICRO 100
 
 #define LIBAVUTIL_VERSION_INT   AV_VERSION_INT(LIBAVUTIL_VERSION_MAJOR, \
-- 
2.26.2

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

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

Re: [FFmpeg-devel] [PATCH] ffmpeg:Accelerated hardware decode support on Jetson

[Anton Khirnov]

Hi,
the preferred way of adding new hardware-accelerated decoding wrappers
is implementing the hwcontext API in libavutil and the hwaccel hooks in
libavcodec decoders. Handles to hardware frames are exported to the
caller to avoid a possibly-unnecessary memory copy. See e.g.
vaapi_decode for an example.
Deviating from this pattern requires a sufficiently strong
justification.

Beyond that, we already have two NVidia hardware decoding APIs. Why is
there a need for a third one?

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

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

Re: [FFmpeg-devel] [PATCH] avformat/dashenc: use AVCodecContext timebase when computing missing bitrate

[Jeyapal, Karthick]

On 6/1/20 5:24 PM, Przemysław Sobala wrote:
> On Mon, Jun 1, 2020 at 10:06 AM Anton Khirnov  wrote:
>
>> Quoting Przemysław Sobala (2020-05-27 17:07:22)
>>> ---
>>>  libavformat/dashenc.c | 2 +-
>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c
>>> index 0cf0df50ef..00a37b175d 100644
>>> --- a/libavformat/dashenc.c
>>> +++ b/libavformat/dashenc.c
>>> @@ -1959,7 +1959,7 @@ static int dash_flush(AVFormatContext *s, int
>> final, int stream)
>>>
>>>  if (!os->bit_rate) {
>>>  // calculate average bitrate of first segment
>>> -int64_t bitrate = (int64_t) range_length * 8 * AV_TIME_BASE
>> / duration;
>>> +int64_t bitrate = (int64_t) range_length * 8 *
>> (c->use_timeline ? os->ctx->streams[0]->time_base.den : AV_TIME_BASE) /
>> duration;
>>
>> That does not look like an AVCodecContext
>>
>
> Of course not. time_base is AVStream's field. I don't know why I wrote
> AVCodecContext... Please amend that commit message if possible.
Amended and Pushed!

Thanks,
Karthick
>
> --
> Przemysław Sobala
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://urldefense.proofpoint.com/v2/url?u=https-3A__ffmpeg.org_mailman_listinfo_ffmpeg-2Ddevel=DwIGaQ=96ZbZZcaMF4w0F4jpN6LZg=xOoesbz-6ff1GPXp5Lg4jf1ZG99yp4a1qhxVn_YOwRU=d5_uQoLoKY0i_-ZFJQGxnQcD0feA0He0ST4ojg4---4=dstVnsDMFsrakFvnEaO5zT4dmLntnO4RBfr7YTHwI_4=
>  
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

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

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

Re: [FFmpeg-devel] [PATCH 1/2] avcodec: Add AV_CODEC_FLAG2_FAST_UNSAFE, move unsafe uses of FAST to it

[Kieran Kunhya]

On Mon, 1 Jun 2020 at 14:02, Anton Khirnov  wrote:

> Quoting Paul B Mahol (2020-05-29 18:46:18)
> > I see no aggression at all here.
>
> Same here. People have disagreeing opinions and are expressing them.
> That does not imply aggression or uncivility.
>

There is no aggression here.
If anything the long winded text about how anyone who wants this code
removed is creating CO2 emissions is passive-aggressive.

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

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

Re: [FFmpeg-devel] [PATCH] ffmpeg:Accelerated hardware decode support on Jetson

[Jean-Baptiste Kempf]

Hello,

Why does it uses v4l2 in a different way and requires a nvv4l2 file instead of 
v4l_m2m or v4l2?

BEst,

On Mon, Jun 1, 2020, at 11:50, Amit Pandya wrote:
> Hi all,
> 
> This patch can support hardware-accelerated decode in ffmpeg on Jetson 
> platforms.
> 
> ffmpeg application can use accelerated decode to read video files in the 
> following elementary/container formats and dump them in YUV 420 format:
> H.264, H.265, VP8, VP9. MPEG2, MPEG4
> (NOTE: The ffmpeg package does not support MPEG4 container files).
> 
> Steps to apply the patch:
> 1) Clone the ffmpeg master branch:
> git clone git://source.ffmpeg.org/ffmpeg
> 2) cd ffmpeg
> 3) Apply the patch 
> 0001-ffmpeg-Accelerated-hardware-decode-support-on-Jetson.patch
> Command to apply the patch:
> git apply 0001-ffmpeg-Accelerated-hardware-decode-support-on-Jetson.patch
> 
> Steps to compile:
> 1) Install "jetson_multimedia_api" package from latest Jetpack release.
> Follow link to install jetpack on jetson: 
> https://developer.nvidia.com/embedded/jetpack
> 2) Install below dependent packages on target using the command (if not 
> already installed by jetpack):
> sudo apt install libv4l-dev
> sudo apt install gcc
> sudo apt install pkg-config
> sudo apt install libegl1-mesa-dev
> 3) Run following commands to build and install:
> ./configure --enable-nvv4l2dec --enable-libv4l2 --enable-shared 
> --extra-libs="-L/usr/lib/aarch64-linux-gnu/tegra -lnvbuf_utils" 
> --extra-cflags="-I /usr/src/jetson_multimedia_api/include/"
> make
> sudo make install
> export LD_LIBRARY_PATH=/usr/local/lib/
> 4) Run following commands to decode:
> H264: ffmpeg -c:v h264_nvv4l2dec -i  
> H265: ffmpeg -c:v hevc_nvv4l2dec -i  
> MPEG2: ffmpeg -c:v mpeg2_nvv4l2dec -i  
> MPEG4: ffmpeg -c:v mpeg4_nvv4l2dec -i  
> VP8: ffmpeg -c:v vp8_nvv4l2dec -i  
> VP9: ffmpeg -c:v vp9_nvv4l2dec -i  
> 
> Example command:
> ffmpeg -c:v mpeg2_nvv4l2dec -i libmpeg2bug.ts output_420.yuv
> (Input file is referenced from https://samples.ffmpeg.org/MPEG2/)
> 
> -Regards,
> Amit Pandya
> 
> 
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
> 
> *Attachments:*
>  * 0001-ffmpeg-Accelerated-hardware-decode-support-on-Jetson.patch
>  * README.nvidia

--
Jean-Baptiste Kempf - President
+33 672 704 734


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

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

Re: [FFmpeg-devel] [PATCH v2] avcodec/h264_parser: Try to avoid (un)referencing

[Anton Khirnov]

Quoting Andreas Rheinhardt (2020-06-01 12:21:15)
> Anton Khirnov:
> > Quoting Andreas Rheinhardt (2020-05-29 18:31:57)
> >> When a slice is encountered, the H.264 parser up until now always
> >> unreferenced and reset the currently active PPS; immediately
> >> afterwards, the currently active PPS is set again which includes
> >> referencing it. Given that it is typical for the active parameter
> >> sets to change only seldomly, most of the time the new active PPS will
> >> be the old one. Therefore this commit checks for this and only
> >> unreferences the PPS if it changed.
> >>
> >> Signed-off-by: Andreas Rheinhardt 
> >> ---
> >> New and much simplified version of [1]. This has been made possible by
> >> 5e316096fa9ba4493d9dbb48847ad8e0b0e188c3.
> >>
> >> [1]: https://ffmpeg.org/pipermail/ffmpeg-devel/2019-August/248374.html
> >>
> >>  libavcodec/h264_parser.c | 2 ++
> >>  1 file changed, 2 insertions(+)
> > 
> > I've been considering a utility function along the lines of:
> > 
> > int av_buffer_update(AVBufferRef **dst, AVBufferRef *src)
> > {
> > if ((*dst)->buffer == src->buffer)
> 
> Obviously missing a check for *dst == NULL.
> 
> > return 0;
> 
> What if *dst and src point to different parts of the same underlying
> AVBuffer? You'd need to overwrite **dst with *src in this case.
> 
> > av_buffer_unref(dst);
> > *dst = av_buffer_ref(src);
> > return 1;
> 
> Missing check for av_buffer_ref failure.

This was supposed to be a quick example, not complete code ready to be
pushed.

> 
> > }
> > 
> > which would help avoid unnecessary unrefs+refs in such cases. Thoughts?
> > 
> I also pondered such a helper function, but then opted for the simple
> approach instead. But if you want such a function and if it resides in
> libavutil/buffer.c, then one could improve this even further by not
> calling av_buffer_unref(dst) which throws an AVBufferRef away, but by
> just decrementing the refcount of the underlying AVBuffer of *dst (and
> freeing it if necessary), incrementing the refcount of the AVBuffer of
> src and overwriting **dst with *src.

How is that an improvement? It seems like a lot of complexity to save a
small malloc+free.

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

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

Re: [FFmpeg-devel] [PATCH 1/2] avcodec: Add AV_CODEC_FLAG2_FAST_UNSAFE, move unsafe uses of FAST to it

[Anton Khirnov]

Quoting Paul B Mahol (2020-05-29 18:46:18)
> I see no aggression at all here.

Same here. People have disagreeing opinions and are expressing them.
That does not imply aggression or uncivility.

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

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

Re: [FFmpeg-devel] [PATCH] avcodec/internal: move packet related functions to their own header

[James Almer]

On 6/1/2020 6:41 AM, Anton Khirnov wrote:
> Quoting James Almer (2020-05-30 18:44:26)
>> Signed-off-by: James Almer 
>> ---
>> I included the new header directly in internal.h because the alternative was
>> including it in a hundred  or so files that call ff_alloc_packet2().
>>
>> If that's nonetheless prefered, i can go ahead with it.
> 
> I would prefer that, but won't force you or anyone to do such tedious
> work. So do as you like.
> 
>>
>>  libavcodec/internal.h| 35 +---
>>  libavcodec/packet_internal.h | 63 
>>  2 files changed, 64 insertions(+), 34 deletions(-)
>>  create mode 100644 libavcodec/packet_internal.h
>>
>> diff --git a/libavcodec/internal.h b/libavcodec/internal.h
>> index 0e3415d69b..fa5052723b 100644
>> --- a/libavcodec/internal.h
>> +++ b/libavcodec/internal.h
>> @@ -32,6 +32,7 @@
>>  #include "libavutil/pixfmt.h"
>>  #include "avcodec.h"
>>  #include "config.h"
>> +#include "packet_internal.h"
>>  
>>  /**
>>   * The codec does not modify any global variables in the init function,
>> @@ -222,36 +223,6 @@ void ff_color_frame(AVFrame *frame, const int color[4]);
>>   */
>>  #define FF_MAX_EXTRADATA_SIZE ((1 << 28) - AV_INPUT_BUFFER_PADDING_SIZE)
>>  
>> -/**
>> - * Check AVPacket size and/or allocate data.
>> - *
>> - * Encoders supporting AVCodec.encode2() can use this as a convenience to
>> - * ensure the output packet data is large enough, whether provided by the 
>> user
>> - * or allocated in this function.
>> - *
>> - * @param avctx   the AVCodecContext of the encoder
>> - * @param avpkt   the AVPacket
>> - *If avpkt->data is already set, avpkt->size is checked
>> - *to ensure it is large enough.
>> - *If avpkt->data is NULL, a new buffer is allocated.
>> - *avpkt->size is set to the specified size.
>> - *All other AVPacket fields will be reset with 
>> av_init_packet().
>> - * @param sizethe minimum required packet size
>> - * @param min_size This is a hint to the allocation algorithm, which 
>> indicates
>> - *to what minimal size the caller might later shrink the 
>> packet
>> - *to. Encoders often allocate packets which are larger than 
>> the
>> - *amount of data that is written into them as the exact 
>> amount is
>> - *not known at the time of allocation. min_size represents 
>> the
>> - *size a packet might be shrunk to by the caller. Can be 
>> set to
>> - *0. setting this roughly correctly allows the allocation 
>> code
>> - *to choose between several allocation strategies to improve
>> - *speed slightly.
>> - * @returnnon negative on success, negative error code on failure
>> - */
>> -int ff_alloc_packet2(AVCodecContext *avctx, AVPacket *avpkt, int64_t size, 
>> int64_t min_size);
> 
> I would consider this function encoder-related rather than
> packet-related, since it potentially modifies AVCodecContext state.

Ok, will see about moving this one to encode.h as part of the encoding
code rewriting set instead.

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

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

Re: [FFmpeg-devel] [PATCH 1/3] avcodec/encode: Remove ff_alloc_packet

[James Almer]

On 6/1/2020 8:32 AM, Andreas Rheinhardt wrote:
> It is no longer used anymore.
> 
> Signed-off-by: Andreas Rheinhardt 
> ---
> Strange that it has not already been removed earlier. Am I missing
> something?

Afaik, it was left in place to make merges from libav easier.

LGTM.

> 
>  libavcodec/encode.c   | 5 -
>  libavcodec/internal.h | 2 --
>  2 files changed, 7 deletions(-)
> 
> diff --git a/libavcodec/encode.c b/libavcodec/encode.c
> index b850f86d0c..b1784ed050 100644
> --- a/libavcodec/encode.c
> +++ b/libavcodec/encode.c
> @@ -70,11 +70,6 @@ int ff_alloc_packet2(AVCodecContext *avctx, AVPacket 
> *avpkt, int64_t size, int64
>  }
>  }
>  
> -int ff_alloc_packet(AVPacket *avpkt, int size)
> -{
> -return ff_alloc_packet2(NULL, avpkt, size, 0);
> -}
> -
>  /**
>   * Pad last frame with silence.
>   */
> diff --git a/libavcodec/internal.h b/libavcodec/internal.h
> index 0e3415d69b..d09c3167ed 100644
> --- a/libavcodec/internal.h
> +++ b/libavcodec/internal.h
> @@ -250,8 +250,6 @@ void ff_color_frame(AVFrame *frame, const int color[4]);
>   */
>  int ff_alloc_packet2(AVCodecContext *avctx, AVPacket *avpkt, int64_t size, 
> int64_t min_size);
>  
> -attribute_deprecated int ff_alloc_packet(AVPacket *avpkt, int size);
> -
>  /**
>   * Rescale from sample rate to AVCodecContext.time_base.
>   */
> 

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

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

Re: [FFmpeg-devel] [PATCH] avformat/dashenc: use AVCodecContext timebase when computing missing bitrate

[Przemysław Sobala]

On Mon, Jun 1, 2020 at 10:06 AM Anton Khirnov  wrote:

> Quoting Przemysław Sobala (2020-05-27 17:07:22)
> > ---
> >  libavformat/dashenc.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c
> > index 0cf0df50ef..00a37b175d 100644
> > --- a/libavformat/dashenc.c
> > +++ b/libavformat/dashenc.c
> > @@ -1959,7 +1959,7 @@ static int dash_flush(AVFormatContext *s, int
> final, int stream)
> >
> >  if (!os->bit_rate) {
> >  // calculate average bitrate of first segment
> > -int64_t bitrate = (int64_t) range_length * 8 * AV_TIME_BASE
> / duration;
> > +int64_t bitrate = (int64_t) range_length * 8 *
> (c->use_timeline ? os->ctx->streams[0]->time_base.den : AV_TIME_BASE) /
> duration;
>
> That does not look like an AVCodecContext
>

Of course not. time_base is AVStream's field. I don't know why I wrote
AVCodecContext... Please amend that commit message if possible.

--
Przemysław Sobala
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [PATCH 3/3] avfilter/vf_lut3d: Fix mixed declaration and code

[Paul B Mahol]

lgtm

On 6/1/20, Andreas Rheinhardt  wrote:
> Signed-off-by: Andreas Rheinhardt 
> ---
>  libavfilter/vf_lut3d.c | 12 ++--
>  1 file changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/libavfilter/vf_lut3d.c b/libavfilter/vf_lut3d.c
> index e5d9fcc068..6730a424ce 100644
> --- a/libavfilter/vf_lut3d.c
> +++ b/libavfilter/vf_lut3d.c
> @@ -261,10 +261,11 @@ static inline float prelut_interp_1d_linear(const
> Lut3DPreLut *prelut,
>  static inline struct rgbvec apply_prelut(const Lut3DPreLut *prelut,
>   const struct rgbvec *s)
>  {
> +struct rgbvec c;
> +
>  if (prelut->size <= 0)
>  return *s;
>
> -struct rgbvec c;
>  c.r = prelut_interp_1d_linear(prelut, 0, s->r);
>  c.g = prelut_interp_1d_linear(prelut, 1, s->g);
>  c.b = prelut_interp_1d_linear(prelut, 2, s->b);
> @@ -975,17 +976,16 @@ static int parse_cinespace(AVFilterContext *ctx, FILE
> *f)
>
>  for (int i = 0; i < lut3d->prelut.size; ++i) {
>  float mix = (float) i / (float)(lut3d->prelut.size - 1);
> -float x = lerpf(in_min[c], in_max[c], mix);
> +float x = lerpf(in_min[c], in_max[c], mix), a, b;
>
>  int idx = nearest_sample_index(in_prelut[c], x, 0,
> prelut_sizes[c]-1);
>  av_assert0(idx + 1 < prelut_sizes[c]);
>
> -float a = out_prelut[c][idx + 0];
> -float b = out_prelut[c][idx + 1];
> +a   = out_prelut[c][idx + 0];
> +b   = out_prelut[c][idx + 1];
>  mix = x - in_prelut[c][idx];
>
> -float outval = lerpf(a, b, mix);
> -lut3d->prelut.lut[c][i] = sanitizef(outval);
> +lut3d->prelut.lut[c][i] = sanitizef(lerpf(a, b, mix));
>  }
>  }
>  lut3d->scale.r = 1.00f;
> --
> 2.20.1
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

[FFmpeg-devel] [PATCH 3/3] avfilter/vf_lut3d: Fix mixed declaration and code

[Andreas Rheinhardt]

Signed-off-by: Andreas Rheinhardt 
---
 libavfilter/vf_lut3d.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/libavfilter/vf_lut3d.c b/libavfilter/vf_lut3d.c
index e5d9fcc068..6730a424ce 100644
--- a/libavfilter/vf_lut3d.c
+++ b/libavfilter/vf_lut3d.c
@@ -261,10 +261,11 @@ static inline float prelut_interp_1d_linear(const 
Lut3DPreLut *prelut,
 static inline struct rgbvec apply_prelut(const Lut3DPreLut *prelut,
  const struct rgbvec *s)
 {
+struct rgbvec c;
+
 if (prelut->size <= 0)
 return *s;
 
-struct rgbvec c;
 c.r = prelut_interp_1d_linear(prelut, 0, s->r);
 c.g = prelut_interp_1d_linear(prelut, 1, s->g);
 c.b = prelut_interp_1d_linear(prelut, 2, s->b);
@@ -975,17 +976,16 @@ static int parse_cinespace(AVFilterContext *ctx, FILE *f)
 
 for (int i = 0; i < lut3d->prelut.size; ++i) {
 float mix = (float) i / (float)(lut3d->prelut.size - 1);
-float x = lerpf(in_min[c], in_max[c], mix);
+float x = lerpf(in_min[c], in_max[c], mix), a, b;
 
 int idx = nearest_sample_index(in_prelut[c], x, 0, 
prelut_sizes[c]-1);
 av_assert0(idx + 1 < prelut_sizes[c]);
 
-float a = out_prelut[c][idx + 0];
-float b = out_prelut[c][idx + 1];
+a   = out_prelut[c][idx + 0];
+b   = out_prelut[c][idx + 1];
 mix = x - in_prelut[c][idx];
 
-float outval = lerpf(a, b, mix);
-lut3d->prelut.lut[c][i] = sanitizef(outval);
+lut3d->prelut.lut[c][i] = sanitizef(lerpf(a, b, mix));
 }
 }
 lut3d->scale.r = 1.00f;
-- 
2.20.1

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

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

[FFmpeg-devel] [PATCH 1/3] avcodec/encode: Remove ff_alloc_packet

[Andreas Rheinhardt]

It is no longer used anymore.

Signed-off-by: Andreas Rheinhardt 
---
Strange that it has not already been removed earlier. Am I missing
something?

 libavcodec/encode.c   | 5 -
 libavcodec/internal.h | 2 --
 2 files changed, 7 deletions(-)

diff --git a/libavcodec/encode.c b/libavcodec/encode.c
index b850f86d0c..b1784ed050 100644
--- a/libavcodec/encode.c
+++ b/libavcodec/encode.c
@@ -70,11 +70,6 @@ int ff_alloc_packet2(AVCodecContext *avctx, AVPacket *avpkt, 
int64_t size, int64
 }
 }
 
-int ff_alloc_packet(AVPacket *avpkt, int size)
-{
-return ff_alloc_packet2(NULL, avpkt, size, 0);
-}
-
 /**
  * Pad last frame with silence.
  */
diff --git a/libavcodec/internal.h b/libavcodec/internal.h
index 0e3415d69b..d09c3167ed 100644
--- a/libavcodec/internal.h
+++ b/libavcodec/internal.h
@@ -250,8 +250,6 @@ void ff_color_frame(AVFrame *frame, const int color[4]);
  */
 int ff_alloc_packet2(AVCodecContext *avctx, AVPacket *avpkt, int64_t size, 
int64_t min_size);
 
-attribute_deprecated int ff_alloc_packet(AVPacket *avpkt, int size);
-
 /**
  * Rescale from sample rate to AVCodecContext.time_base.
  */
-- 
2.20.1

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

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

[FFmpeg-devel] [PATCH 2/3] avcodec/v4l2_m2m_enc: Avoid ;;

[Andreas Rheinhardt]

Inside a function, the second ; in a double ;; is a null statement, but
outside of functions a double ;; is simply invalid C that compilers
happen to accept. v4l2_m2m_enc.c contained several ;; as a result of
macro-expansion. So change the underlying macro so that it doesn't
happen any longer.

This fixes warnings when compiling with -pedantic: "ISO C does not allow
extra ‘;’ outside of a function".

Signed-off-by: Andreas Rheinhardt 
---
 libavcodec/v4l2_m2m_enc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavcodec/v4l2_m2m_enc.c b/libavcodec/v4l2_m2m_enc.c
index a21a7b6c65..32321f392f 100644
--- a/libavcodec/v4l2_m2m_enc.c
+++ b/libavcodec/v4l2_m2m_enc.c
@@ -417,7 +417,7 @@ static const AVCodecDefault v4l2_m2m_defaults[] = {
 .defaults   = v4l2_m2m_defaults, \
 .capabilities   = AV_CODEC_CAP_HARDWARE | AV_CODEC_CAP_DELAY, \
 .wrapper_name   = "v4l2m2m", \
-};
+}
 
 M2MENC(mpeg4,"MPEG4", mpeg4_options, AV_CODEC_ID_MPEG4);
 M2MENC(h263, "H.263", options,   AV_CODEC_ID_H263);
-- 
2.20.1

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

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

Re: [FFmpeg-devel] [PATCH v2] avcodec/h264_parser: Try to avoid (un)referencing

[Andreas Rheinhardt]

Anton Khirnov:
> Quoting Andreas Rheinhardt (2020-05-29 18:31:57)
>> When a slice is encountered, the H.264 parser up until now always
>> unreferenced and reset the currently active PPS; immediately
>> afterwards, the currently active PPS is set again which includes
>> referencing it. Given that it is typical for the active parameter
>> sets to change only seldomly, most of the time the new active PPS will
>> be the old one. Therefore this commit checks for this and only
>> unreferences the PPS if it changed.
>>
>> Signed-off-by: Andreas Rheinhardt 
>> ---
>> New and much simplified version of [1]. This has been made possible by
>> 5e316096fa9ba4493d9dbb48847ad8e0b0e188c3.
>>
>> [1]: https://ffmpeg.org/pipermail/ffmpeg-devel/2019-August/248374.html
>>
>>  libavcodec/h264_parser.c | 2 ++
>>  1 file changed, 2 insertions(+)
> 
> I've been considering a utility function along the lines of:
> 
> int av_buffer_update(AVBufferRef **dst, AVBufferRef *src)
> {
> if ((*dst)->buffer == src->buffer)

Obviously missing a check for *dst == NULL.

> return 0;

What if *dst and src point to different parts of the same underlying
AVBuffer? You'd need to overwrite **dst with *src in this case.

> av_buffer_unref(dst);
> *dst = av_buffer_ref(src);
> return 1;

Missing check for av_buffer_ref failure.

> }
> 
> which would help avoid unnecessary unrefs+refs in such cases. Thoughts?
> 
I also pondered such a helper function, but then opted for the simple
approach instead. But if you want such a function and if it resides in
libavutil/buffer.c, then one could improve this even further by not
calling av_buffer_unref(dst) which throws an AVBufferRef away, but by
just decrementing the refcount of the underlying AVBuffer of *dst (and
freeing it if necessary), incrementing the refcount of the AVBuffer of
src and overwriting **dst with *src.

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

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

[FFmpeg-devel] [PATCH] libavformat/dashenc.c:add support to change mpd update interval

[Siyuan Huang]

Hello Mr.James 

 

For this , in dash if . there are tcs whose segment type is SegmentTemplate
,and minimumUpdatePeriod is not 50 . 

(eg: https://livesim.dashif.org/livesim/mup_30/testpic_2s/Manifest.mpd)

Cause there is no rules in dash spec says , in template cases , the live
miniupdateperiod should be 500s, 

So I modify my patch that , keep the 500 as the default minimumUpdatePeriod
value , but add option to set this value for template cases 

 

B.R

Huang Siyuan 



0001-libavformat-dashenc.c-add-support-to-change-mpd-upda.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

[FFmpeg-devel] [PATCH] libavformat/dashenc.c:keep same with streaming , when live end

[Siyuan Huang]

Hello Mr.James Almer

 

Thanks for your opinion . patch is updated 

 



0001-PATCH-libavformat-dashenc.c-keep-same-with-streaming.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

[FFmpeg-devel] [PATCH] ffmpeg:Accelerated hardware decode support on Jetson

[Amit Pandya]

Hi all,

This patch can support hardware-accelerated decode in ffmpeg on Jetson 
platforms.

ffmpeg application can use accelerated decode to read video files in the 
following elementary/container formats and dump them in YUV 420 format:
H.264, H.265, VP8, VP9. MPEG2, MPEG4
(NOTE: The ffmpeg package does not support MPEG4 container files).

Steps to apply the patch:
1) Clone the ffmpeg master branch:
git clone git://source.ffmpeg.org/ffmpeg
2) cd ffmpeg
3) Apply the patch 
0001-ffmpeg-Accelerated-hardware-decode-support-on-Jetson.patch
Command to apply the patch:
git apply 0001-ffmpeg-Accelerated-hardware-decode-support-on-Jetson.patch

Steps to compile:
1) Install "jetson_multimedia_api" package from latest Jetpack release.
Follow link to install jetpack on jetson: 
https://developer.nvidia.com/embedded/jetpack
2) Install below dependent packages on target using the command (if not already 
installed by jetpack):
sudo apt install libv4l-dev
sudo apt install gcc
sudo apt install pkg-config
sudo apt install libegl1-mesa-dev
3) Run following commands to build and install:
./configure --enable-nvv4l2dec --enable-libv4l2 --enable-shared 
--extra-libs="-L/usr/lib/aarch64-linux-gnu/tegra -lnvbuf_utils" 
--extra-cflags="-I /usr/src/jetson_multimedia_api/include/"
make
sudo make install
export LD_LIBRARY_PATH=/usr/local/lib/
4) Run following commands to decode:
H264:  ffmpeg -c:v h264_nvv4l2dec -i  
H265:  ffmpeg -c:v hevc_nvv4l2dec -i  
MPEG2: ffmpeg -c:v mpeg2_nvv4l2dec -i  
MPEG4: ffmpeg -c:v mpeg4_nvv4l2dec -i  
VP8:   ffmpeg -c:v vp8_nvv4l2dec -i  
VP9:   ffmpeg -c:v vp9_nvv4l2dec -i  

Example command:
ffmpeg -c:v mpeg2_nvv4l2dec -i libmpeg2bug.ts output_420.yuv
(Input file is referenced from https://samples.ffmpeg.org/MPEG2/)

-Regards,
Amit Pandya



0001-ffmpeg-Accelerated-hardware-decode-support-on-Jetson.patch
Description: 0001-ffmpeg-Accelerated-hardware-decode-support-on-Jetson.patch


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

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

Re: [FFmpeg-devel] [PATCH v2] avcodec/h264_parser: Try to avoid (un)referencing

[Anton Khirnov]

Quoting Andreas Rheinhardt (2020-05-29 18:31:57)
> When a slice is encountered, the H.264 parser up until now always
> unreferenced and reset the currently active PPS; immediately
> afterwards, the currently active PPS is set again which includes
> referencing it. Given that it is typical for the active parameter
> sets to change only seldomly, most of the time the new active PPS will
> be the old one. Therefore this commit checks for this and only
> unreferences the PPS if it changed.
> 
> Signed-off-by: Andreas Rheinhardt 
> ---
> New and much simplified version of [1]. This has been made possible by
> 5e316096fa9ba4493d9dbb48847ad8e0b0e188c3.
> 
> [1]: https://ffmpeg.org/pipermail/ffmpeg-devel/2019-August/248374.html
> 
>  libavcodec/h264_parser.c | 2 ++
>  1 file changed, 2 insertions(+)

I've been considering a utility function along the lines of:

int av_buffer_update(AVBufferRef **dst, AVBufferRef *src)
{
if ((*dst)->buffer == src->buffer)
return 0;
av_buffer_unref(dst);
*dst = av_buffer_ref(src);
return 1;
}

which would help avoid unnecessary unrefs+refs in such cases. Thoughts?

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

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

Re: [FFmpeg-devel] [PATCH] avcodec/internal: move packet related functions to their own header

[Anton Khirnov]

Quoting James Almer (2020-05-30 18:44:26)
> Signed-off-by: James Almer 
> ---
> I included the new header directly in internal.h because the alternative was
> including it in a hundred  or so files that call ff_alloc_packet2().
> 
> If that's nonetheless prefered, i can go ahead with it.

I would prefer that, but won't force you or anyone to do such tedious
work. So do as you like.

> 
>  libavcodec/internal.h| 35 +---
>  libavcodec/packet_internal.h | 63 
>  2 files changed, 64 insertions(+), 34 deletions(-)
>  create mode 100644 libavcodec/packet_internal.h
> 
> diff --git a/libavcodec/internal.h b/libavcodec/internal.h
> index 0e3415d69b..fa5052723b 100644
> --- a/libavcodec/internal.h
> +++ b/libavcodec/internal.h
> @@ -32,6 +32,7 @@
>  #include "libavutil/pixfmt.h"
>  #include "avcodec.h"
>  #include "config.h"
> +#include "packet_internal.h"
>  
>  /**
>   * The codec does not modify any global variables in the init function,
> @@ -222,36 +223,6 @@ void ff_color_frame(AVFrame *frame, const int color[4]);
>   */
>  #define FF_MAX_EXTRADATA_SIZE ((1 << 28) - AV_INPUT_BUFFER_PADDING_SIZE)
>  
> -/**
> - * Check AVPacket size and/or allocate data.
> - *
> - * Encoders supporting AVCodec.encode2() can use this as a convenience to
> - * ensure the output packet data is large enough, whether provided by the 
> user
> - * or allocated in this function.
> - *
> - * @param avctx   the AVCodecContext of the encoder
> - * @param avpkt   the AVPacket
> - *If avpkt->data is already set, avpkt->size is checked
> - *to ensure it is large enough.
> - *If avpkt->data is NULL, a new buffer is allocated.
> - *avpkt->size is set to the specified size.
> - *All other AVPacket fields will be reset with 
> av_init_packet().
> - * @param sizethe minimum required packet size
> - * @param min_size This is a hint to the allocation algorithm, which 
> indicates
> - *to what minimal size the caller might later shrink the 
> packet
> - *to. Encoders often allocate packets which are larger than 
> the
> - *amount of data that is written into them as the exact 
> amount is
> - *not known at the time of allocation. min_size represents 
> the
> - *size a packet might be shrunk to by the caller. Can be set 
> to
> - *0. setting this roughly correctly allows the allocation 
> code
> - *to choose between several allocation strategies to improve
> - *speed slightly.
> - * @returnnon negative on success, negative error code on failure
> - */
> -int ff_alloc_packet2(AVCodecContext *avctx, AVPacket *avpkt, int64_t size, 
> int64_t min_size);

I would consider this function encoder-related rather than
packet-related, since it potentially modifies AVCodecContext state.

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

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

Re: [FFmpeg-devel] [PATCH 10/36] avcodec/vp9_superframe_split_bsf: Use unchecked bytestream reader

[Anton Khirnov]

Quoting Andreas Rheinhardt (2020-05-30 18:05:15)
> It has already been checked that there is enough data available.
> 
> Signed-off-by: Andreas Rheinhardt 
> ---

I don't see how this improves things. The only advantage of unchecked
reads is performance, but I don't think that is relevant here.
Otherwise, it just adds a non-obvious dependency on the check being
there and being correct (not to mention cluttering history).

IMO unchecked reads should be used ONLY when there are important
performance reasons to use them, otherwise checked reads should be used
even if they are not strictly necessary.

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

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

Re: [FFmpeg-devel] [PATCH] avfilter: add afwtdn filter

[Paul B Mahol]

On 6/1/20, Anton Khirnov  wrote:
> Quoting Paul B Mahol (2020-06-01 10:33:24)
>> On 6/1/20, Anton Khirnov  wrote:
>> > Quoting Paul B Mahol (2020-06-01 09:32:06)
>> >> On 5/31/20, Reino Wijnsma  wrote:
>> >> > On 2020-05-31T22:37:20+0200, Paul B Mahol  wrote:
>> >> >> On 5/31/20, Nicolas George  wrote:
>> >> >>> Paul B Mahol (12020-05-31):
>> >>  Signed-off-by: Paul B Mahol 
>> >>  ---
>> >>   libavfilter/Makefile |   1 +
>> >>   libavfilter/af_afwtdn.c  | 619
>> >>  +++
>> >>   libavfilter/allfilters.c |   1 +
>> >>   3 files changed, 621 insertions(+)
>> >>   create mode 100644 libavfilter/af_afwtdn.c
>> >> >>> No doc, name completely impossible to understand. Unacceptable.
>> >> >> Go away!
>> >> >
>> >> > Can you please act as a grown-up for once?!
>> >> > Nicolas is right. How would anyone be able to understand what your
>> >> > patch
>> >> > does. No name, no discription, no documentation. Nothing!
>> >> > I would immediately reject this patch if this would be my project.
>> >> >
>> >> > Whatever issue you have with Nicolas, I suggest you two have a
>> >> > serious
>> >> > conversation about this, preferably face-to-face if possible, and
>> >> > talk
>> >> > this
>> >> > out! I've been around here long enough to see that it's polluting
>> >> > this
>> >> > mailinglist.
>> >> >
>> >>
>> >> Look, you are not here to talk like that.
>> >
>> > Neither are you.
>> >
>> > At least this should remind people why we need an enforceable code of
>> > conduct.
>> >
>>
>> What I did wrong? What you want to enforce upon me?
>
> You are insulting, attacking and belittling other contributors. I have
> no idea how you can think such behaviour is anywhere near acceptable.
>

Where I insulted, attacked, belittled other contributorS, not counting Nicolas.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [PATCH] libavfilter/vf_drawtext.c:add support to generte ms level timestamp

[Siyuan Huang]

On 6/1/20, Siyuan Huang  wrote:

> Look email client will auto format the patch ,

> 

> 

> 

> So , patch file is attached ,

> 

> 

 

What is meaning of generte ?

 

 

--> this is used for generate  ms level watermark which burn in video . 

After that  it can test whole system latency (from camera to client ) or
said black box test . 

 

 

If there is other way which can burn ms level watermark , then  maybe  this
patch no need . 

 

Here is my script to generate live stream with watermark :

 

ffmpeg  -i inputfile -an -vcodec libx264 \

-vf
"drawtext=expansion=strftime:text='mspts':fontsize=50:fontcolor=yellow:box=1
:x=10:y=10:boxcolor=black@0.5:fontfile=./FreeSerif.ttf"

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

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

Re: [FFmpeg-devel] [PATCH] avfilter: add afwtdn filter

[Anton Khirnov]

Quoting Paul B Mahol (2020-06-01 10:33:24)
> On 6/1/20, Anton Khirnov  wrote:
> > Quoting Paul B Mahol (2020-06-01 09:32:06)
> >> On 5/31/20, Reino Wijnsma  wrote:
> >> > On 2020-05-31T22:37:20+0200, Paul B Mahol  wrote:
> >> >> On 5/31/20, Nicolas George  wrote:
> >> >>> Paul B Mahol (12020-05-31):
> >>  Signed-off-by: Paul B Mahol 
> >>  ---
> >>   libavfilter/Makefile |   1 +
> >>   libavfilter/af_afwtdn.c  | 619
> >>  +++
> >>   libavfilter/allfilters.c |   1 +
> >>   3 files changed, 621 insertions(+)
> >>   create mode 100644 libavfilter/af_afwtdn.c
> >> >>> No doc, name completely impossible to understand. Unacceptable.
> >> >> Go away!
> >> >
> >> > Can you please act as a grown-up for once?!
> >> > Nicolas is right. How would anyone be able to understand what your patch
> >> > does. No name, no discription, no documentation. Nothing!
> >> > I would immediately reject this patch if this would be my project.
> >> >
> >> > Whatever issue you have with Nicolas, I suggest you two have a serious
> >> > conversation about this, preferably face-to-face if possible, and talk
> >> > this
> >> > out! I've been around here long enough to see that it's polluting this
> >> > mailinglist.
> >> >
> >>
> >> Look, you are not here to talk like that.
> >
> > Neither are you.
> >
> > At least this should remind people why we need an enforceable code of
> > conduct.
> >
> 
> What I did wrong? What you want to enforce upon me?

You are insulting, attacking and belittling other contributors. I have
no idea how you can think such behaviour is anywhere near acceptable.

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

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

Re: [FFmpeg-devel] [PATCH] libavfilter/vf_drawtext.c:add support to generte ms level timestamp

[Paul B Mahol]

On 6/1/20, Siyuan Huang  wrote:
> Look email client will auto format the patch ,
>
>
>
> So , patch file is attached ,
>
>

What is meaning of generte ?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [PATCH] libavfilter/vf_drawtext.c:add support to generte ms level timestamp

[Siyuan Huang]

Look email client will auto format the patch , 

 

So , patch file is attached ,



0001-libavfilter-vf_drawtext.c-add-support-to-generte-ms-.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [PATCH] avfilter: add afwtdn filter

[Paul B Mahol]

On 6/1/20, Anton Khirnov  wrote:
> Quoting Paul B Mahol (2020-06-01 09:32:06)
>> On 5/31/20, Reino Wijnsma  wrote:
>> > On 2020-05-31T22:37:20+0200, Paul B Mahol  wrote:
>> >> On 5/31/20, Nicolas George  wrote:
>> >>> Paul B Mahol (12020-05-31):
>>  Signed-off-by: Paul B Mahol 
>>  ---
>>   libavfilter/Makefile |   1 +
>>   libavfilter/af_afwtdn.c  | 619
>>  +++
>>   libavfilter/allfilters.c |   1 +
>>   3 files changed, 621 insertions(+)
>>   create mode 100644 libavfilter/af_afwtdn.c
>> >>> No doc, name completely impossible to understand. Unacceptable.
>> >> Go away!
>> >
>> > Can you please act as a grown-up for once?!
>> > Nicolas is right. How would anyone be able to understand what your patch
>> > does. No name, no discription, no documentation. Nothing!
>> > I would immediately reject this patch if this would be my project.
>> >
>> > Whatever issue you have with Nicolas, I suggest you two have a serious
>> > conversation about this, preferably face-to-face if possible, and talk
>> > this
>> > out! I've been around here long enough to see that it's polluting this
>> > mailinglist.
>> >
>>
>> Look, you are not here to talk like that.
>
> Neither are you.
>
> At least this should remind people why we need an enforceable code of
> conduct.
>

What I did wrong? What you want to enforce upon me?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [PATCH 01/36] avcodec/vp9_superframe_bsf: Check for existence of data before reading it

[Anton Khirnov]

Quoting Andreas Rheinhardt (2020-05-30 18:05:06)
> Signed-off-by: Andreas Rheinhardt 
> ---
>  libavcodec/vp9_superframe_bsf.c | 5 +
>  1 file changed, 5 insertions(+)
> 
> diff --git a/libavcodec/vp9_superframe_bsf.c b/libavcodec/vp9_superframe_bsf.c
> index 57681e29e4..34a47aa69e 100644
> --- a/libavcodec/vp9_superframe_bsf.c
> +++ b/libavcodec/vp9_superframe_bsf.c
> @@ -108,6 +108,11 @@ static int vp9_superframe_filter(AVBSFContext *ctx, 
> AVPacket *pkt)
>  if (res < 0)
>  return res;
>  
> +if (pkt->size <= 0) {
> +res = AVERROR_INVALIDDATA;
> +goto done;
> +}
> +
>  marker = pkt->data[pkt->size - 1];
>  if ((marker & 0xe0) == 0xc0) {
>  int nbytes = 1 + ((marker >> 3) & 0x3);
> -- 
> 2.20.1

I wonder if it wouldn't be better to add an internal capability for
"bsf supports zero-sized packets" and have the internal code reject
packets instead.

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

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

Re: [FFmpeg-devel] [PATCH] avfilter: add afwtdn filter

[Anton Khirnov]

Quoting Paul B Mahol (2020-06-01 09:32:06)
> On 5/31/20, Reino Wijnsma  wrote:
> > On 2020-05-31T22:37:20+0200, Paul B Mahol  wrote:
> >> On 5/31/20, Nicolas George  wrote:
> >>> Paul B Mahol (12020-05-31):
>  Signed-off-by: Paul B Mahol 
>  ---
>   libavfilter/Makefile |   1 +
>   libavfilter/af_afwtdn.c  | 619 +++
>   libavfilter/allfilters.c |   1 +
>   3 files changed, 621 insertions(+)
>   create mode 100644 libavfilter/af_afwtdn.c
> >>> No doc, name completely impossible to understand. Unacceptable.
> >> Go away!
> >
> > Can you please act as a grown-up for once?!
> > Nicolas is right. How would anyone be able to understand what your patch
> > does. No name, no discription, no documentation. Nothing!
> > I would immediately reject this patch if this would be my project.
> >
> > Whatever issue you have with Nicolas, I suggest you two have a serious
> > conversation about this, preferably face-to-face if possible, and talk this
> > out! I've been around here long enough to see that it's polluting this
> > mailinglist.
> >
> 
> Look, you are not here to talk like that.

Neither are you.

At least this should remind people why we need an enforceable code of
conduct.

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

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

Re: [FFmpeg-devel] [PATCH] libavfilter/vf_drawtext.c:add support to generte ms level timestamp

[Anton Khirnov]

Quoting Siyuan Huang (2020-05-29 09:16:54)
>  
> 
> for test latency , need sub-seconds level timestamp watermark
> 
>  
> 
> Signed-off-by: SiyuanHuang 

Not much opinion on the change itself, but it seems your mail client
mangled the patch so it cannot be applied.

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

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

Re: [FFmpeg-devel] [PATCH] avformat/dashenc: use AVCodecContext timebase when computing missing bitrate

[Anton Khirnov]

Quoting Przemysław Sobala (2020-05-27 17:07:22)
> ---
>  libavformat/dashenc.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c
> index 0cf0df50ef..00a37b175d 100644
> --- a/libavformat/dashenc.c
> +++ b/libavformat/dashenc.c
> @@ -1959,7 +1959,7 @@ static int dash_flush(AVFormatContext *s, int final, 
> int stream)
>  
>  if (!os->bit_rate) {
>  // calculate average bitrate of first segment
> -int64_t bitrate = (int64_t) range_length * 8 * AV_TIME_BASE / 
> duration;
> +int64_t bitrate = (int64_t) range_length * 8 * (c->use_timeline 
> ? os->ctx->streams[0]->time_base.den : AV_TIME_BASE) / duration;

That does not look like an AVCodecContext

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

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

Re: [FFmpeg-devel] [PATCH 2/2] avutil/buffer: reject NULL as argument for the av_buffer_pool_init2() alloc callback

[Anton Khirnov]

Quoting James Almer (2020-06-01 03:30:00)
> On 5/31/2020 7:30 AM, Nicolas George wrote:
> > James Almer (12020-05-30):
> >> This prevents NULL pointer dereference crashes when calling 
> >> av_buffer_pool_get()
> >> using the resulting pool.
> >>
> >> Signed-off-by: James Almer 
> >> ---
> >>  libavutil/buffer.c | 6 +-
> >>  1 file changed, 5 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/libavutil/buffer.c b/libavutil/buffer.c
> >> index 6d9cb7428e..6fe8f19c39 100644
> >> --- a/libavutil/buffer.c
> >> +++ b/libavutil/buffer.c
> >> @@ -220,7 +220,11 @@ AVBufferPool *av_buffer_pool_init2(int size, void 
> >> *opaque,
> >> AVBufferRef* (*alloc)(void *opaque, 
> >> int size),
> >> void (*pool_free)(void *opaque))
> >>  {
> >> -AVBufferPool *pool = av_mallocz(sizeof(*pool));
> >> +AVBufferPool *pool;
> >> +
> >> +if (!alloc)
> >> +return NULL;
> >> +pool = av_mallocz(sizeof(*pool));
> >>  if (!pool)
> >>  return NULL;
> > 
> > I do not like this: this function can return NULL for AVERROR(ENOMEM),
> > but now it also means "idiot programmer thought NULL was a valid
> > callback".
> > 
> > The error code to "idiot programmer did something stupid and should have
> > read the doc" should be SIGABORT. Proper error return should be reserved
> > for cases that cannot be tested statically.
> > 
> > So, in this case:
> > 
> > av_assert0(alloc);
> > 
> > If the code is tested, it is perfectly equivalent anyway, because alloc
> > will not be NULL.
> > 
> > Regards,
> 
> I guess replacing one crash with another earlier crash is not too bad
> (Although i dislike asserts used to catch invalid arguments), but we
> can't chalk it up to "idiot user that didn't read the docs" seeing how
> in some functions certain parameters may be NULL and it's undocumented
> (see patch 1/2 from this same set).
> 
> An alternative is doing the same as av_buffer_pool_init() and falling
> back to using the default allocator if none is passed, but that's a
> change in behavior (From not working to working, instead of from
> crashing to crashing earlier).

I don't see that as a problem. Changing behaviour from something being
invalid to something being valid is okay, because nobody should have
done the invalid thing before and if they did it's their own problem.
Just bump the version so that people can check if the new behaviour is
available.

And this seems like the preferable option to me.

Also, if you do this then av_assert0(alloc || alloc2) in
pool_alloc_buffer() seems appropriate.

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

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

Re: [FFmpeg-devel] [PATCH] avfilter: add afwtdn filter

[Paul B Mahol]

On 5/31/20, Reino Wijnsma  wrote:
> On 2020-05-31T22:37:20+0200, Paul B Mahol  wrote:
>> On 5/31/20, Nicolas George  wrote:
>>> Paul B Mahol (12020-05-31):
 Signed-off-by: Paul B Mahol 
 ---
  libavfilter/Makefile |   1 +
  libavfilter/af_afwtdn.c  | 619 +++
  libavfilter/allfilters.c |   1 +
  3 files changed, 621 insertions(+)
  create mode 100644 libavfilter/af_afwtdn.c
>>> No doc, name completely impossible to understand. Unacceptable.
>> Go away!
>
> Can you please act as a grown-up for once?!
> Nicolas is right. How would anyone be able to understand what your patch
> does. No name, no discription, no documentation. Nothing!
> I would immediately reject this patch if this would be my project.
>
> Whatever issue you have with Nicolas, I suggest you two have a serious
> conversation about this, preferably face-to-face if possible, and talk this
> out! I've been around here long enough to see that it's polluting this
> mailinglist.
>

Look, you are not here to talk like that.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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