[FFmpeg-devel] [PATCH v4] Patch for memory optimization with QuickTime/MP4

2019-12-09 Thread Jörg Beckmann 
The last patch mail seems to be lost in space. Therefore here the next try .

Cheers,
Jörg


This patch invents a new option "discard_fragments" for the MP4/Quicktime/MOV 
decoder. If the option is not set, nothing changes at all. If it is set, old 
fragments are discarded as far as possible on each call to switch_root. For 
pure audio streams, the memory usage is now constant. For video streams, the 
memory usage is reduced. I've tested it with audio streams received from a 
professional DAB+ receiver and with video streams created on my own with 
"ffmpeg -i .m4v -c:a:0 copy -c:v copy -c:s copy -f ismv -movflags 
frag_keyframe -movflags faststart tcp://localhost:1234?listen" and "ffmpeg -i 
tcp://localhost:1234 -c:a copy -c:v copy -c:s copy -y ". 

Signed-off-by: Jörg Beckmann 
---
libavformat/isom.h |  1 +
 libavformat/mov.c  | 50 +-
 2 files changed, 50 insertions(+), 1 deletion(-)

diff --git a/libavformat/isom.h b/libavformat/isom.h
index 4943b80ccf..9b4753f4d7 100644
--- a/libavformat/isom.h
+++ b/libavformat/isom.h
@@ -268,6 +268,7 @@ typedef struct MOVContext {
 int advanced_editlist;
 int ignore_chapters;
 int seek_individually;
+int discard_fragments;
 int64_t next_root_atom; ///< offset of the next root atom
 int export_all;
 int export_xmp;
diff --git a/libavformat/mov.c b/libavformat/mov.c
index 7553a7fdfc..97c02725c5 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -7698,8 +7698,11 @@ static int should_retry(AVIOContext *pb, int error_code) 
{
 
 static int mov_switch_root(AVFormatContext *s, int64_t target, int index)
 {
-int ret;
+int ret, i;
 MOVContext *mov = s->priv_data;
+AVStream *st = NULL;
+MOVStreamContext *sc;
+MOVFragment *frag;
 
 if (index >= 0 && index < mov->frag_index.nb_items)
 target = mov->frag_index.item[index].moof_offset;
@@ -7721,6 +7724,44 @@ static int mov_switch_root(AVFormatContext *s, int64_t 
target, int index)
 
 mov->found_mdat = 0;
 
+if (mov->discard_fragments) {
+frag = &mov->fragment;
+
+for (i = 0; i < mov->fc->nb_streams; i++) {
+if (mov->fc->streams[i]->id == frag->track_id) {
+st = mov->fc->streams[i];
+break;
+}
+}
+
+av_assert0(st);
+
+sc = st->priv_data;
+
+switch (st->codecpar->codec_type) {
+case AVMEDIA_TYPE_AUDIO:
+case AVMEDIA_TYPE_SUBTITLE:
+/* Freeing VIDEO tables leads to corrupted video when writing 
to eg. MKV */
+av_freep(&st->index_entries);
+st->nb_index_entries = 0;
+st->index_entries_allocated_size = 0;
+
+sc->current_index = 0;
+sc->current_sample = 0;
+
+av_freep(&sc->ctts_data);
+sc->ctts_data = NULL;
+sc->ctts_allocated_size = 0;
+sc->ctts_count = 0;
+break;
+}
+
+av_free(mov->frag_index.item->stream_info);
+av_freep(&mov->frag_index.item);
+mov->frag_index.allocated_size = 0;
+mov->frag_index.nb_items = 0;
+}
+
 ret = mov_read_default(mov, s->pb, (MOVAtom){ AV_RL32("root"), INT64_MAX 
});
 if (ret < 0)
 return ret;
@@ -7975,6 +8016,9 @@ static int mov_read_seek(AVFormatContext *s, int 
stream_index, int64_t sample_ti
 int sample;
 int i;
 
+if (mc->discard_fragments)  // Seeking is not possible if fragments are 
discarded.
+return AVERROR(ENOTSUP);
+
 if (stream_index >= s->nb_streams)
 return AVERROR_INVALIDDATA;
 
@@ -8063,6 +8107,10 @@ static const AVOption mov_options[] = {
 { "decryption_key", "The media decryption key (hex)", 
OFFSET(decryption_key), AV_OPT_TYPE_BINARY, .flags = AV_OPT_FLAG_DECODING_PARAM 
},
 { "enable_drefs", "Enable external track support.", OFFSET(enable_drefs), 
AV_OPT_TYPE_BOOL,
 {.i64 = 0}, 0, 1, FLAGS },
+{"discard_fragments",
+"Discards fragments after they have been read to support live 
streams.",
+OFFSET(discard_fragments), AV_OPT_TYPE_BOOL, { .i64 = 0 },
+0, 1, FLAGS },
 
 { NULL },
 };
___
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] [aarch64] improve performance of ff_hscale_8_to_15_neon

2019-12-09 Thread Clément Bœsch 
On Sun, Dec 08, 2019 at 11:08:31PM +0200, Martin Storsjö wrote:
> On Sun, 8 Dec 2019, Clément Bœsch wrote:
> 
> > On Wed, Dec 04, 2019 at 05:24:46PM -0600, Sebastian Pop wrote:
> > > Hi Clément,
> > > 
> > > please find attached the updated patch addressing all your comments.
> > > Let me know if there is anything else that I missed and that I need to 
> > > address.
> > > 
> > 
> > I can't test but patch LGTM. Aside from the commit message: it's missing a
> > commit prefix (such as "swscale/aarch64: ...") and I'm not sure what this
> > "FMA" is referring to.
> 
> FMA is a common acronym for "fused multiplication and addition", i.e. the
> MLA instruction in AArch64.

Ah right, my bad, I thought the original code was already doing that.

-- 
Clément B.
___
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 v4] Patch for memory optimization with QuickTime/MP4

2019-12-09 Thread Moritz Barsnick 
On Mon, Dec 09, 2019 at 10:22:15 +, Jörg Beckmann wrote:

Just some formal stuff:

> Subject: Patch for memory optimization with QuickTime/MP4

This subject should be created by the actual patch, because, they way
you submitted it, it will be used for pushing.

Or you create your patch with "git format-patch" and attach it, then
the actual subject of the e-mail doesn't matter. Or "git send-email"
will format the subject for you, assuming you put the correct text into
your commit message:

That said, the commit message should be introduced with a one-liner
with a module prefix, such as:

avformat/mov: memory optimization with QuickTime/MP4

(I think it should be "for", not "with", but that's up to you in the
first step.)

Then an empty line, then the remaining text. No need to mention "patch"
anywhere in the commit message, because it's obvious that a commit
corresponds to a patch.

> The last patch mail seems to be lost in space. Therefore here the next try .
>
> Cheers,
> Jörg

If you write this text here, it will be part of the pushed commit
message. If you wish to add text to a patch sent with "git send-email",
please add your additional text below the three-dash separator:

> This patch invents a new option "discard_fragments" for the MP4/Quicktime/MOV 
> decoder. If the option is not set, nothing changes at all. If it is set, old 
> fragments are discarded as far as possible on each call to switch_root. For 
> pure audio streams, the memory usage is now constant. For video streams, the 
> memory usage is reduced. I've tested it with audio streams received from a 
> professional DAB+ receiver and with video streams created on my own with 
> "ffmpeg -i .m4v -c:a:0 copy -c:v copy -c:s copy -f ismv -movflags 
> frag_keyframe -movflags faststart tcp://localhost:1234?listen" and "ffmpeg -i 
> tcp://localhost:1234 -c:a copy -c:v copy -c:s copy -y ".
>
> Signed-off-by: Jörg Beckmann 
> ---

(Add your text in here.)

You should also kindly wrap your commit message at ~80 characters, or
perhaps 72.

> +for (i = 0; i < mov->fc->nb_streams; i++) {
> +if (mov->fc->streams[i]->id == frag->track_id) {
> +st = mov->fc->streams[i];
> +break;
> +}
> +}
> +
> +av_assert0(st);

This can never happen? Or can it, with an illegally formatted file, but
shouldn't? In the latter case, you would need to error out with
"invalid data". (Just wondering, not critisizing.)

> +case AVMEDIA_TYPE_SUBTITLE:
> +/* Freeing VIDEO tables leads to corrupted video when 
> writing to eg. MKV */
> +av_freep(&st->index_entries);
> +st->nb_index_entries = 0;

av_freep() NULLs for you.

> +av_freep(&sc->ctts_data);
> +sc->ctts_data = NULL;

Ditto.

> +{"discard_fragments",
> +"Discards fragments after they have been read to support live 
> streams.",

Nit: I think these descriptions are imperatives, so drop the 's' from
"Discards".

Cheers,
Moritz
___
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/5] avcodec/cbs_mpeg2: Change assertion from bytes to bits

2019-12-09 Thread Andreas Rheinhardt 
On Mon, Dec 9, 2019 at 2:54 AM James Almer  wrote:

> On 12/8/2019 6:31 PM, Michael Niedermayer wrote:
> > This allows writing empty slices
>
> Are empty slices valid in mpeg2 to begin with? Or is that the result of
> invalid/truncated data exclusively?
>
> It's invalid data, unless data partitioning (which we do not and IMO
should never support) is in use. Data partitioning allows to split the
bitstream into two that can be sent independently (and over channels of
different reliability) and it allows the slice in the base layer to only
contain everything excluding the macroblocks (i.e. everything that we put
into the slice header).

But if data partitioning is not in use, there has to be a macroblock after
the extra_information_slice and a macroblock consists of more than zero
bits; in fact, there always has to be a bit set to 1 among the first eight
bits (which is not meant to imply that every macroblock needs to contain
eight bits at all).

I will add a check to error out if slices without data beyond the slice
header are encountered upon reading. And also similar patches for cbs_h2645.

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

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

Re: [FFmpeg-devel] [PATCH v4] Patch for memory optimization with QuickTime/MP4

2019-12-09 Thread Moritz Barsnick 
On Mon, Dec 09, 2019 at 13:15:40 +0100, Moritz Barsnick wrote:
> > +case AVMEDIA_TYPE_SUBTITLE:
> > +/* Freeing VIDEO tables leads to corrupted video when 
> > writing to eg. MKV */
> > +av_freep(&st->index_entries);
> > +st->nb_index_entries = 0;
>
> av_freep() NULLs for you.

Forget this one, I misread it. ;-)

>
> > +av_freep(&sc->ctts_data);
> > +sc->ctts_data = NULL;
>
> Ditto.

But my comment applies here.

Moritz
___
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] [SCISYS Possible Spam] Re: [PATCH v4] Patch for memory optimization with QuickTime/MP4

2019-12-09 Thread Jörg Beckmann 


> -Ursprüngliche Nachricht-
> Von: ffmpeg-devel  Im Auftrag von Moritz
> Barsnick
> Gesendet: Montag, 9. Dezember 2019 13:16
> An: FFmpeg development discussions and patches 
> Betreff: [SCISYS Possible Spam] Re: [FFmpeg-devel] [PATCH v4] Patch for
> memory optimization with QuickTime/MP4
> 
> On Mon, Dec 09, 2019 at 10:22:15 +, Jörg Beckmann wrote:
> 
> Just some formal stuff:
> 
> > Subject: Patch for memory optimization with QuickTime/MP4
> 
> This subject should be created by the actual patch, because, they way you
> submitted it, it will be used for pushing.
> 
> Or you create your patch with "git format-patch" and attach it, then the 
> actual
> subject of the e-mail doesn't matter. Or "git send-email"
> will format the subject for you, assuming you put the correct text into your 
> commit
> message:
> 
> That said, the commit message should be introduced with a one-liner with a
> module prefix, such as:
> 
> avformat/mov: memory optimization with QuickTime/MP4
> 
> (I think it should be "for", not "with", but that's up to you in the first 
> step.)
> 
> Then an empty line, then the remaining text. No need to mention "patch"
> anywhere in the commit message, because it's obvious that a commit corresponds
> to a patch.
> 
> > The last patch mail seems to be lost in space. Therefore here the next try .
> >
> > Cheers,
> > Jörg
> 
> If you write this text here, it will be part of the pushed commit message. If 
> you wish
> to add text to a patch sent with "git send-email", please add your additional 
> text
> below the three-dash separator:
> 
> > This patch invents a new option "discard_fragments" for the
> MP4/Quicktime/MOV decoder. If the option is not set, nothing changes at all. 
> If it
> is set, old fragments are discarded as far as possible on each call to 
> switch_root.
> For pure audio streams, the memory usage is now constant. For video streams,
> the memory usage is reduced. I've tested it with audio streams received from a
> professional DAB+ receiver and with video streams created on my own with
> "ffmpeg -i .m4v -c:a:0 copy -c:v copy -c:s copy -f ismv -movflags
> frag_keyframe -movflags faststart tcp://localhost:1234?listen" and "ffmpeg -i
> tcp://localhost:1234 -c:a copy -c:v copy -c:s copy -y ".
> >
> > Signed-off-by: Jörg Beckmann 
> > ---
> 
> (Add your text in here.)
> 
> You should also kindly wrap your commit message at ~80 characters, or perhaps
> 72.

Okay, I'll send it again.

> 
> > +for (i = 0; i < mov->fc->nb_streams; i++) {
> > +if (mov->fc->streams[i]->id == frag->track_id) {
> > +st = mov->fc->streams[i];
> > +break;
> > +}
> > +}
> > +
> > +av_assert0(st);
> 
> This can never happen? Or can it, with an illegally formatted file, but 
> shouldn't? In
> the latter case, you would need to error out with "invalid data". (Just 
> wondering, not
> critisizing.)

The assert() results from a discussion with Carl Eugen Hoyos. There was an 
error message before, but he suggested to replace it because it should not be 
possible.
 
> > +case AVMEDIA_TYPE_SUBTITLE:
> > +/* Freeing VIDEO tables leads to corrupted video when 
> > writing to eg.
> MKV */
> > +av_freep(&st->index_entries);
> > +st->nb_index_entries = 0;
> 
> av_freep() NULLs for you.
> 
> > +av_freep(&sc->ctts_data);
> > +sc->ctts_data = NULL;
> 
> Ditto.

Oops, I forgot to change it here.

> > +{"discard_fragments",
> > +"Discards fragments after they have been read to support
> > + live streams.",
> 
> Nit: I think these descriptions are imperatives, so drop the 's' from 
> "Discards".

I think you're right.

> 
> Cheers,
> Moritz
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org 
> with
> subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [PATCH] avfilter: rename scale.c, h to scale_eval

2019-12-09 Thread Gyan 



On 08-12-2019 04:47 pm, Gyan wrote:

Makes commit msgs less ambiguous.


Plan to push tomorrow.

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

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

[FFmpeg-devel] Inconsistent behavior in dashenc.c when using custom avio function.

2019-12-09 Thread eSX 
Hi ffmpeg
Recently I want to use dash format to serve a real-time stream video in C
language.
I want to encode the video in memory and copy it out for some purpose.

I use an example code here:
https://gist.github.com/AlexVestin/15b90d72f51ff7521cd7ce4b70056dff

The example code is fine for mp4 format( e.g. call open_video(width,
height, 60, 4, 0, 1, 1);), but the custom avio callback can not be
triggered when I just modify the "mp4" to "dash" in line 220.

I have read the code in dashenc.c, it seems that dashenc take over the avio
functions in dash_init():

if (!c->single_file) {
if ((ret = avio_open_dyn_buf(&ctx->pb)) < 0)
return ret;
ret = s->io_open(s, &os->out, filename, AVIO_FLAG_WRITE, &opts);
} else {
ctx->url = av_strdup(filename);
ret = avio_open2(&ctx->pb, filename, AVIO_FLAG_WRITE, NULL,
&opts);
}

User can only use existing IO functions defined in protocols.c.
Yes, of course, I can read the packet after
calling avcodec_receive_packet(), but the init segment or the file header
can't be retrieved from memory, becasue avformat_write_header() can not
trigger the custom avio callback function.

The behavior is inconsistent for each format, any ideas?

Thanks.



-- 
eSX
___
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] Reimbursement request NTTW4 in Budapest

2019-12-09 Thread Stefano Sabatini 
Il dom 8 dic 2019, 14:37 Carl Eugen Hoyos  ha scritto:

> Hi!
>
> I gave a talk at NTTW4 in Budapest last week and participated (late)
> in the community day.
> I request reimbursement for travel and accommodation, together € 78,-
> and will prepare the usual paperwork for SPI.
>

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

[FFmpeg-devel] [PATCH v5] avformat/mov: Memory optimization with QuickTime/MP4

2019-12-09 Thread Jörg Beckmann 
Invents a new option "discard_fragments" for the MP4/Quicktime/MOV decoder.
 
If the option is not set, nothing changes at all. If it is set, old fragments
are discarded as far as possible on each call to switch_root. For pure audio
streams, the memory usage is now constant. For video streams, the memory
usage is reduced. It's tested with audio streams received from a 
professional DAB+ receiver and with video streams created on my own with 
"ffmpeg -i .m4v -c:a:0 copy -c:v copy -c:s copy -f ismv -movflags \
frag_keyframe -movflags faststart tcp://localhost:1234?listen" and 
"ffmpeg -i tcp://localhost:1234 -c:a copy -c:v copy -c:s copy -y ".

Signed-off-by: Jörg Beckmann 
---
libavformat/isom.h |  1 +
 libavformat/mov.c  | 49 -
 2 files changed, 49 insertions(+), 1 deletion(-)

diff --git a/libavformat/isom.h b/libavformat/isom.h
index 4943b80ccf..9b4753f4d7 100644
--- a/libavformat/isom.h
+++ b/libavformat/isom.h
@@ -268,6 +268,7 @@ typedef struct MOVContext {
 int advanced_editlist;
 int ignore_chapters;
 int seek_individually;
+int discard_fragments;
 int64_t next_root_atom; ///< offset of the next root atom
 int export_all;
 int export_xmp;
diff --git a/libavformat/mov.c b/libavformat/mov.c
index 7553a7fdfc..deb3ff5508 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -7698,8 +7698,11 @@ static int should_retry(AVIOContext *pb, int error_code) 
{
 
 static int mov_switch_root(AVFormatContext *s, int64_t target, int index)
 {
-int ret;
+int ret, i;
 MOVContext *mov = s->priv_data;
+AVStream *st = NULL;
+MOVStreamContext *sc;
+MOVFragment *frag;
 
 if (index >= 0 && index < mov->frag_index.nb_items)
 target = mov->frag_index.item[index].moof_offset;
@@ -7721,6 +7724,43 @@ static int mov_switch_root(AVFormatContext *s, int64_t 
target, int index)
 
 mov->found_mdat = 0;
 
+if (mov->discard_fragments) {
+frag = &mov->fragment;
+
+for (i = 0; i < mov->fc->nb_streams; i++) {
+if (mov->fc->streams[i]->id == frag->track_id) {
+st = mov->fc->streams[i];
+break;
+}
+}
+
+av_assert0(st);
+
+sc = st->priv_data;
+
+switch (st->codecpar->codec_type) {
+case AVMEDIA_TYPE_AUDIO:
+case AVMEDIA_TYPE_SUBTITLE:
+/* Freeing VIDEO tables leads to corrupted video when writing 
to eg. MKV */
+av_freep(&st->index_entries);
+st->nb_index_entries = 0;
+st->index_entries_allocated_size = 0;
+
+sc->current_index = 0;
+sc->current_sample = 0;
+
+av_freep(&sc->ctts_data);
+sc->ctts_allocated_size = 0;
+sc->ctts_count = 0;
+break;
+}
+
+av_free(mov->frag_index.item->stream_info);
+av_freep(&mov->frag_index.item);
+mov->frag_index.allocated_size = 0;
+mov->frag_index.nb_items = 0;
+}
+
 ret = mov_read_default(mov, s->pb, (MOVAtom){ AV_RL32("root"), INT64_MAX 
});
 if (ret < 0)
 return ret;
@@ -7975,6 +8015,9 @@ static int mov_read_seek(AVFormatContext *s, int 
stream_index, int64_t sample_ti
 int sample;
 int i;
 
+if (mc->discard_fragments)  // Seeking is not possible if fragments are 
discarded.
+return AVERROR(ENOTSUP);
+
 if (stream_index >= s->nb_streams)
 return AVERROR_INVALIDDATA;
 
@@ -8063,6 +8106,10 @@ static const AVOption mov_options[] = {
 { "decryption_key", "The media decryption key (hex)", 
OFFSET(decryption_key), AV_OPT_TYPE_BINARY, .flags = AV_OPT_FLAG_DECODING_PARAM 
},
 { "enable_drefs", "Enable external track support.", OFFSET(enable_drefs), 
AV_OPT_TYPE_BOOL,
 {.i64 = 0}, 0, 1, FLAGS },
+{"discard_fragments",
+"Discard fragments after they have been read to support live 
streams.",
+OFFSET(discard_fragments), AV_OPT_TYPE_BOOL, { .i64 = 0 },
+0, 1, FLAGS },
 
 { NULL },
 };

___
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] Next developer meeting...

2019-12-09 Thread Jean-Baptiste Kempf 
On Thu, Dec 5, 2019, at 00:22, Jean-Baptiste Kempf wrote:
> will do our next meeting, Monday 9 December 2019, at 17:00 
> Berlin/Paris/Brussels time.
> 
> The time is selected so that people in China and in South America can join us.
> 
> It will be online, with live comments/discussion on IRC.

See you soon on #ffmpeg-meeting on freenode.

-- 
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] avcodec/ffv1enc: Use version 3 by default (CRCs by default)

2019-12-09 Thread Kieran O Leary 
On Sun, 8 Dec 2019, 22:50 Michael Niedermayer, 
wrote:

> Version 3 is since 2013 (FFmpeg 2.1) non experimental so should be widely
> supported
>

This was recently raised at the No Time To Wait conference in Budapest, so
it would be great to see version three as the default!

Best,

Kieran O'Leary
___
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/ffv1enc: Use version 3 by default (CRCs by default)

2019-12-09 Thread Peter B. 

On 09/12/2019 17:27, Kieran O Leary wrote:
This was recently raised at the No Time To Wait conference in 
Budapest, so it would be great to see version three as the default!


Actually it was triggered by NTTW4.
(Thanks Michael for addressing this)


It should be noted though, that Michael also reminded me of "why it was 
v1 in the first place":


[quote]
"The default is the lowest version which supports all the user selected 
features.


Thats chosen so as to generate a file which is most widely supported.
(older bitstream versions work on older decoders, newer would only work 
on newer decoders)"

[/quote]


This should be known.
However, since I hardly see any reason to prefer v1 over v3 anymore, and 
considering that it's now the most widely one used, I'm happy to see it 
become default.



Any objections?


Kind regards,
Peter B.
___
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] Reimbursement request NTTW4 in Budapest

2019-12-09 Thread Michael Niedermayer 
On Sun, Dec 08, 2019 at 02:36:38PM +0100, Carl Eugen Hoyos wrote:
> Hi!
> 
> I gave a talk at NTTW4 in Budapest last week and participated (late)
> in the community day.
> I request reimbursement for travel and accommodation, together € 78,-
> and will prepare the usual paperwork for SPI.
> 
> Thank you, Carl Eugen
> 
> https://www.youtube.com/watch?v=cjJZ0cjtaz8

LGTM

thx

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

It is dangerous to be right in matters on which the established authorities
are wrong. -- Voltaire


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] [aarch64] improve performance of ff_hscale_8_to_15_neon

2019-12-09 Thread Sebastian Pop 
On Mon, Dec 9, 2019 at 5:01 AM Clément Bœsch  wrote:
>
> On Sun, Dec 08, 2019 at 11:08:31PM +0200, Martin Storsjö wrote:
> > On Sun, 8 Dec 2019, Clément Bœsch wrote:
> >
> > > On Wed, Dec 04, 2019 at 05:24:46PM -0600, Sebastian Pop wrote:
> > > > Hi Clément,
> > > >
> > > > please find attached the updated patch addressing all your comments.
> > > > Let me know if there is anything else that I missed and that I need to 
> > > > address.
> > > >
> > >
> > > I can't test but patch LGTM. Aside from the commit message: it's missing a
> > > commit prefix (such as "swscale/aarch64: ...") and I'm not sure what this
> > > "FMA" is referring to.
> >
> > FMA is a common acronym for "fused multiplication and addition", i.e. the
> > MLA instruction in AArch64.
>
> Ah right, my bad, I thought the original code was already doing that.
>

I replaced "FMA" with "multiply accumulate" in the subject line and added the
prefix as recommended.  Ok to commit?

Thanks,
Sebastian


0001-swscale-aarch64-use-multiply-accumulate-and-increase.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 3/4] Remove redundant ;

2019-12-09 Thread Michael Niedermayer 
On Sun, Dec 08, 2019 at 08:18:40AM +, Fu, Linjie wrote:
> Hi,
> 
> > -Original Message-
> > From: ffmpeg-devel  On Behalf Of
> > Michael Niedermayer
> > Sent: Sunday, December 8, 2019 07:20
> > To: FFmpeg development discussions and patches  > de...@ffmpeg.org>
> > Subject: [FFmpeg-devel] [PATCH 3/4] Remove redundant ;
> > 
> > Signed-off-by: Michael Niedermayer 
> > ---
> >  libavfilter/af_axcorrelate.c | 4 ++--
> >  libavfilter/vf_drawbox.c | 2 +-
> >  libavformat/dashdec.c| 2 +-
> >  libavformat/hlsenc.c | 2 +-
> >  4 files changed, 5 insertions(+), 5 deletions(-)
> > 
> > diff --git a/libavfilter/af_axcorrelate.c b/libavfilter/af_axcorrelate.c
> > index 861903b0f1..6e9a028716 100644
> > --- a/libavfilter/af_axcorrelate.c
> > +++ b/libavfilter/af_axcorrelate.c
> > @@ -238,11 +238,11 @@ static int activate(AVFilterContext *ctx)
> > 
> >  ret = av_audio_fifo_peek(s->fifo[0], (void **)s->cache[0]-
> > >extended_data, available);
> >  if (ret < 0)
> > -return ret;;
> > +return ret;
> > 
> >  ret = av_audio_fifo_peek(s->fifo[1], (void **)s->cache[1]-
> > >extended_data, available);
> >  if (ret < 0)
> > -return ret;;
> > +return ret;
> > 
> >  out = ff_get_audio_buffer(ctx->outputs[0], out_samples);
> >  if (!out)
> > diff --git a/libavfilter/vf_drawbox.c b/libavfilter/vf_drawbox.c
> > index d71e3af397..2750048bcd 100644
> > --- a/libavfilter/vf_drawbox.c
> > +++ b/libavfilter/vf_drawbox.c
> > @@ -292,7 +292,7 @@ static int process_command(AVFilterContext *ctx,
> > const char *cmd, const char *ar
> >  ret = init(ctx);
> >  if (ret < 0)
> >  goto end;
> > -ret = config_input(inlink);;
> > +ret = config_input(inlink);
> >  end:
> >  if (ret < 0) {
> >  s->x = old_x;
> > diff --git a/libavformat/dashdec.c b/libavformat/dashdec.c
> > index d001c5b76d..72ba9605f0 100644
> > --- a/libavformat/dashdec.c
> > +++ b/libavformat/dashdec.c
> > @@ -1934,7 +1934,7 @@ static int
> > reopen_demux_for_component(AVFormatContext *s, struct
> > representation
> >  goto fail;
> > 
> >  pls->ctx->flags = AVFMT_FLAG_CUSTOM_IO;
> > -pls->ctx->probesize = s->probesize > 0 ? s->probesize : 1024 * 4;;
> > +pls->ctx->probesize = s->probesize > 0 ? s->probesize : 1024 * 4;
> >  pls->ctx->max_analyze_duration = s->max_analyze_duration > 0 ? s-
> > >max_analyze_duration : 4 * AV_TIME_BASE;
> >  ret = av_probe_input_buffer(&pls->pb, &in_fmt, "", NULL, 0, 0);
> >  if (ret < 0) {
> > diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
> > index 043438368e..fc53c9d654 100644
> > --- a/libavformat/hlsenc.c
> > +++ b/libavformat/hlsenc.c
> > @@ -475,7 +475,7 @@ static int flush_dynbuf(VariantStream *vs, int
> > *range_length)
> >  static void reflush_dynbuf(VariantStream *vs, int *range_length)
> >  {
> >  // re-open buffer
> > -avio_write(vs->out, vs->temp_buffer, *range_length);;
> > +avio_write(vs->out, vs->temp_buffer, *range_length);
> >  }
> > 
> >  #if HAVE_DOS_PATHS
> > --
> 
> Redundant ";" also exits in L157 of libavcodec/mpegvideo_parser.c:
> https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/mpegvideo_parser.c#L157
> 
> IMHO this could be combined and fixed in one patch.

sure, will apply with that removed too

thx

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

You can kill me, but you cannot change the truth.


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] avcodec/ffv1enc: Use version 3 by default (CRCs by default)

2019-12-09 Thread Michael Niedermayer 
On Mon, Dec 09, 2019 at 04:27:06PM +, Kieran O Leary wrote:
> On Sun, 8 Dec 2019, 22:50 Michael Niedermayer, 
> wrote:
> 
> > Version 3 is since 2013 (FFmpeg 2.1) non experimental so should be widely
> > supported
> >
> 
> This was recently raised at the No Time To Wait conference in Budapest, so
> it would be great to see version three as the default!

Yes, i did listen to the conference online, i was just a few hours late so i
could not comment on anything online in realtime (like the ffv1 default version)

Thanks

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

Re: [FFmpeg-devel] [PATCH 001/244] Add a new channel layout API

2019-12-09 Thread Michael Niedermayer 
On Mon, Dec 09, 2019 at 12:36:11AM +0100, Nicolas George wrote:
> Michael Niedermayer (12019-12-09):
> > One problem with unsigned is that in expressions you cannot have negative
> > values, nor can you compare to negative values without casting to signed.
> > That has some risk for producing unexpected behavior bugs
> > 
> > for example 
> > if (ch >= s->nb_channels) {
> > ...
> > } else if (ch < 0)
> > ...
> > 
> > would not work as expected
> 
> I do not see it as a problem, I see it as exactly what we want. If a
> value cannot meaningfully be negative, there is no sense in wasting time
> and code allowing it to be negative and then testing it.
> 
> In the above code, ch should be unsigned too. Or, if it has a good
> reason to be signed (negative values meaning something else?), test them
> first.

mixing unsigned and signed int of course works if one is aware of
* what is signed, what is unsigned
* exact semantics of expressions mixing them
* does not miss any corner cases

OTOH if everything is signed, then the developer does not need to worry
about these things, and its easier to remember "all is signed int" vs.
"these specific fields are unsigned"

What i meant really is
"Its easier to maintain code that is all int, instead of code mixing
 signed and unsigned int"
Sometimes we need unsigned and thats fine, i think though when we dont
"need" it, its better to use plain int. 

Just my oppinion, not objecting to anything

Thanks

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Does the universe only have a finite lifespan? No, its going to go on
forever, its just that you wont like living in it. -- Hiranya Peiri


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

2019-12-09 Thread Nicolas George 
Michael Niedermayer (12019-12-09):
> mixing unsigned and signed int of course works if one is aware of
> * what is signed, what is unsigned
> * exact semantics of expressions mixing them
> * does not miss any corner cases

I think it is reasonable to demand from FFmpeg developers that they know
enough C to be at ease with this.

And for remembering exactly and not missing corner cases, there are
compiler warnings. IIRC they are not enabled in FFmpeg, but they do lead
to a much better code hygiene.

> OTOH if everything is signed, then the developer does not need to worry
> about these things, and its easier to remember "all is signed int" vs.
> "these specific fields are unsigned"

Indeed. Instead, if everything is signed, they have to worry about the
many undefined behaviors attached with signed. Plus the risks that are
not related to UB, like checking that an array index is small enough but
forgetting to check non-negative.

Considering the time you spent recently "fixing" signed integer
overflows, I suspect you may be receptive to the fact that unsigned
arithmetic is entirely specified.

Regards,

-- 
  Nicolas George


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 v2] avfilter/formats: optimize ff_all_formats

2019-12-09 Thread Tomas Härdin 
lör 2019-12-07 klockan 01:06 +0800 skrev Zhao Zhili:
> This is a micro-optimization. Saving almost 200 reallocations makes
> it
> worth a try.
> ---
> fix commit message typo: relocations -> reallocations
> 
>  libavfilter/formats.c | 35 +--
>  1 file changed, 21 insertions(+), 14 deletions(-)
> 
> diff --git a/libavfilter/formats.c b/libavfilter/formats.c
> index 33c64668a0..1af7a1cedd 100644
> --- a/libavfilter/formats.c
> +++ b/libavfilter/formats.c
> @@ -348,23 +348,30 @@ int
> ff_add_channel_layout(AVFilterChannelLayouts **l, uint64_t
> channel_layout)
>  
>  AVFilterFormats *ff_all_formats(enum AVMediaType type)
>  {
> -AVFilterFormats *ret = NULL;
> +AVFilterFormats *ret;
> +int i, count;
>  
> -if (type == AVMEDIA_TYPE_VIDEO) {
> -const AVPixFmtDescriptor *desc = NULL;
> -while ((desc = av_pix_fmt_desc_next(desc))) {
> -if (ff_add_format(&ret, av_pix_fmt_desc_get_id(desc)) <
> 0)
> -return NULL;
> -}
> -} else if (type == AVMEDIA_TYPE_AUDIO) {
> -enum AVSampleFormat fmt = 0;
> -while (av_get_sample_fmt_name(fmt)) {
> -if (ff_add_format(&ret, fmt) < 0)
> -return NULL;
> -fmt++;
> -}
> +if (type == AVMEDIA_TYPE_VIDEO)
> +count = AV_PIX_FMT_NB;
> +else if (type == AVMEDIA_TYPE_AUDIO)
> +count = AV_SAMPLE_FMT_NB;
> +else
> +return NULL;
> +
> +ret = av_mallocz(sizeof(*ret));
> +if (!ret)
> +return NULL;
> +
> +ret->nb_formats = count;
> +ret->formats = av_malloc_array(count, sizeof(*ret->formats));
> +if (!ret->formats) {
> +av_free(ret);
> +return NULL;
>  }
>  
> +for (i = 0; i < count; i++)
> +ret->formats[i] = i;

As far as I can tell this is OK, and it passes FATE. But it just looks
very very wrong. Why does this function even exist if all it
effectively does is return the integers from 0..count-1?

/Tomas

___
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: rename scale.c, h to scale_eval

2019-12-09 Thread Michael Niedermayer 
On Sun, Dec 08, 2019 at 04:47:17PM +0530, Gyan wrote:
> Makes commit msgs less ambiguous.
> 
> Regards,
> Gyan

>  Makefile |   10 +-
>  scale_eval.c |2 +-
>  vf_scale.c   |2 +-
>  vf_scale_cuda.c  |2 +-
>  vf_scale_npp.c   |2 +-
>  vf_scale_vaapi.c |2 +-
>  6 files changed, 10 insertions(+), 10 deletions(-)
> 45f5881be8abef7f4e7507cf8e491bb29455cb5e  
> 0001-avfilter-rename-scale.c-h-to-scale_eval.patch
> From 331496c1746dfe66a893a6fde1b9cfacca100667 Mon Sep 17 00:00:00 2001
> From: Gyan Doshi 
> Date: Sun, 8 Dec 2019 16:42:36 +0530
> Subject: [PATCH] avfilter: rename scale.c,h to scale_eval
> 
> scale.c is too generic; scale_eval is more representative
> ---
>  libavfilter/Makefile  | 10 +-
>  libavfilter/{scale.c => scale_eval.c} |  2 +-
>  libavfilter/{scale.h => scale_eval.h} |  0
>  libavfilter/vf_scale.c|  2 +-
>  libavfilter/vf_scale_cuda.c   |  2 +-
>  libavfilter/vf_scale_npp.c|  2 +-
>  libavfilter/vf_scale_vaapi.c  |  2 +-
>  7 files changed, 10 insertions(+), 10 deletions(-)
>  rename libavfilter/{scale.c => scale_eval.c} (99%)
>  rename libavfilter/{scale.h => scale_eval.h} (100%)

AVFILTER_SCALE_H should be renamed too

thx

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

"I am not trying to be anyone's saviour, I'm trying to think about the
 future and not be sad" - Elon Musk



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 5/5] avcodec/truespeech: Fix an integer overflow in truespeech_synth()

2019-12-09 Thread Michael Niedermayer 
On Thu, Nov 14, 2019 at 05:34:08PM +0100, Michael Niedermayer wrote:
> Fixes: signed integer overflow: 2147483188 + 2048 cannot be represented in 
> type 'int'
> Fixes: 
> 18741/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_TRUESPEECH_fuzzer-5748950460268544
> 
> Found-by: continuous fuzzing process 
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by: Michael Niedermayer 
> ---
>  libavcodec/truespeech.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

will apply

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

The bravest are surely those who have the clearest vision
of what is before them, glory and danger alike, and yet
notwithstanding go out to meet it. -- Thucydides


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/wmaprodec: Check if the channel sum of all internal contexts match the external

2019-12-09 Thread Michael Niedermayer 
On Tue, Nov 12, 2019 at 11:51:30PM +0100, Michael Niedermayer wrote:
> Fixes: NULL pointer dereference
> Fixes: 
> 18689/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_XMA1_fuzzer-5715114640015360
> 
> Found-by: continuous fuzzing process 
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by: Michael Niedermayer 
> ---
>  libavcodec/wmaprodec.c | 2 ++
>  1 file changed, 2 insertions(+)

will apply patchset

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

No snowflake in an avalanche ever feels responsible. -- Voltaire


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 4/5] avcodec/apedec: Fix 2 integer overflows

2019-12-09 Thread Michael Niedermayer 
On Thu, Nov 14, 2019 at 05:34:07PM +0100, Michael Niedermayer wrote:
> Fixes: signed integer overflow: 2119056926 - -134217728 cannot be represented 
> in type 'int'
> Fixes: 
> 18728/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_APE_fuzzer-5747539563511808
> 
> Found-by: continuous fuzzing process 
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by: Michael Niedermayer 
> ---
>  libavcodec/apedec.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)

will apply

[...]


-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

There will always be a question for which you do not know the correct answer.


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/5] avcodec/wmalosslessdec: Set FF_CODEC_CAP_INIT_CLEANUP

2019-12-09 Thread Michael Niedermayer 
On Thu, Nov 14, 2019 at 05:34:06PM +0100, Michael Niedermayer wrote:
> Fixes: memleaks
> Fixes: 
> 18429/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_WMALOSSLESS_fuzzer-6210814364614656
> Fixes: 
> 18722/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_WMALOSSLESS_fuzzer-5680535690543104
> 
> Found-by: continuous fuzzing process 
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by: Michael Niedermayer 
> ---
>  libavcodec/wmalosslessdec.c | 1 +
>  1 file changed, 1 insertion(+)

will apply

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

In a rich man's house there is no place to spit but his face.
-- Diogenes of Sinope


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 2/7] avcodec/cbs: Check for overflow when assembling fragments

2019-12-09 Thread Andreas Rheinhardt 
Up until now, the various functions for assembling fragments did not
check for overflow in the computation of the size of the output fragment
or whether the size they allocate actually fits into an int (as it must
given that the AVBuffer API is based on size fields of type int).

In order to optimize this, the overflow check is partially done
generically: The size of all the units is just added while checking for
it to be <= INT_MAX - AV_INPUT_BUFFER_PADDING_SIZE. The result is
accessible to the function doing the actual assembling.

Signed-off-by: Andreas Rheinhardt 
---
In case of H.26x, the new allocation might be slightly larger than the
old one (e.g. two units of odd size would be independently rounded down
when multiplying by 3 followed by dividing by two). But that hardly
matters.

 libavcodec/cbs.c   | 10 ++
 libavcodec/cbs_av1.c   |  7 +--
 libavcodec/cbs_h2645.c | 12 +++-
 libavcodec/cbs_jpeg.c  |  9 ++---
 libavcodec/cbs_mpeg2.c |  9 +
 libavcodec/cbs_vp9.c   |  6 --
 6 files changed, 33 insertions(+), 20 deletions(-)

diff --git a/libavcodec/cbs.c b/libavcodec/cbs.c
index 805049404b..e70e11fb99 100644
--- a/libavcodec/cbs.c
+++ b/libavcodec/cbs.c
@@ -343,6 +343,7 @@ static int cbs_write_unit_data(CodedBitstreamContext *ctx,
 int ff_cbs_write_fragment_data(CodedBitstreamContext *ctx,
CodedBitstreamFragment *frag)
 {
+size_t fragment_size;
 int err, i;
 
 for (i = 0; i < frag->nb_units; i++) {
@@ -366,6 +367,15 @@ int ff_cbs_write_fragment_data(CodedBitstreamContext *ctx,
 av_buffer_unref(&frag->data_ref);
 frag->data = NULL;
 
+fragment_size = 0;
+for (i = 0; i < frag->nb_units; i++) {
+if (frag->units[i].data_size > INT_MAX - AV_INPUT_BUFFER_PADDING_SIZE
+   - fragment_size)
+return AVERROR(ERANGE);
+fragment_size += frag->units[i].data_size;
+}
+frag->data_size = fragment_size;
+
 err = ctx->codec->assemble_fragment(ctx, frag);
 if (err < 0) {
 av_log(ctx->log_ctx, AV_LOG_ERROR, "Failed to assemble fragment.\n");
diff --git a/libavcodec/cbs_av1.c b/libavcodec/cbs_av1.c
index bbe4461130..1c51839f16 100644
--- a/libavcodec/cbs_av1.c
+++ b/libavcodec/cbs_av1.c
@@ -1223,13 +1223,9 @@ static int cbs_av1_write_obu(CodedBitstreamContext *ctx,
 static int cbs_av1_assemble_fragment(CodedBitstreamContext *ctx,
  CodedBitstreamFragment *frag)
 {
-size_t size, pos;
+size_t size = frag->data_size, pos;
 int i;
 
-size = 0;
-for (i = 0; i < frag->nb_units; i++)
-size += frag->units[i].data_size;
-
 frag->data_ref = av_buffer_alloc(size + AV_INPUT_BUFFER_PADDING_SIZE);
 if (!frag->data_ref)
 return AVERROR(ENOMEM);
@@ -1243,7 +1239,6 @@ static int 
cbs_av1_assemble_fragment(CodedBitstreamContext *ctx,
 pos += frag->units[i].data_size;
 }
 av_assert0(pos == size);
-frag->data_size = size;
 
 return 0;
 }
diff --git a/libavcodec/cbs_h2645.c b/libavcodec/cbs_h2645.c
index 5f71d80584..4b17780836 100644
--- a/libavcodec/cbs_h2645.c
+++ b/libavcodec/cbs_h2645.c
@@ -1392,11 +1392,13 @@ static int 
cbs_h2645_assemble_fragment(CodedBitstreamContext *ctx,
 av_assert0(frag->units[i].data);
 }
 
-max_size = 0;
-for (i = 0; i < frag->nb_units; i++) {
-// Start code + content with worst-case emulation prevention.
-max_size += 4 + frag->units[i].data_size * 3 / 2;
-}
+// Content with worst-case emulation prevention.
+max_size = frag->data_size + frag->data_size / 2;
+if (frag->nb_units > (int)(INT_MAX - AV_INPUT_BUFFER_PADDING_SIZE
+   - max_size + 3) / 4)
+return AVERROR(ERANGE);
+// Start codes
+max_size += 4 * frag->nb_units;
 
 data = av_realloc(NULL, max_size + AV_INPUT_BUFFER_PADDING_SIZE);
 if (!data)
diff --git a/libavcodec/cbs_jpeg.c b/libavcodec/cbs_jpeg.c
index 2bb6c8d18c..6c131d2e2e 100644
--- a/libavcodec/cbs_jpeg.c
+++ b/libavcodec/cbs_jpeg.c
@@ -391,13 +391,12 @@ static int 
cbs_jpeg_assemble_fragment(CodedBitstreamContext *ctx,
 {
 const CodedBitstreamUnit *unit;
 uint8_t *data;
-size_t size, dp, sp;
+size_t size = frag->data_size, dp, sp;
 int i;
 
-size = 4; // SOI + EOI.
+size += 4; // SOI + EOI.
 for (i = 0; i < frag->nb_units; i++) {
 unit = &frag->units[i];
-size += 2 + unit->data_size;
 if (unit->type == JPEG_MARKER_SOS) {
 for (sp = 0; sp < unit->data_size; sp++) {
 if (unit->data[sp] == 0xff)
@@ -405,6 +404,10 @@ static int 
cbs_jpeg_assemble_fragment(CodedBitstreamContext *ctx,
 }
 }
 }
+if (frag->nb_units > (int)(INT_MAX - AV_INPUT_BUFFER_PADDING_SIZE
+   - size + 1) / 2)
+return AVERROR(ERANGE);
+size += 2 * frag->nb_units;
 
 fra

[FFmpeg-devel] [PATCH 3/7] avcodec/cbs_h2645: Remove redundant assert

2019-12-09 Thread Andreas Rheinhardt 
cbs_h2645_assemble_fragment() asserted that every unit of the fragment
that should be written contain data; yet this is also asserted
generically in ff_cbs_write_fragment_data(). So drop the redundant
assert.

Signed-off-by: Andreas Rheinhardt 
---
 libavcodec/cbs_h2645.c | 5 -
 1 file changed, 5 deletions(-)

diff --git a/libavcodec/cbs_h2645.c b/libavcodec/cbs_h2645.c
index 4b17780836..7c92ae4871 100644
--- a/libavcodec/cbs_h2645.c
+++ b/libavcodec/cbs_h2645.c
@@ -1387,11 +1387,6 @@ static int 
cbs_h2645_assemble_fragment(CodedBitstreamContext *ctx,
 size_t max_size, dp, sp;
 int err, i, zero_run;
 
-for (i = 0; i < frag->nb_units; i++) {
-// Data should already all have been written when we get here.
-av_assert0(frag->units[i].data);
-}
-
 // Content with worst-case emulation prevention.
 max_size = frag->data_size + frag->data_size / 2;
 if (frag->nb_units > (int)(INT_MAX - AV_INPUT_BUFFER_PADDING_SIZE
-- 
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 1/5] avcodec/agm: Do not allow MVs out of the picture area as no edge is allocated

2019-12-09 Thread Michael Niedermayer 
On Sat, Nov 02, 2019 at 05:05:57PM +0100, Michael Niedermayer wrote:
> Fixes: out of array access
> Fixes: 
> 18499/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_AGM_fuzzer-5749038406434816
> 
> Found-by: continuous fuzzing process 
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by: Michael Niedermayer 
> ---
>  libavcodec/agm.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)

will apply

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

Observe your enemies, for they first find out your faults. -- Antisthenes


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 4/7] avcodec/cbs_vp9: Combine two loops

2019-12-09 Thread Andreas Rheinhardt 
Signed-off-by: Andreas Rheinhardt 
---
 libavcodec/cbs_vp9.c | 8 +++-
 1 file changed, 3 insertions(+), 5 deletions(-)

diff --git a/libavcodec/cbs_vp9.c b/libavcodec/cbs_vp9.c
index ea7747182e..807d066690 100644
--- a/libavcodec/cbs_vp9.c
+++ b/libavcodec/cbs_vp9.c
@@ -581,9 +581,11 @@ static int cbs_vp9_assemble_fragment(CodedBitstreamContext 
*ctx,
 }
 
 max = 0;
-for (i = 0; i < frag->nb_units; i++)
+for (i = 0; i < frag->nb_units; i++) {
+sfi.frame_sizes[i] = frag->units[i].data_size;
 if (max < frag->units[i].data_size)
 max = frag->units[i].data_size;
+}
 
 if (max < 2)
 size_len = 1;
@@ -599,10 +601,6 @@ static int cbs_vp9_assemble_fragment(CodedBitstreamContext 
*ctx,
 if (size > INT_MAX - AV_INPUT_BUFFER_PADDING_SIZE)
 return AVERROR(ERANGE);
 
-for (i = 0; i < frag->nb_units; i++) {
-sfi.frame_sizes[i] = frag->units[i].data_size;
-}
-
 ref = av_buffer_alloc(size + AV_INPUT_BUFFER_PADDING_SIZE);
 if (!ref)
 return AVERROR(ENOMEM);
-- 
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 6/7] avcodec/cbs_h2645: Treat slices without data as invalid

2019-12-09 Thread Andreas Rheinhardt 
Slices that end after their header (meaning slices after the header
without any data before the rbsp_stop_one_bit or possibly without any
rbsp_stop_one_bit at all) are invalid and are now dropped. This ensures
that one doesn't run into two asserts in cbs_h2645_write_slice_data().

Signed-off-by: Andreas Rheinhardt 
---
 libavcodec/cbs_h2645.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/libavcodec/cbs_h2645.c b/libavcodec/cbs_h2645.c
index be82a8cd5f..c66876ea06 100644
--- a/libavcodec/cbs_h2645.c
+++ b/libavcodec/cbs_h2645.c
@@ -855,6 +855,9 @@ static int cbs_h264_read_nal_unit(CodedBitstreamContext 
*ctx,
 if (err < 0)
 return err;
 
+if (!cbs_h2645_read_more_rbsp_data(&gbc))
+return AVERROR_INVALIDDATA;
+
 pos = get_bits_count(&gbc);
 len = unit->data_size;
 
@@ -1030,6 +1033,9 @@ static int cbs_h265_read_nal_unit(CodedBitstreamContext 
*ctx,
 if (err < 0)
 return err;
 
+if (!cbs_h2645_read_more_rbsp_data(&gbc))
+return AVERROR_INVALIDDATA;
+
 pos = get_bits_count(&gbc);
 len = unit->data_size;
 
-- 
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 7/7] avcodec/cbs_mpeg2: Treat slices without data as invalid

2019-12-09 Thread Andreas Rheinhardt 
They are spec-incompliant.

Signed-off-by: Andreas Rheinhardt 
---
 libavcodec/cbs_mpeg2.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/libavcodec/cbs_mpeg2.c b/libavcodec/cbs_mpeg2.c
index e42c602476..b57551c92a 100644
--- a/libavcodec/cbs_mpeg2.c
+++ b/libavcodec/cbs_mpeg2.c
@@ -245,6 +245,9 @@ static int cbs_mpeg2_read_unit(CodedBitstreamContext *ctx,
 if (err < 0)
 return err;
 
+if (!get_bits_left(&gbc))
+return AVERROR_INVALIDDATA;
+
 pos = get_bits_count(&gbc);
 len = unit->data_size;
 
-- 
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 5/7] avcodec/cbs_h2645: Remove dead code to delete trailing zeroes

2019-12-09 Thread Andreas Rheinhardt 
Trailing zeroes are already discarded when splitting a fragment, which
makes the code to remove them when decomposing slices dead code.

Signed-off-by: Andreas Rheinhardt 
---
This of course presupposes that the fragment has been split via
cbs_h2645_split_fragment(). And the current code is buggy even when one
does not make this assumption: The trailing zeroes should be discarded
before one reads the header. And then the GetBitContext needs to
reinitialized (otherwise, some of those trailing zeroes might be
considered valid data when reading the header).

 libavcodec/cbs_h2645.c | 14 --
 1 file changed, 14 deletions(-)

diff --git a/libavcodec/cbs_h2645.c b/libavcodec/cbs_h2645.c
index 7c92ae4871..be82a8cd5f 100644
--- a/libavcodec/cbs_h2645.c
+++ b/libavcodec/cbs_h2645.c
@@ -857,13 +857,6 @@ static int cbs_h264_read_nal_unit(CodedBitstreamContext 
*ctx,
 
 pos = get_bits_count(&gbc);
 len = unit->data_size;
-if (!unit->data[len - 1]) {
-int z;
-for (z = 0; z < len && !unit->data[len - z - 1]; z++);
-av_log(ctx->log_ctx, AV_LOG_DEBUG, "Deleted %d trailing zeroes 
"
-   "from slice data.\n", z);
-len -= z;
-}
 
 slice->data_size = len - pos / 8;
 slice->data_ref  = av_buffer_ref(unit->data_ref);
@@ -1039,13 +1032,6 @@ static int cbs_h265_read_nal_unit(CodedBitstreamContext 
*ctx,
 
 pos = get_bits_count(&gbc);
 len = unit->data_size;
-if (!unit->data[len - 1]) {
-int z;
-for (z = 0; z < len && !unit->data[len - z - 1]; z++);
-av_log(ctx->log_ctx, AV_LOG_DEBUG, "Deleted %d trailing zeroes 
"
-   "from slice data.\n", z);
-len -= z;
-}
 
 slice->data_size = len - pos / 8;
 slice->data_ref  = av_buffer_ref(unit->data_ref);
-- 
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 4/4] swscale/swscale_unscaled: add AV_PIX_FMT_GBRAP10 for LE and BE conversion wrapper

2019-12-09 Thread Michael Niedermayer 
On Thu, Nov 14, 2019 at 10:56:35PM +0100, Michael Niedermayer wrote:
> On Thu, Nov 14, 2019 at 09:46:23PM +0800, lance.lmw...@gmail.com wrote:
> > From: Limin Wang 
> > 
> > Signed-off-by: Limin Wang 
> > ---
> >  libswscale/swscale_unscaled.c | 2 ++
> >  1 file changed, 2 insertions(+)
> 
> probably ok

will apply

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The day soldiers stop bringing you their problems is the day you have stopped 
leading them. They have either lost confidence that you can help or concluded 
you do not care. Either case is a failure of leadership. - Colin Powell


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/2] avformat/rmdec: Initialize and sanity check offset in ivr_read_header()

2019-12-09 Thread Michael Niedermayer 
On Sat, Nov 16, 2019 at 12:10:52AM +0100, Michael Niedermayer wrote:
> Fixes: signed integer overflow: -9223372036854775808 - 17 cannot be 
> represented in type 'long'
> Fixes: 
> 18768/clusterfuzz-testcase-minimized-ffmpeg_DEMUXER_fuzzer-5674385247830016
> 
> Found-by: continuous fuzzing process 
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by: Michael Niedermayer 
> ---
>  libavformat/rmdec.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)

will apply

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

it is not once nor twice but times without number that the same ideas make
their appearance in the world. -- Aristotle


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 2/7] avformat/id3v2: Fix double-free on error

2019-12-09 Thread Michael Niedermayer 
On Sun, Nov 10, 2019 at 05:07:28AM +0100, Andreas Rheinhardt wrote:
> ff_id3v2_parse_priv_dict() uses av_dict_set() with the flags
> AV_DICT_DONT_STRDUP_KEY and AV_DICT_DONT_STRDUP_VAL. In this case both
> key and value are freed on error (and owned by the destination
> dictionary on success), so that freeing them again on error is a
> double-free and therefore forbidden. But it nevertheless happened.
> 
> Fixes CID 1452489 and 1452421.
> 
> Signed-off-by: Andreas Rheinhardt 
> ---
>  libavformat/id3v2.c | 2 --
>  1 file changed, 2 deletions(-)

will apply

thx

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

There will always be a question for which you do not know the correct answer.


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 1/7] avcodec/cbs: Check for overflow when reading

2019-12-09 Thread Andreas Rheinhardt 
While CBS itself uses size_t for sizes, it relies on other APIs that use
int for their sizes; in particular, AVBuffer uses int for their size
parameters and so does GetBitContext with their number of bits. While
CBS aims to be a safe API, the checks it employed were not sufficient to
prevent overflows: E.g. if the size of a unit was > UINT_MAX / 8, 8 *
said size may be truncated to a positive integer before being passed to
init_get_bits() in which case its return value would not indicate an
error.

These checks have been improved to really capture these kinds of errors;
furthermore, although the sizes are still size_t, they are now de-facto
restricted to 0..INT_MAX - AV_INPUT_BUFFER_PADDING_SIZE.

Signed-off-by: Andreas Rheinhardt 
---
The check in cbs_insert_unit() can currently not be triggered, because
av_malloc_array makes sure that it doesn't allocate more than INT_MAX;
so the allocation will fail long before we get even close to INT_MAX.

av1 and H.26x have not been changed, because their split functions
already check the size (in case of H.264 and H.265 this happens in
ff_h2645_packet_split()).

It would btw be possible to open the GetBitContext generically. The
read_unit function would then get the already opened GetBitContext
as a parameter.

 libavcodec/cbs.c   | 6 ++
 libavcodec/cbs_jpeg.c  | 2 +-
 libavcodec/cbs_mpeg2.c | 2 +-
 libavcodec/cbs_vp9.c   | 2 +-
 4 files changed, 9 insertions(+), 3 deletions(-)

diff --git a/libavcodec/cbs.c b/libavcodec/cbs.c
index 0badb192d9..805049404b 100644
--- a/libavcodec/cbs.c
+++ b/libavcodec/cbs.c
@@ -206,6 +206,9 @@ static int cbs_fill_fragment_data(CodedBitstreamContext 
*ctx,
 {
 av_assert0(!frag->data && !frag->data_ref);
 
+if (size > INT_MAX - AV_INPUT_BUFFER_PADDING_SIZE)
+return AVERROR(ERANGE);
+
 frag->data_ref =
 av_buffer_alloc(size + AV_INPUT_BUFFER_PADDING_SIZE);
 if (!frag->data_ref)
@@ -693,6 +696,9 @@ static int cbs_insert_unit(CodedBitstreamContext *ctx,
 memmove(units + position + 1, units + position,
 (frag->nb_units - position) * sizeof(*units));
 } else {
+if (frag->nb_units == INT_MAX)
+return AVERROR(ERANGE);
+
 units = av_malloc_array(frag->nb_units + 1, sizeof(*units));
 if (!units)
 return AVERROR(ENOMEM);
diff --git a/libavcodec/cbs_jpeg.c b/libavcodec/cbs_jpeg.c
index b189cbd9b7..2bb6c8d18c 100644
--- a/libavcodec/cbs_jpeg.c
+++ b/libavcodec/cbs_jpeg.c
@@ -246,7 +246,7 @@ static int cbs_jpeg_read_unit(CodedBitstreamContext *ctx,
 GetBitContext gbc;
 int err;
 
-err = init_get_bits(&gbc, unit->data, 8 * unit->data_size);
+err = init_get_bits8(&gbc, unit->data, unit->data_size);
 if (err < 0)
 return err;
 
diff --git a/libavcodec/cbs_mpeg2.c b/libavcodec/cbs_mpeg2.c
index 13d871cc89..255f033734 100644
--- a/libavcodec/cbs_mpeg2.c
+++ b/libavcodec/cbs_mpeg2.c
@@ -227,7 +227,7 @@ static int cbs_mpeg2_read_unit(CodedBitstreamContext *ctx,
 GetBitContext gbc;
 int err;
 
-err = init_get_bits(&gbc, unit->data, 8 * unit->data_size);
+err = init_get_bits8(&gbc, unit->data, unit->data_size);
 if (err < 0)
 return err;
 
diff --git a/libavcodec/cbs_vp9.c b/libavcodec/cbs_vp9.c
index 42e4dcf5ac..f6cfaa3b36 100644
--- a/libavcodec/cbs_vp9.c
+++ b/libavcodec/cbs_vp9.c
@@ -488,7 +488,7 @@ static int cbs_vp9_read_unit(CodedBitstreamContext *ctx,
 GetBitContext gbc;
 int err, pos;
 
-err = init_get_bits(&gbc, unit->data, 8 * unit->data_size);
+err = init_get_bits8(&gbc, unit->data, unit->data_size);
 if (err < 0)
 return err;
 
-- 
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 1/3] avformat/movenc: write the major brand also as the first compatible brand

2019-12-09 Thread James Almer 
On 12/3/2019 5:00 PM, James Almer wrote:
> On 12/3/2019 5:19 AM, Michael Niedermayer wrote:
>> On Mon, Dec 02, 2019 at 01:18:36PM -0300, James Almer wrote:
>>> Signed-off-by: James Almer 
>>> ---
>>
>>> This is meant to be squashed with patch 2/3, otherwise it will write 
>>> duplicate
>>> compatible brands, and a lot of tests will have to be updated twice.
>>
>> I dont think 2 updates are a problem if it keeps the commits more readable
> 
> Alright.

Will apply this set soon without squashing.
___
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/qsvenc: add Tiles encode support for HEVC

2019-12-09 Thread Fu, Linjie 
> -Original Message-
> From: ffmpeg-devel  On Behalf Of
> Zhong Li
> Sent: Sunday, December 8, 2019 16:32
> To: FFmpeg development discussions and patches  de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH] lavc/qsvenc: add Tiles encode support
> for HEVC
> 
> Linjie Fu  于2019年11月26日周二 下午12:04写道：
> >
> > Add -tile_rows and -tile_cols option to specify the number of tile rows
> > and columns for ICL+ (gen 11) platform.
> >
> > A tile must wholly contain all the slices within it. Slices cannot cross
> > tile boundaries. So the slice number would be implicitly resized to the
> > max(nSlice, nTile).
> >
> > Example:
> > ffmpeg -v verbose -hwaccel qsv -init_hw_device qsv=hw
> > -filter_hw_device hw -f rawvideo -s:v 1920x1080 -i ./input.nv12 -vf
> > format=nv12,hwupload=extra_hw_frames=64 -c:v hevc_qsv -tile_rows 2
> > -tile_cols 2 -slices 4 -y output.h265
> >
> > Also dump the actual quantity of encoded tiled rows and columns in run
> > time.
> >
> > Fix the enhancement #8400.
> >
> > Signed-off-by: Linjie Fu 
> > ---
> >  libavcodec/qsvenc.c  | 32 +++-
> >  libavcodec/qsvenc.h  |  7 +++
> >  libavcodec/qsvenc_hevc.c |  3 +++
> >  3 files changed, 41 insertions(+), 1 deletion(-)
> >
> > diff --git a/libavcodec/qsvenc.c b/libavcodec/qsvenc.c
> > index e176d57..64814fc 100644
> > --- a/libavcodec/qsvenc.c
> > +++ b/libavcodec/qsvenc.c
> > @@ -139,6 +139,9 @@ static void dump_video_param(AVCodecContext
> *avctx, QSVEncContext *q,
> >  #if QSV_HAVE_CO3
> >  mfxExtCodingOption3 *co3 = (mfxExtCodingOption3*)coding_opts[2];
> >  #endif
> > +#if QSV_HAVE_EXT_HEVC_TILES
> > +mfxExtHEVCTiles *exthevctiles = (mfxExtHEVCTiles *)coding_opts[3 +
> QSV_HAVE_CO_VPS];
> > +#endif
> >
> >  av_log(avctx, AV_LOG_VERBOSE, "profile: %s; level: %"PRIu16"\n",
> > print_profile(info->CodecProfile), info->CodecLevel);
> > @@ -204,6 +207,12 @@ static void dump_video_param(AVCodecContext
> *avctx, QSVEncContext *q,
> >  av_log(avctx, AV_LOG_VERBOSE, "RateDistortionOpt: %s\n",
> > print_threestate(co->RateDistortionOpt));
> >
> > +#if QSV_HAVE_EXT_HEVC_TILES
> > +if (avctx->codec_id == AV_CODEC_ID_HEVC)
> > +av_log(avctx, AV_LOG_VERBOSE, "NumTileColumns: %"PRIu16";
> NumTileRows: %"PRIu16"\n",
> > +   exthevctiles->NumTileColumns, exthevctiles->NumTileRows);
> > +#endif
> > +
> >  #if QSV_HAVE_CO2
> >  av_log(avctx, AV_LOG_VERBOSE,
> > "RecoveryPointSEI: %s IntRefType: %"PRIu16";
> IntRefCycleSize: %"PRIu16"; IntRefQPDelta: %"PRId16"\n",
> > @@ -771,6 +780,16 @@ FF_ENABLE_DEPRECATION_WARNINGS
> >  }
> >  #endif
> >
> > +#if QSV_HAVE_EXT_HEVC_TILES
> > +if (avctx->codec_id == AV_CODEC_ID_HEVC) {
> > +q->exthevctiles.Header.BufferId = MFX_EXTBUFF_HEVC_TILES;
> > +q->exthevctiles.Header.BufferSz = sizeof(q->exthevctiles);
> > +q->exthevctiles.NumTileColumns  = q->tile_cols;
> > +q->exthevctiles.NumTileRows = q->tile_rows;
> > +q->extparam_internal[q->nb_extparam_internal++] = (mfxExtBuffer
> *)&q->exthevctiles;
> > +}
> > +#endif
> > +
> >  if (!check_enc_param(avctx,q)) {
> >  av_log(avctx, AV_LOG_ERROR,
> > "some encoding parameters are not supported by the QSV "
> > @@ -887,7 +906,14 @@ static int
> qsv_retrieve_enc_params(AVCodecContext *avctx, QSVEncContext *q)
> >  };
> >  #endif
> >
> > -mfxExtBuffer *ext_buffers[2 + QSV_HAVE_CO2 + QSV_HAVE_CO3 +
> QSV_HAVE_CO_VPS];
> > +#if QSV_HAVE_EXT_HEVC_TILES
> > +mfxExtHEVCTiles hevc_tile_buf = {
> > + .Header.BufferId = MFX_EXTBUFF_HEVC_TILES,
> > + .Header.BufferSz = sizeof(hevc_tile_buf),
> > +};
> > +#endif
> > +
> > +mfxExtBuffer *ext_buffers[2 + QSV_HAVE_CO2 + QSV_HAVE_CO3 +
> QSV_HAVE_CO_VPS + QSV_HAVE_EXT_HEVC_TILES];
> 
> Should be checked with #if QSV_HAVE_EXT_HEVC_TILES""

Hi,

IMHO the check may be redundant. If  the version of MSDK  < 1.13,
QSV_HAVE_EXT_HEVC_TILES equals 0,  above expression is identical to
mfxExtBuffer *ext_buffers[2 + QSV_HAVE_CO2 + QSV_HAVE_CO3 + QSV_HAVE_CO_VPS + 
0];

And there is no version check for CO2/CO3/VPS.

> The reset LGTM.

Thanks for the review.

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

[FFmpeg-devel] [PATCH] libavformat/tls_libtls: handle TLS_WANT_POLLIN and TLS_WANT_POLLOUT return values

2019-12-09 Thread Michael Forney 
These values may be returned from libtls (even in the case of blocking
file descriptors) when we need to read/write more TLS record data in
order to read/write application data.

The URLProtocol documentation says AVERROR(EAGAIN) should be returned
in these cases.

Signed-off-by: Michael Forney 
---
 libavformat/tls_libtls.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/libavformat/tls_libtls.c b/libavformat/tls_libtls.c
index ba83b56ffe..286454e452 100644
--- a/libavformat/tls_libtls.c
+++ b/libavformat/tls_libtls.c
@@ -159,6 +159,8 @@ static int ff_tls_read(URLContext *h, uint8_t *buf, int 
size)
 return ret;
 else if (ret == 0)
 return AVERROR_EOF;
+else if (ret == TLS_WANT_POLLIN || ret == TLS_WANT_POLLOUT)
+return AVERROR(EAGAIN);
 av_log(h, AV_LOG_ERROR, "%s\n", tls_error(p->ctx));
 return AVERROR(EIO);
 }
@@ -172,6 +174,8 @@ static int ff_tls_write(URLContext *h, const uint8_t *buf, 
int size)
 return ret;
 else if (ret == 0)
 return AVERROR_EOF;
+else if (ret == TLS_WANT_POLLIN || ret == TLS_WANT_POLLOUT)
+return AVERROR(EAGAIN);
 av_log(h, AV_LOG_ERROR, "%s\n", tls_error(p->ctx));
 return AVERROR(EIO);
 }
-- 
2.24.0

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

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

Re: [FFmpeg-devel] [PATCH V4 0/2] Enable other srt options.

2019-12-09 Thread myp...@gmail.com 
Ping

On Wed, Dec 4, 2019 at 10:13 PM Jun Zhao  wrote:
>
> V4: - changed the option enforced_encryption type from int to bool.
>   tks Michael & Moritz's comments.
> - add range info in the docs. tks Gyan's comments.
>
> V3: - add more details for linger options. tks Andriy Gelman's comments.
> - fix minor typo in commit message.
>
> V2: - correct the commit message.
>
> Jun Zhao (2):
>   lavf/libsrt: add linger parameter to libsrt
>   lavf/libsrt: enable other encryption parameters
>
>  doc/protocols.texi   |   26 ++
>  libavformat/libsrt.c |   31 +++
>  2 files changed, 57 insertions(+), 0 deletions(-)
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

[FFmpeg-devel] [PATCH 1/3] avformat/apc: Remove unnecessary resetting of flags

2019-12-09 Thread Andreas Rheinhardt 
The packet a demuxer receives is freshly initialized, hence it is
unnecessary to reset any flags on them (as none are set), yet apc did
this.

Signed-off-by: Andreas Rheinhardt 
---
 libavformat/apc.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/libavformat/apc.c b/libavformat/apc.c
index 835d1b0f6e..571726affb 100644
--- a/libavformat/apc.c
+++ b/libavformat/apc.c
@@ -78,7 +78,6 @@ static int apc_read_packet(AVFormatContext *s, AVPacket *pkt)
 {
 if (av_get_packet(s->pb, pkt, MAX_READ_SIZE) <= 0)
 return AVERROR(EIO);
-pkt->flags &= ~AV_PKT_FLAG_CORRUPT;
 pkt->stream_index = 0;
 return 0;
 }
-- 
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 3/3] avformat/iff: Use ff_alloc_extradata

2019-12-09 Thread Andreas Rheinhardt 
Besides improved readability it also zeroes the padding which has been
forgotten here.

Signed-off-by: Andreas Rheinhardt 
---
 libavformat/iff.c | 15 +++
 1 file changed, 7 insertions(+), 8 deletions(-)

diff --git a/libavformat/iff.c b/libavformat/iff.c
index 2a3729f97e..9cee31a86b 100644
--- a/libavformat/iff.c
+++ b/libavformat/iff.c
@@ -525,10 +525,10 @@ static int iff_read_header(AVFormatContext *s)
 data_size);
  return AVERROR_INVALIDDATA;
 }
-st->codecpar->extradata_size = data_size + IFF_EXTRA_VIDEO_SIZE;
-st->codecpar->extradata  = av_malloc(data_size + 
IFF_EXTRA_VIDEO_SIZE + AV_INPUT_BUFFER_PADDING_SIZE);
-if (!st->codecpar->extradata)
-return AVERROR(ENOMEM);
+res = ff_alloc_extradata(st->codecpar,
+ data_size + IFF_EXTRA_VIDEO_SIZE);
+if (res < 0)
+return res;
 if (avio_read(pb, st->codecpar->extradata + IFF_EXTRA_VIDEO_SIZE, 
data_size) < 0) {
 av_freep(&st->codecpar->extradata);
 st->codecpar->extradata_size = 0;
@@ -771,10 +771,9 @@ static int iff_read_header(AVFormatContext *s)
 iff->transparency = transparency;
 
 if (!st->codecpar->extradata) {
-st->codecpar->extradata_size = IFF_EXTRA_VIDEO_SIZE;
-st->codecpar->extradata  = av_malloc(IFF_EXTRA_VIDEO_SIZE + 
AV_INPUT_BUFFER_PADDING_SIZE);
-if (!st->codecpar->extradata)
-return AVERROR(ENOMEM);
+int ret = ff_alloc_extradata(st->codecpar, IFF_EXTRA_VIDEO_SIZE);
+if (ret < 0)
+return ret;
 }
 av_assert0(st->codecpar->extradata_size >= IFF_EXTRA_VIDEO_SIZE);
 buf = st->codecpar->extradata;
-- 
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] avformat/flvenc: Don't reimplement ff_alloc_extradata

2019-12-09 Thread Andreas Rheinhardt 
Signed-off-by: Andreas Rheinhardt 
---
 libavformat/flvenc.c | 10 +++---
 1 file changed, 3 insertions(+), 7 deletions(-)

diff --git a/libavformat/flvenc.c b/libavformat/flvenc.c
index 872050a74f..862082dd2d 100644
--- a/libavformat/flvenc.c
+++ b/libavformat/flvenc.c
@@ -908,14 +908,10 @@ static int flv_write_packet(AVFormatContext *s, AVPacket 
*pkt)
 int side_size = 0;
 uint8_t *side = av_packet_get_side_data(pkt, 
AV_PKT_DATA_NEW_EXTRADATA, &side_size);
 if (side && side_size > 0 && (side_size != par->extradata_size || 
memcmp(side, par->extradata, side_size))) {
-av_free(par->extradata);
-par->extradata = av_mallocz(side_size + 
AV_INPUT_BUFFER_PADDING_SIZE);
-if (!par->extradata) {
-par->extradata_size = 0;
-return AVERROR(ENOMEM);
-}
+ret = ff_alloc_extradata(par, side_size);
+if (ret < 0)
+return ret;
 memcpy(par->extradata, side, side_size);
-par->extradata_size = side_size;
 flv_write_codec_header(s, par, pkt->dts);
 }
 }
-- 
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] lavf/movenc: Replace dts by pts to calculate duration

2019-12-09 Thread manuelyuan 
 I opened a ticket in https://trac.ffmpeg.org/ticket/8420
 my patch may be not absolutely right, but this problem should get your 
attention, thank you

At 2019-12-03 20:57:44, "Martin Storsjö"  wrote:
>On Thu, 28 Nov 2019, manuelyuan wrote:
>
>> There are many UGC videos with dynamic frame rates, which are represented by
>> PTS jumps. After transcoding with ffmpeg -vsync 0 or -vsync 2, the output
>> video duration becomes longer.
>
>Did you post any reproduction case of what, exactly (which field in which 
>box), you think is wrong?
>
>Right now, this patch, among other things, breaks the implied last 
>duration of the last packet in a fragment.
>
>This can be reproduced by with the lavf-movenc test, like this:
>$ make libavformat/tests/movenc
>$ libavformat/tests/movenc -w
>
>Then inspect vfr-noduration.mp4 (with a suitable tool, e.g. L-SMASH's 
>boxdumper). Previously, the last packet in each fragment got an 
>inferred/guessed duration (if the duration field of the AVFrame was zero) 
>based on earlier frame intervals, but with your patch it is zero.
>
>I'm fairly convinced that most of the changes in your patch shouldn't be 
>made, but to make the discussion proceed you need to _exactly_ specify 
>what you think is wrong, in a way that others can reproduce.
>
>// Martin
>
>___
>ffmpeg-devel mailing list
>ffmpeg-devel@ffmpeg.org
>https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
>To unsubscribe, visit link above, or email
>ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [PATCH] avfilter: rename scale.c, h to scale_eval

2019-12-09 Thread Gyan 



On 10-12-2019 03:12 am, Michael Niedermayer wrote:

On Sun, Dec 08, 2019 at 04:47:17PM +0530, Gyan wrote:

Makes commit msgs less ambiguous.

Regards,
Gyan
  Makefile |   10 +-
  scale_eval.c |2 +-
  vf_scale.c   |2 +-
  vf_scale_cuda.c  |2 +-
  vf_scale_npp.c   |2 +-
  vf_scale_vaapi.c |2 +-
  6 files changed, 10 insertions(+), 10 deletions(-)
45f5881be8abef7f4e7507cf8e491bb29455cb5e  
0001-avfilter-rename-scale.c-h-to-scale_eval.patch
 From 331496c1746dfe66a893a6fde1b9cfacca100667 Mon Sep 17 00:00:00 2001
From: Gyan Doshi 
Date: Sun, 8 Dec 2019 16:42:36 +0530
Subject: [PATCH] avfilter: rename scale.c,h to scale_eval

scale.c is too generic; scale_eval is more representative
---
  libavfilter/Makefile  | 10 +-
  libavfilter/{scale.c => scale_eval.c} |  2 +-
  libavfilter/{scale.h => scale_eval.h} |  0
  libavfilter/vf_scale.c|  2 +-
  libavfilter/vf_scale_cuda.c   |  2 +-
  libavfilter/vf_scale_npp.c|  2 +-
  libavfilter/vf_scale_vaapi.c  |  2 +-
  7 files changed, 10 insertions(+), 10 deletions(-)
  rename libavfilter/{scale.c => scale_eval.c} (99%)
  rename libavfilter/{scale.h => scale_eval.h} (100%)

AVFILTER_SCALE_H should be renamed too

Done and pushed as e73688eff43727eb79eb344a4def49540d463902

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

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