Re: [FFmpeg-devel] [PATCH v2] avfilter/vf_edgedetect: properly implement double_threshold()

[Andriy Gelman]

On Mon, 06. Jul 16:02, Andriy Gelman wrote:
> Hi Alex,
> Thanks for testing.
> 
> On Mon, 6 Jul 2020 at 14:49, Alexander Strasser  wrote:
> 
> > On 2020-07-04 23:19 -0400, Andriy Gelman wrote:
> > > On Sun, 05. Jul 09:37, lance.lmw...@gmail.com wrote:
> > > > On Sat, Jul 04, 2020 at 01:03:48PM -0400, Andriy Gelman wrote:
> > > > > On Mon, 29. Jun 09:26, Valery Kot wrote:
> > > > > > On Sun, Jun 28, 2020 at 12:03 AM Andriy Gelman <
> > andriy.gel...@gmail.com> wrote:
> > > > > > >
> > > > > > > lgtm. I saw a small improvement when testing.
> > > > > > >
> > > > > > > Would be nice to allow weak edges that become strong to trigger
> > neighboring weak
> > > > > > > edges in the future.
> > > > > >
> > > > > > Thanks for the comment.
> > > > > >
> > > > > > You are right, ideally double_threshold should be recursive (seed
> > from
> > > > > > each "high" peak and spread over "low" peaks). But then
> > potentially we
> > > > > > may end up with width*height/2 recursion depth, which may lead to
> > > > > > stack overflow. So probably some recursion limit is needed, and
> > hence
> > > > > > suboptimal solution.
> > > > > >
> > > > > > Or iterative approach, running through the complete image again and
> > > > > > again checking if "low" peaks are touching already selected edge
> > > > > > pixels. Stop when no new pixels can be added to the edge. Better,
> > but
> > > > > > still potentially width*height/2 iterations with width*height
> > > > > > operations each, completely killing performance.
> > > > > >
> > > > > > Maybe later I'll try to implement it in a generic way, but this is
> > out
> > > > > > of scope for this patch.
> > > > > >
> > > > > > Regards,
> > > > > >
> > > > > > Valery Kot
> > > > >
> > > > > Any objections if I apply this patch?
> > >
> > > >
> > > > The patch look fine to me, but no sign-off?
> > > >
> > >
> > > Thanks, will add one.
> >
> > I guess it's OK to push. In my few tests for some cases it looked
> > a bit better.
> >
> > I didn't understand why this doesn't make things worse for the
> > outermost frame of pixels, but Valery commented it wouldn't make
> > any difference because of the surrounding code.
> >
> > I just looked at that function and because it checks all the eight
> > surrounding pixels, I thought we might now miss cases that wouldn't
> > have been missed before. Should of course be usually be better for
> > most pictures.
> 
> 
> The point of the first check is to skip pixels on the boundary so that the
> surrounding pixels check does not seg fault.
> It was only by luck that src[i] is always zero on the boundary so that the
> surrounding pixels check is not evaluated.
> 
> You could treat pixels on the boundary separately, but I don't think it's
> worth it.

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] [FFmpeg-cvslog] swscale: Add swscale input/output support for X2RGB10LE

[Andriy Gelman]

On Mon, 06. Jul 02:33, Wang, Fei W wrote:
> 
> 
> > -Original Message-
> > From: ffmpeg-devel  On Behalf Of
> > Michael Niedermayer
> > Sent: Monday, July 6, 2020 7:47 AM
> > To: ffmpeg-devel@ffmpeg.org
> > Subject: Re: [FFmpeg-devel] [FFmpeg-cvslog] swscale: Add swscale
> > input/output support for X2RGB10LE
> > 
> > On Fri, Jun 12, 2020 at 04:57:30PM +, Fei Wang wrote:
> > > ffmpeg | branch: master | Fei Wang  | Wed Apr 22
> > > 13:23:02 2020 +0800| [c721b450141d6bbe1e977212a0bcb70118965c34] |
> > > committer: Lynne
> > >
> > > swscale: Add swscale input/output support for X2RGB10LE
> > >
> > > Signed-off-by: Fei Wang 
> > >
> > > > http://git.videolan.org/gitweb.cgi/ffmpeg.git/?a=commit;h=c721b45014
> > > > 1d6bbe1e977212a0bcb70118965c34
> > > ---
> > >
> > >  libswscale/input.c   | 13 -
> > >  libswscale/output.c  | 14 ++
> > >  libswscale/utils.c   |  1 +
> > >  libswscale/yuv2rgb.c | 22 ++
> > >  tests/ref/fate/filter-pixfmts-copy   |  1 +
> > >  tests/ref/fate/filter-pixfmts-crop   |  1 +
> > >  tests/ref/fate/filter-pixfmts-field  |  1 +
> > >  tests/ref/fate/filter-pixfmts-fieldorder |  1 +
> > >  tests/ref/fate/filter-pixfmts-hflip  |  1 +
> > >  tests/ref/fate/filter-pixfmts-il |  1 +
> > >  tests/ref/fate/filter-pixfmts-null   |  1 +
> > >  tests/ref/fate/filter-pixfmts-pad|  1 +
> > >  tests/ref/fate/filter-pixfmts-scale  |  1 +
> > >  tests/ref/fate/filter-pixfmts-transpose  |  1 +
> > >  tests/ref/fate/filter-pixfmts-vflip  |  1 +
> > >  15 files changed, 60 insertions(+), 1 deletion(-)
> > 
> > This fails on big endian (mips qemu)
> > 
> > stuff like:
> Thanks, I will try to setup mips qumu to check this. Mostly like it shouldn't 
> execute little endian case on big endian enviroment.
> 
> @Andriy Gelman, I am not sure do we already have big endian test environment 
> in patchwork fate test now? if not, we may consider to add it, so that we can 
> catch the fail before patch merge.

It would be nice to have a big endian test running on the patchwork.
I'll try to set one up.

-- 
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 2/2] avcodec/h26[45]_metadata_bsf: Use separate contexts for reading/writing

[Andreas Rheinhardt]

Mark Thompson:
> On 06/07/2020 01:53, Andreas Rheinhardt wrote:
>> Currently, both bsfs used the same CodedBitstreamContext for reading and
>> writing; as a consequence, the state of the writer's context at the
>> beginning of writing a fragment is exactly the state of the reader after
>> having read the fragment; in particular, the writer might not have
>> encountered one of its active parameter sets yet.
>>
>> This is not nice and may lead to invalid output even when the input
>> is completely spec-compliant: Think of an access unit containing
>> a primary coded picture referencing a PPS with id id (that is known from
>> an earlier access unit/from extradata), then a new version of the PPS
>> with id id and then a redundant coded picture that is also referencing
>> the PPS with id id. This is spec-compliant, as the standard allows to
>> overwrite a PPS with a different PPS in between coded pictures and not
>> only at the beginning of an access unit. In this scenario, the reader
>> would read the primary coded picture with the old PPS and the redundant
>> coded picture with the new PPS (as it should); yet the writer would
>> write both with the new PPS as extradata which might lead to errors or
>> to invalid data being output without any error (e.g. if the two PPS
>> differed in redundant_pic_cnt_present_flag).
>>
>> The above scenario does not directly translate to HEVC as long as one
>> restricts oneself to input with nuh_layer_id == 0 only (as cbs_h265
>> does: it currently strips away any NAL unit with nuh_layer_id > 0 when
>> decomposing); if one doesn't the same issue as above can happen.
>>
>> If one also allowed input packets to contain more than one access unit,
>> issues like the above can happen even without redundant coded
>> pictures/multiple layers.
>>
>> Therefore this commit uses separate contexts for reader and writer.
>>
>> Signed-off-by: Andreas Rheinhardt 
>> ---
>> This is an alternative to James patch [1] which instead uses separate
>> reader and writer parameter sets in the same CodedBitstreamContext.
> 
> I do prefer this approach.
> 
>> The diff would be bigger if it were not for the preceding patch (in this
>> case one would have to choose one of the two contexts to add/delete
>> units and as soon as one has to do this, one notices that none of the
>> two choices make any sense).
>>
>>   libavcodec/h264_metadata_bsf.c | 23 ++-
>>   libavcodec/h265_metadata_bsf.c | 23 ++-
>>   2 files changed, 28 insertions(+), 18 deletions(-)
>>
>> diff --git a/libavcodec/h264_metadata_bsf.c
>> b/libavcodec/h264_metadata_bsf.c
>> index 09aa1765fd..9f081a3879 100644
>> --- a/libavcodec/h264_metadata_bsf.c
>> +++ b/libavcodec/h264_metadata_bsf.c
>> @@ -49,7 +49,8 @@ enum {
>>   typedef struct H264MetadataContext {
>>   const AVClass *class;
>>   -    CodedBitstreamContext *cbc;
>> +    CodedBitstreamContext *cbc_in;
>> +    CodedBitstreamContext *cbc_out;
> 
> The old name "cbc" there was just a placeholder because it couldn't be
> "".  Given that, just "in" and "out" might be nicer, or "read" and
> "write"?  (Feel free to ignore this if you don't agree.)
> 
I opted for "input" and "output", thereby making the naming consistent
with h264_redundant_pps.

- 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 2/2] avcodec/h26[45]_metadata_bsf: Use separate contexts for reading/writing

[James Almer]

On 7/6/2020 6:52 PM, Mark Thompson wrote:
> On 06/07/2020 01:53, Andreas Rheinhardt wrote:
>> Currently, both bsfs used the same CodedBitstreamContext for reading and
>> writing; as a consequence, the state of the writer's context at the
>> beginning of writing a fragment is exactly the state of the reader after
>> having read the fragment; in particular, the writer might not have
>> encountered one of its active parameter sets yet.
>>
>> This is not nice and may lead to invalid output even when the input
>> is completely spec-compliant: Think of an access unit containing
>> a primary coded picture referencing a PPS with id id (that is known from
>> an earlier access unit/from extradata), then a new version of the PPS
>> with id id and then a redundant coded picture that is also referencing
>> the PPS with id id. This is spec-compliant, as the standard allows to
>> overwrite a PPS with a different PPS in between coded pictures and not
>> only at the beginning of an access unit. In this scenario, the reader
>> would read the primary coded picture with the old PPS and the redundant
>> coded picture with the new PPS (as it should); yet the writer would
>> write both with the new PPS as extradata which might lead to errors or
>> to invalid data being output without any error (e.g. if the two PPS
>> differed in redundant_pic_cnt_present_flag).
>>
>> The above scenario does not directly translate to HEVC as long as one
>> restricts oneself to input with nuh_layer_id == 0 only (as cbs_h265
>> does: it currently strips away any NAL unit with nuh_layer_id > 0 when
>> decomposing); if one doesn't the same issue as above can happen.
>>
>> If one also allowed input packets to contain more than one access unit,
>> issues like the above can happen even without redundant coded
>> pictures/multiple layers.
>>
>> Therefore this commit uses separate contexts for reader and writer.
>>
>> Signed-off-by: Andreas Rheinhardt 
>> ---
>> This is an alternative to James patch [1] which instead uses separate
>> reader and writer parameter sets in the same CodedBitstreamContext.
> 
> I do prefer this approach.
> 
>> The diff would be bigger if it were not for the preceding patch (in this
>> case one would have to choose one of the two contexts to add/delete
>> units and as soon as one has to do this, one notices that none of the
>> two choices make any sense).
>>
>>   libavcodec/h264_metadata_bsf.c | 23 ++-
>>   libavcodec/h265_metadata_bsf.c | 23 ++-
>>   2 files changed, 28 insertions(+), 18 deletions(-)
>>
>> diff --git a/libavcodec/h264_metadata_bsf.c
>> b/libavcodec/h264_metadata_bsf.c
>> index 09aa1765fd..9f081a3879 100644
>> --- a/libavcodec/h264_metadata_bsf.c
>> +++ b/libavcodec/h264_metadata_bsf.c
>> @@ -49,7 +49,8 @@ enum {
>>   typedef struct H264MetadataContext {
>>   const AVClass *class;
>>   -    CodedBitstreamContext *cbc;
>> +    CodedBitstreamContext *cbc_in;
>> +    CodedBitstreamContext *cbc_out;
> 
> The old name "cbc" there was just a placeholder because it couldn't be
> "".  Given that, just "in" and "out" might be nicer, or "read" and
> "write"?  (Feel free to ignore this if you don't agree.)
> 
>>   CodedBitstreamFragment access_unit;
>>     int done_first_au;
>> @@ -289,7 +290,7 @@ static int
>> h264_metadata_update_side_data(AVBSFContext *bsf, AVPacket *pkt)
>>   if (!side_data_size)
>>   return 0;
>>   -    err = ff_cbs_read(ctx->cbc, au, side_data, side_data_size);
>> +    err = ff_cbs_read(ctx->cbc_in, au, side_data, side_data_size);
>>   if (err < 0) {
>>   av_log(bsf, AV_LOG_ERROR, "Failed to read extradata from
>> packet side data.\n");
>>   return err;
>> @@ -303,7 +304,7 @@ static int
>> h264_metadata_update_side_data(AVBSFContext *bsf, AVPacket *pkt)
>>   }
>>   }
>>   -    err = ff_cbs_write_fragment_data(ctx->cbc, au);
>> +    err = ff_cbs_write_fragment_data(ctx->cbc_out, au);
>>   if (err < 0) {
>>   av_log(bsf, AV_LOG_ERROR, "Failed to write extradata into
>> packet side data.\n");
>>   return err;
>> @@ -334,7 +335,7 @@ static int h264_metadata_filter(AVBSFContext *bsf,
>> AVPacket *pkt)
>>   if (err < 0)
>>   goto fail;
>>   -    err = ff_cbs_read_packet(ctx->cbc, au, pkt);
>> +    err = ff_cbs_read_packet(ctx->cbc_in, au, pkt);
>>   if (err < 0) {
>>   av_log(bsf, AV_LOG_ERROR, "Failed to read packet.\n");
>>   goto fail;
>> @@ -602,7 +603,7 @@ static int h264_metadata_filter(AVBSFContext *bsf,
>> AVPacket *pkt)
>>   }
>>   }
>>   -    err = ff_cbs_write_packet(ctx->cbc, pkt, au);
>> +    err = ff_cbs_write_packet(ctx->cbc_out, pkt, au);
>>   if (err < 0) {
>>   av_log(bsf, AV_LOG_ERROR, "Failed to write packet.\n");
>>   goto fail;
>> @@ -626,12 +627,15 @@ static int h264_metadata_init(AVBSFContext *bsf)
>>   CodedBitstreamFragment *au = >access_unit;
>>   int err, i;
>>   -    err = ff_cbs_init(>cbc, 

Re: [FFmpeg-devel] [PATCH v1 1/3] doc/developer.texi: Improvements in "Submitting patches" section.

[Jim DeLaHunt]

On 2020-07-05 14:45, Manolis Stamatogiannakis wrote:


The section has been expanded to outline how to manage patch revisions.
---
  doc/developer.texi | 37 ++---
  1 file changed, 26 insertions(+), 11 deletions(-)



Thank you for taking the time to improve the documentation about how to 
submit patches. Once these changes are accepted, you will have smoothed 
the way for many other developers.


  —Jim DeLaHunt, software engineer, Vancouver, Canada



___
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/isom: allow ISO 639 codes for mov

[Baptiste Coudurier]

Hi Yongle, I hope you are doing well

> On Jul 6, 2020, at 11:04 AM, Yongle Lin  wrote:
> 
> On Fri, Jun 19, 2020 at 5:11 PM Yongle Lin  > wrote:
> 
>> Allow ISO 639 language codes for text tracks in mov format when
>> strictness is set to experimental
>> ---
>> libavformat/isom.c | 9 +++--
>> libavformat/isom.h | 2 +-
>> libavformat/movenc.c   | 6 +++---
>> tests/fate/mov.mak | 3 +++
>> tests/ref/fate/mov-iso639-lang | 4 
>> 5 files changed, 18 insertions(+), 6 deletions(-)
>> create mode 100644 tests/ref/fate/mov-iso639-lang
>> 
>> diff --git a/libavformat/isom.c b/libavformat/isom.c
>> index 44c7b13038..de20ea8d8b 100644
>> --- a/libavformat/isom.c
>> +++ b/libavformat/isom.c
>> @@ -416,7 +416,7 @@ static const char mov_mdhd_language_map[][4] = {
>> "cat", "lat", "que", "grn", "aym", "tat", "uig", "dzo", "jav"
>> };
>> 
>> -int ff_mov_iso639_to_lang(const char lang[4], int mp4)
>> +int ff_mov_iso639_to_lang(const char lang[4], int mp4, int
>> strict_std_compliance)
>> {
>> int i, code = 0;
>> 
>> @@ -426,8 +426,13 @@ int ff_mov_iso639_to_lang(const char lang[4], int mp4)
>> return i;
>> }
>> /* XXX:can we do that in mov too? */
>> -if (!mp4)
>> +if (!mp4 && (strict_std_compliance != FF_COMPLIANCE_EXPERIMENTAL ||
>> !strcmp(lang, "und"))) {
>> +if (strcmp(lang, "und"))
>> +av_log(NULL, AV_LOG_WARNING, "Non macintosh language is
>> discarded for mov\n");
>> return -1;
>> +}
>> +if (!mp4)
>> +av_log(NULL, AV_LOG_WARNING, "Experimental behavior: enable iso
>> 639 language in mov\n");
>> /* handle undefined as such */
>> if (lang[0] == '\0')
>> lang = "und";
>> diff --git a/libavformat/isom.h b/libavformat/isom.h
>> index 41a9c64c11..9d018ebf1f 100644
>> --- a/libavformat/isom.h
>> +++ b/libavformat/isom.h
>> @@ -43,7 +43,7 @@ extern const AVCodecTag ff_codec_movaudio_tags[];
>> extern const AVCodecTag ff_codec_movsubtitle_tags[];
>> extern const AVCodecTag ff_codec_movdata_tags[];
>> 
>> -int ff_mov_iso639_to_lang(const char lang[4], int mp4);
>> +int ff_mov_iso639_to_lang(const char lang[4], int mp4, int
>> strict_std_compliance);
>> int ff_mov_lang_to_iso639(unsigned code, char to[4]);
>> 
>> struct AVAESCTR;
>> diff --git a/libavformat/movenc.c b/libavformat/movenc.c
>> index 520aaafb74..4d7a98245e 100644
>> --- a/libavformat/movenc.c
>> +++ b/libavformat/movenc.c
>> @@ -3429,7 +3429,7 @@ static int mov_write_string_data_tag(AVIOContext
>> *pb, const char *data, int lang
>> return size;
>> } else {
>> if (!lang)
>> -lang = ff_mov_iso639_to_lang("und", 1);
>> +lang = ff_mov_iso639_to_lang("und", 1, FF_COMPLIANCE_NORMAL);
>> avio_wb16(pb, strlen(data)); /* string length */
>> avio_wb16(pb, lang);
>> avio_write(pb, data, strlen(data));
>> @@ -3468,7 +3468,7 @@ static AVDictionaryEntry
>> *get_metadata_lang(AVFormatContext *s,
>> while ((t2 = av_dict_get(s->metadata, tag2, t2,
>> AV_DICT_IGNORE_SUFFIX))) {
>> len2 = strlen(t2->key);
>> if (len2 == len + 4 && !strcmp(t->value, t2->value)
>> -&& (l = ff_mov_iso639_to_lang(>key[len2 - 3], 1)) >= 0) {
>> +&& (l = ff_mov_iso639_to_lang(>key[len2 - 3], 1,
>> s->strict_std_compliance)) >= 0) {
>> *lang = l;
>> return t;
>> }
>> @@ -6445,7 +6445,7 @@ static int mov_init(AVFormatContext *s)
>> 
>> track->st  = st;
>> track->par = st->codecpar;
>> -track->language = ff_mov_iso639_to_lang(lang?lang->value:"und",
>> mov->mode!=MODE_MOV);
>> +track->language = ff_mov_iso639_to_lang(lang?lang->value:"und",
>> mov->mode!=MODE_MOV, s->strict_std_compliance);
>> if (track->language < 0)
>> track->language = 32767;  // Unspecified Macintosh language
>> code
>> track->mode = mov->mode;
>> diff --git a/tests/fate/mov.mak b/tests/fate/mov.mak
>> index 7a721d7c95..a85cc1a07d 100644
>> --- a/tests/fate/mov.mak
>> +++ b/tests/fate/mov.mak
>> @@ -29,6 +29,7 @@ FATE_MOV_FFPROBE = fate-mov-neg-firstpts-discard \
>>fate-mov-guess-delay-2 \
>>fate-mov-guess-delay-3 \
>>fate-mov-mp4-with-mov-in24-ver \
>> +   fate-mov-iso639-lang \
>> 
>> FATE_MOV_FASTSTART = fate-mov-faststart-4gb-overflow \
>> 
>> @@ -124,3 +125,5 @@ fate-mov-faststart-4gb-overflow: CMP = oneline
>> fate-mov-faststart-4gb-overflow: REF = bc875921f151871e787c4b4023269b29
>> 
>> fate-mov-mp4-with-mov-in24-ver: CMD = run ffprobe$(PROGSSUF)$(EXESUF)
>> -show_entries stream=codec_name -select_streams 1
>> $(TARGET_SAMPLES)/mov/mp4-with-mov-in24-ver.mp4
>> +
>> +fate-mov-iso639-lang: CMD = ffmpeg$(PROGSSUF)$(EXESUF) -f lavfi -i
>> sine=frequency=1000:duration=15 -strict experimental -metadata:s:a:0
>> language=deu -y $(TARGET_PATH)/metadata.mov; run ffprobe -show_entries

Re: [FFmpeg-devel] [PATCH v06 2/5] fbtile helperRoutines cpu based framebuffer detiling

[Mark Thompson]

On 06/07/2020 00:30, Lynne wrote:

Jul 5, 2020, 23:47 by s...@jkqxz.net:


On 04/07/2020 14:17, hanishkvc wrote:


Add helper routines which can be used to detile tiled framebuffer
layouts into a linear layout, using the cpu.

Currently it supports Legacy Intel Tile-X, Legacy Intel Tile-Y and
Newer Intel Tile-Yf tiled layouts.

Currently supported pixel format is 32bit RGB.

It also contains detile_generic logic, which can be easily configured
to support different kinds of tiling layouts, at the expense of some
processing speed, compared to developing a targeted detiling logic.
---
  libavutil/Makefile |   2 +
  libavutil/fbtile.c | 441 +
  libavutil/fbtile.h | 228 +++
  3 files changed, 671 insertions(+)
  create mode 100644 libavutil/fbtile.c
  create mode 100644 libavutil/fbtile.h



I do think this is a reasonable thing to include in FFmpeg, but please think 
about what you actually want as a public API here.

Ideally you want to minimise the public API surface while providing something 
clean and of general use.

So:
- It should probably operate on whole frames - copying pieces of frames or 
single planes doesn't have any obvious use.
- The pixel format, width, height and pitches will all need to be specified, so 
AVFrames which already include that information are probably the right 
structure to use.
- You want to specify a tiling mode for the source frame somehow.
- For the untile case the destination is linear, but a plausible use-case is 
the opposite so we could include tiling mode for the destination as well.
- The tiling modes will need to be some sort of enum, since they are all ad-hoc 
setups for particular hardware vendors.
- We can't reuse existing values like those from libdrm because we'd like it to 
work everywhere it can and there is no intrinsic dependence on libdrm, so it 
needs to be a new enum.
- Names for the tiling modes should be valid everywhere, so if they are 
platform-dependent (like Intel X/Y tiling) then the platform will need to be 
included in the name.
- Linear should be in the tiling mode enum, so that you don't need special 
cases elsewhere.
- All the dispatch between different implementations can happen internally, so 
it doesn't need to be exposed.
- Not everything will actually be implemented, so it will need to be able to 
return an error indicating that a particular case is not available.

Given that, I make the desired public API to be exactly one enum and one 
function.  It would look something like:

enum AVTilingMode {
  AV_TILING_MODE_LINEAR = 0,
  AV_TILING_MODE_INTEL_GEN7_X,
  AV_TILING_MODE_INTEL_GEN7_Y,
  AV_TILING_MODE_INTEL_GEN9_X,
  AV_TILING_MODE_INTEL_GEN9_Y,
  AV_TILING_MODE_INTEL_YF,
};

int av_frame_copy_with_tiling(const AVFrame *dst, enum AVTilingMode dst_tiling,
  const AVFrame *src, enum AVTilingMode src_tiling);


Some other thoughts:
- Functions should all be static unless you are intentionally exposing them as 
public API.
- Libraries must not include mutable globals.
- Note that av_log(NULL, ...) should never be called from a library unless you 
really are in a global context.  I think you probably just don't want to 
include any user-facing logging at all.
- Look at the coding style guide, especially around naming and operator spacing.



Yes, in general those are good guidelines for public APIs.
But please, _don't_ in this case. Really. I've already said its not a good idea 
and I'll reject
future patches that do simply because its a problem exclusive to hwcontext_drm 
and directly
solvable there.


Yeah, that's fair - there isn't really any good reason to make it public unless 
there is another use-case entirely independent from the DRM one.

- Mark
___
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] libavutil/video_enc_params: add block type

[Mark Thompson]

On 06/07/2020 22:08, Yongle Lin wrote:

add block type field to AVVideoBlockParams so we could either export or 
visualize it later.
---
  libavutil/video_enc_params.h | 20 
  1 file changed, 20 insertions(+)

diff --git a/libavutil/video_enc_params.h b/libavutil/video_enc_params.h
index 43fa443154..55b9fc4031 100644
--- a/libavutil/video_enc_params.h
+++ b/libavutil/video_enc_params.h
@@ -101,6 +101,21 @@ typedef struct AVVideoEncParams {
  int32_t delta_qp[4][2];
  } AVVideoEncParams;
  
+typedef struct MacroBlockType {

+/**
+ * Is intra prediction
+ */
+int intra;
+/**
+ * Skip flag
+ */
+int skip;
+/**
+ * Reference to the past or future
+ */
+int ref[2];


Please can you define carefully in the documentation exactly what each of these 
fields mean, as is done for the QP values above?

(That is, there should be enough information to determine what exactly is meant 
if I am given one of these structures with, say, intra = 3, skip = 7, ref = { 
5, 1 }.)


+} MacroBlockType;


Structures in the public API need to carry the "AV" namespace prefix.

I'm not sure that "macroblock" is a good word to use here: many codecs have no concept 
called a "macroblock", and invoking a word with a specific definition in only some 
contexts seems unhelpful.


+
  /**
   * Data structure for storing block-level encoding information.
   * It is allocated as a part of AVVideoEncParams and should be retrieved with
@@ -126,6 +141,11 @@ typedef struct AVVideoBlockParams {
   * corresponding per-frame value.
   */
  int32_t delta_qp;
+
+/**
+ * Type of block
+ */
+MacroBlockType mb_type;
  } AVVideoBlockParams;
  
  /*




- Mark
___
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] avcodec/h26[45]_metadata_bsf: Use separate contexts for reading/writing

[Mark Thompson]

On 06/07/2020 01:53, Andreas Rheinhardt wrote:

Currently, both bsfs used the same CodedBitstreamContext for reading and
writing; as a consequence, the state of the writer's context at the
beginning of writing a fragment is exactly the state of the reader after
having read the fragment; in particular, the writer might not have
encountered one of its active parameter sets yet.

This is not nice and may lead to invalid output even when the input
is completely spec-compliant: Think of an access unit containing
a primary coded picture referencing a PPS with id id (that is known from
an earlier access unit/from extradata), then a new version of the PPS
with id id and then a redundant coded picture that is also referencing
the PPS with id id. This is spec-compliant, as the standard allows to
overwrite a PPS with a different PPS in between coded pictures and not
only at the beginning of an access unit. In this scenario, the reader
would read the primary coded picture with the old PPS and the redundant
coded picture with the new PPS (as it should); yet the writer would
write both with the new PPS as extradata which might lead to errors or
to invalid data being output without any error (e.g. if the two PPS
differed in redundant_pic_cnt_present_flag).

The above scenario does not directly translate to HEVC as long as one
restricts oneself to input with nuh_layer_id == 0 only (as cbs_h265
does: it currently strips away any NAL unit with nuh_layer_id > 0 when
decomposing); if one doesn't the same issue as above can happen.

If one also allowed input packets to contain more than one access unit,
issues like the above can happen even without redundant coded
pictures/multiple layers.

Therefore this commit uses separate contexts for reader and writer.

Signed-off-by: Andreas Rheinhardt 
---
This is an alternative to James patch [1] which instead uses separate
reader and writer parameter sets in the same CodedBitstreamContext.


I do prefer this approach.


The diff would be bigger if it were not for the preceding patch (in this
case one would have to choose one of the two contexts to add/delete
units and as soon as one has to do this, one notices that none of the
two choices make any sense).

  libavcodec/h264_metadata_bsf.c | 23 ++-
  libavcodec/h265_metadata_bsf.c | 23 ++-
  2 files changed, 28 insertions(+), 18 deletions(-)

diff --git a/libavcodec/h264_metadata_bsf.c b/libavcodec/h264_metadata_bsf.c
index 09aa1765fd..9f081a3879 100644
--- a/libavcodec/h264_metadata_bsf.c
+++ b/libavcodec/h264_metadata_bsf.c
@@ -49,7 +49,8 @@ enum {
  typedef struct H264MetadataContext {
  const AVClass *class;
  
-CodedBitstreamContext *cbc;

+CodedBitstreamContext *cbc_in;
+CodedBitstreamContext *cbc_out;


The old name "cbc" there was just a placeholder because it couldn't be "".  Given that, just "in" and 
"out" might be nicer, or "read" and "write"?  (Feel free to ignore this if you don't agree.)


  CodedBitstreamFragment access_unit;
  
  int done_first_au;

@@ -289,7 +290,7 @@ static int h264_metadata_update_side_data(AVBSFContext 
*bsf, AVPacket *pkt)
  if (!side_data_size)
  return 0;
  
-err = ff_cbs_read(ctx->cbc, au, side_data, side_data_size);

+err = ff_cbs_read(ctx->cbc_in, au, side_data, side_data_size);
  if (err < 0) {
  av_log(bsf, AV_LOG_ERROR, "Failed to read extradata from packet side 
data.\n");
  return err;
@@ -303,7 +304,7 @@ static int h264_metadata_update_side_data(AVBSFContext 
*bsf, AVPacket *pkt)
  }
  }
  
-err = ff_cbs_write_fragment_data(ctx->cbc, au);

+err = ff_cbs_write_fragment_data(ctx->cbc_out, au);
  if (err < 0) {
  av_log(bsf, AV_LOG_ERROR, "Failed to write extradata into packet side 
data.\n");
  return err;
@@ -334,7 +335,7 @@ static int h264_metadata_filter(AVBSFContext *bsf, AVPacket 
*pkt)
  if (err < 0)
  goto fail;
  
-err = ff_cbs_read_packet(ctx->cbc, au, pkt);

+err = ff_cbs_read_packet(ctx->cbc_in, au, pkt);
  if (err < 0) {
  av_log(bsf, AV_LOG_ERROR, "Failed to read packet.\n");
  goto fail;
@@ -602,7 +603,7 @@ static int h264_metadata_filter(AVBSFContext *bsf, AVPacket 
*pkt)
  }
  }
  
-err = ff_cbs_write_packet(ctx->cbc, pkt, au);

+err = ff_cbs_write_packet(ctx->cbc_out, pkt, au);
  if (err < 0) {
  av_log(bsf, AV_LOG_ERROR, "Failed to write packet.\n");
  goto fail;
@@ -626,12 +627,15 @@ static int h264_metadata_init(AVBSFContext *bsf)
  CodedBitstreamFragment *au = >access_unit;
  int err, i;
  
-err = ff_cbs_init(>cbc, AV_CODEC_ID_H264, bsf);

+err = ff_cbs_init(>cbc_in,  AV_CODEC_ID_H264, bsf);
+if (err < 0)
+return err;
+err = ff_cbs_init(>cbc_out, AV_CODEC_ID_H264, bsf);
  if (err < 0)
  return err;
  
  if (bsf->par_in->extradata) {

-err = ff_cbs_read_extradata(ctx->cbc, au, bsf->par_in);
+ 

Re: [FFmpeg-devel] [PATCH 1/2] avcodec/cbs: Remove unused function parameters

[Mark Thompson]

On 06/07/2020 01:53, Andreas Rheinhardt wrote:

Several cbs-functions had an unused CodedBitstreamContext parameter.
This commit removes these.


Yeah, the intent was that every call would be attached to a single context for 
logging / debug stuff.  That didn't end up getting any use, so it's fair to 
dump all of the extra parameters.



Signed-off-by: Andreas Rheinhardt 
---
As one sees, removing the ctx parameter from some of these functions
depends on removing it from others. But ff_cbs_alloc_unit_content is
separate from all the others; so if we switched to Mark's
ff_cbs_alloc_unit_content2 [1], one would not need to add this parameter
back for any other function.

[1]: https://ffmpeg.org/pipermail/ffmpeg-devel/2020-May/262042.html


Merging looks like it might be fun :P  I'll rebase and resend that set once 
you've applied this lot.



  libavcodec/av1_frame_merge_bsf.c| 12 
  libavcodec/av1_frame_split_bsf.c| 10 +++---
  libavcodec/av1_metadata_bsf.c   | 14 -
  libavcodec/av1_parser.c |  6 ++--
  libavcodec/cbs.c| 48 -
  libavcodec/cbs.h| 21 +
  libavcodec/cbs_av1.c|  4 +--
  libavcodec/cbs_h264.h   |  6 ++--
  libavcodec/cbs_h2645.c  | 40 
  libavcodec/cbs_jpeg.c   | 10 +++---
  libavcodec/cbs_mpeg2.c  |  6 ++--
  libavcodec/cbs_vp9.c|  6 ++--
  libavcodec/filter_units_bsf.c   |  8 ++---
  libavcodec/h264_metadata_bsf.c  | 24 +++
  libavcodec/h264_redundant_pps_bsf.c |  8 ++---
  libavcodec/h265_metadata_bsf.c  | 13 
  libavcodec/mpeg2_metadata_bsf.c |  8 ++---
  libavcodec/trace_headers_bsf.c  |  6 ++--
  libavcodec/vaapi_encode_h264.c  | 13 
  libavcodec/vaapi_encode_h265.c  | 13 
  libavcodec/vaapi_encode_mjpeg.c | 14 -
  libavcodec/vaapi_encode_mpeg2.c |  9 +++---
  libavcodec/vp9_metadata_bsf.c   |  4 +--
  23 files changed, 138 insertions(+), 165 deletions(-)

...


LGTM.

Thanks,

- Mark
___
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] libavutil/video_enc_params: add block type

[Yongle Lin]

add block type field to AVVideoBlockParams so we could either export or 
visualize it later.
---
 libavutil/video_enc_params.h | 20 
 1 file changed, 20 insertions(+)

diff --git a/libavutil/video_enc_params.h b/libavutil/video_enc_params.h
index 43fa443154..55b9fc4031 100644
--- a/libavutil/video_enc_params.h
+++ b/libavutil/video_enc_params.h
@@ -101,6 +101,21 @@ typedef struct AVVideoEncParams {
 int32_t delta_qp[4][2];
 } AVVideoEncParams;
 
+typedef struct MacroBlockType {
+/**
+ * Is intra prediction
+ */
+int intra;
+/**
+ * Skip flag
+ */
+int skip;
+/**
+ * Reference to the past or future
+ */
+int ref[2];
+} MacroBlockType;
+
 /**
  * Data structure for storing block-level encoding information.
  * It is allocated as a part of AVVideoEncParams and should be retrieved with
@@ -126,6 +141,11 @@ typedef struct AVVideoBlockParams {
  * corresponding per-frame value.
  */
 int32_t delta_qp;
+
+/**
+ * Type of block
+ */
+MacroBlockType mb_type;
 } AVVideoBlockParams;
 
 /*
-- 
2.27.0.383.g050319c2ae-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".

Re: [FFmpeg-devel] Bad language on this mailing list

[Paul B Mahol]

On 7/6/20, Jim DeLaHunt  wrote:
> On 2020-07-04 14:08, Jean-Baptiste Kempf wrote:
>
>> On Sat, Jul 4, 2020, at 20:09, Paul B Mahol wrote:
>>> Why is bad and offensive language tolerated on this mailing list and on
>>> IRC?
>> It is not tolerated.
>> Whatever the reason.
>>
>> --
>> Jean-Baptiste Kempf -  President
>
>
> Jean-Baptiste, with respect, rudeness and offensive language _is_
> tolerated on this mailing list — as measured by the lack of community
> norm enforcement when rudeness appears, and by the lack of visible
> punishment to those who are rude. I think it is especially important for
> the person with "President" after their name to have a clear idea of the
> actual behaviour of the group.
>
> You are the best at attempting to enforce community norms. In a few
> recent threads, you have responded to rudeness by saying that rude
> behaviour is not welcome. That is good. You announced recently that you
> kicked a person off IRC as a consequence of their rude behaviour there.
> That is good. However, it is very mild compared to what I think should
> happen.
>
> None of the multiple instances of rudeness on this list in the last few
> weeks has been met with a wide-spread public rebuke. None have resulted
> in a list member being suspended from the list, or having their code
> commit authority suspended.
>
> Rudeness and offensive language is against the _rules_ of this list and
> of IRC, but it is clearly "tolerated". I wish it were not. I am hopeful
> that setting up the community governance, and forming councils with
> authority to deal with bad behaviour, will improve the situation.

Are you kind of person who prefer censorship?

Rudeness are present on both sides.

> —Jim DeLaHunt, software engineer, Vancouver, Canada
>
>
> ___
> 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] Bad language on this mailing list

[Jim DeLaHunt]

On 2020-07-04 14:08, Jean-Baptiste Kempf wrote:


On Sat, Jul 4, 2020, at 20:09, Paul B Mahol wrote:

Why is bad and offensive language tolerated on this mailing list and on IRC?

It is not tolerated.
Whatever the reason.

--
Jean-Baptiste Kempf -  President



Jean-Baptiste, with respect, rudeness and offensive language _is_ 
tolerated on this mailing list — as measured by the lack of community 
norm enforcement when rudeness appears, and by the lack of visible 
punishment to those who are rude. I think it is especially important for 
the person with "President" after their name to have a clear idea of the 
actual behaviour of the group.


You are the best at attempting to enforce community norms. In a few 
recent threads, you have responded to rudeness by saying that rude 
behaviour is not welcome. That is good. You announced recently that you 
kicked a person off IRC as a consequence of their rude behaviour there. 
That is good. However, it is very mild compared to what I think should 
happen.


None of the multiple instances of rudeness on this list in the last few 
weeks has been met with a wide-spread public rebuke. None have resulted 
in a list member being suspended from the list, or having their code 
commit authority suspended.


Rudeness and offensive language is against the _rules_ of this list and 
of IRC, but it is clearly "tolerated". I wish it were not. I am hopeful 
that setting up the community governance, and forming councils with 
authority to deal with bad behaviour, will improve the situation.

   —Jim DeLaHunt, software engineer, Vancouver, Canada


___
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: add nonlinearstretch filter.

[Mathias Rasmussen]

> On 29 Jun 2020, at 17.33, Mathias Rasmussen  wrote:
> 
> How do I proceed?

If there is no chance this is going to get merged, please let me know.
I’m following the writing filters docs that recommends submitting the filter, 
but I would rather spend my time on a different solution if this is no longer 
the case.
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 v2] avfilter/vf_edgedetect: properly implement double_threshold()

[Andriy Gelman]

Hi Alex,
Thanks for testing.

On Mon, 6 Jul 2020 at 14:49, Alexander Strasser  wrote:

> On 2020-07-04 23:19 -0400, Andriy Gelman wrote:
> > On Sun, 05. Jul 09:37, lance.lmw...@gmail.com wrote:
> > > On Sat, Jul 04, 2020 at 01:03:48PM -0400, Andriy Gelman wrote:
> > > > On Mon, 29. Jun 09:26, Valery Kot wrote:
> > > > > On Sun, Jun 28, 2020 at 12:03 AM Andriy Gelman <
> andriy.gel...@gmail.com> wrote:
> > > > > >
> > > > > > lgtm. I saw a small improvement when testing.
> > > > > >
> > > > > > Would be nice to allow weak edges that become strong to trigger
> neighboring weak
> > > > > > edges in the future.
> > > > >
> > > > > Thanks for the comment.
> > > > >
> > > > > You are right, ideally double_threshold should be recursive (seed
> from
> > > > > each "high" peak and spread over "low" peaks). But then
> potentially we
> > > > > may end up with width*height/2 recursion depth, which may lead to
> > > > > stack overflow. So probably some recursion limit is needed, and
> hence
> > > > > suboptimal solution.
> > > > >
> > > > > Or iterative approach, running through the complete image again and
> > > > > again checking if "low" peaks are touching already selected edge
> > > > > pixels. Stop when no new pixels can be added to the edge. Better,
> but
> > > > > still potentially width*height/2 iterations with width*height
> > > > > operations each, completely killing performance.
> > > > >
> > > > > Maybe later I'll try to implement it in a generic way, but this is
> out
> > > > > of scope for this patch.
> > > > >
> > > > > Regards,
> > > > >
> > > > > Valery Kot
> > > >
> > > > Any objections if I apply this patch?
> >
> > >
> > > The patch look fine to me, but no sign-off?
> > >
> >
> > Thanks, will add one.
>
> I guess it's OK to push. In my few tests for some cases it looked
> a bit better.
>
> I didn't understand why this doesn't make things worse for the
> outermost frame of pixels, but Valery commented it wouldn't make
> any difference because of the surrounding code.
>
> I just looked at that function and because it checks all the eight
> surrounding pixels, I thought we might now miss cases that wouldn't
> have been missed before. Should of course be usually be better for
> most pictures.


The point of the first check is to skip pixels on the boundary so that the
surrounding pixels check does not seg fault.
It was only by luck that src[i] is always zero on the boundary so that the
surrounding pixels check is not evaluated.

You could treat pixels on the boundary separately, but I don't think it's
worth it.

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] libavutil/imgutils: UBSan nullptr-with-offset in av_image_fill_pointer

[Brian Kim]

I'm using clang 10.0.0 and configuring with with `configure --enable-gpl
--enable-libass --enable-libfdk-aac --enable-libmp3lame
--enable-libopencore-amrnb --enable-libopencore-amrwb --enable-librtmp
--enable-libtheora --enable-libvorbis --enable-libopus --enable-libx264
--enable-libvpx --enable-nonfree --enable-version3 --disable-optimizations
--disable-stripping --enable-debug=3 --toolchain=clang-usan` (plus
`--extra-cflags=-fno-sanitize-recover=pointer-overflow
--extra-ldflags=-fno-sanitize-recover=pointer-overflow` to crash when we
run into the UB)

When I run `make fate -j 12 SAMPLES=fate-suite`, several tests (e.g.
api-mjpeg-codec-param) fail with something like the following in the error
logs:

libavutil/imgutils.c:139:29: runtime error: applying non-zero offset 131072
to null pointer
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior
libavutil/imgutils.c:139:29 in

 It looks like this check was added in clang 10 (
https://reviews.llvm.org/D67122)

On Thu, Jul 2, 2020 at 8:06 AM Michael Niedermayer 
wrote:

> On Wed, Jul 01, 2020 at 11:14:13AM -0700, Brian Kim wrote:
> > While running under Clang's UndefinedBehaviorSanitizer, I found a few
> > places where av_image_fill_pointers is called before buffers for the
> image
> > are allocated, so ptr is passed in as NULL.
> >
> > This leads to (currently harmless) UB when the plane sizes are added to
> the
> > null pointer, so I was wondering if there was interest in avoiding it?
> >
> > I've attached a patch to expose some extra utilities and avoid passing in
> > the null pointer, but is this an appropriate way to work around it?
>
> how can these cases be reproduced ?
>
> thx
>
> [...]
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> The smallest minority on earth is the individual. Those who deny
> individual rights cannot claim to be defenders of minorities. - Ayn Rand
> ___
> 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] [GSoC 1/6] avformat/abr: Adaptive Bitrate support

[Martin Storsjö]

On Sun, 5 Jul 2020, Hongcheng Zhong wrote:


From: spartazhc 

Add abr module for hls/dash.

Signed-off-by: spartazhc 
---
doc/protocols.texi  |   7 +
libavformat/Makefile|   1 +
libavformat/abr.c   | 282 
libavformat/protocols.c |   1 +
4 files changed, 291 insertions(+)
create mode 100644 libavformat/abr.c




+const URLProtocol ff_abr_protocol = {
+.name= "abr",


If this protocol isn't a protocol that an end user would invoke (it isn't 
- there's no standard abr:// protocol), it would be good to more clearly 
mark it as an internal implementation detail instead of an end user facing 
protocol, e.g. by adding an "ff" prefix to the protocol name, like the 
existing ffrtmpcrypt protocol.


That said I haven't reviewed the concept itself though.

// 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] [PATCH] avformat/smjpegdec: Check the existence of referred streams

[Michael Niedermayer]

Fixes: Assertion failure
Fixes: 
23758/clusterfuzz-testcase-minimized-ffmpeg_DEMUXER_fuzzer-5160954605338624.fuzz

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

diff --git a/libavformat/smjpegdec.c b/libavformat/smjpegdec.c
index 5bc04921fe..a4e1f957ed 100644
--- a/libavformat/smjpegdec.c
+++ b/libavformat/smjpegdec.c
@@ -51,6 +51,9 @@ static int smjpeg_read_header(AVFormatContext *s)
 uint32_t version, htype, hlength, duration;
 char *comment;
 
+sc->audio_stream_index =
+sc->video_stream_index = -1;
+
 avio_skip(pb, 8); // magic
 version = avio_rb32(pb);
 if (version)
@@ -147,6 +150,8 @@ static int smjpeg_read_packet(AVFormatContext *s, AVPacket 
*pkt)
 dtype = avio_rl32(s->pb);
 switch (dtype) {
 case SMJPEG_SNDD:
+if (sc->audio_stream_index < 0)
+return AVERROR_INVALIDDATA;
 timestamp = avio_rb32(s->pb);
 size = avio_rb32(s->pb);
 ret = av_get_packet(s->pb, pkt, size);
@@ -155,6 +160,8 @@ static int smjpeg_read_packet(AVFormatContext *s, AVPacket 
*pkt)
 pkt->pos = pos;
 break;
 case SMJPEG_VIDD:
+if (sc->video_stream_index < 0)
+return AVERROR_INVALIDDATA;
 timestamp = avio_rb32(s->pb);
 size = avio_rb32(s->pb);
 ret = av_get_packet(s->pb, pkt, size);
-- 
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".

[FFmpeg-devel] [PATCH] libavfilter/vf_codecview: add block structure visualization

[Yongle Lin]

example command line to visualize block decomposition:
./ffmpeg -export_side_data +venc_params -i input.webm -vf
codecview=bs=true output.webm
---
 doc/filters.texi   |  3 +++
 libavfilter/vf_codecview.c | 41 ++
 2 files changed, 44 insertions(+)

diff --git a/doc/filters.texi b/doc/filters.texi
index 84567dec16..db2c80b1e9 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -7285,6 +7285,9 @@ backward predicted MVs of B-frames
 @item qp
 Display quantization parameters using the chroma planes.
 
+@item bs
+Display block structure using the luma plane.
+
 @item mv_type, mvt
 Set motion vectors type to visualize. Includes MVs from all frames unless 
specified by @var{frame_type} option.
 
diff --git a/libavfilter/vf_codecview.c b/libavfilter/vf_codecview.c
index 331bfba777..db06625d70 100644
--- a/libavfilter/vf_codecview.c
+++ b/libavfilter/vf_codecview.c
@@ -34,6 +34,7 @@
 #include "libavutil/opt.h"
 #include "avfilter.h"
 #include "internal.h"
+#include "libavutil/video_enc_params.h"
 
 #define MV_P_FOR  (1<<0)
 #define MV_B_FOR  (1<<1)
@@ -51,6 +52,7 @@ typedef struct CodecViewContext {
 unsigned mv_type;
 int hsub, vsub;
 int qp;
+int bs;
 } CodecViewContext;
 
 #define OFFSET(x) offsetof(CodecViewContext, x)
@@ -63,6 +65,7 @@ static const AVOption codecview_options[] = {
 CONST("bf", "forward predicted MVs of B-frames",  MV_B_FOR,  "mv"),
 CONST("bb", "backward predicted MVs of B-frames", MV_B_BACK, "mv"),
 { "qp", NULL, OFFSET(qp), AV_OPT_TYPE_BOOL, {.i64=0}, 0, 1, .flags = FLAGS 
},
+{ "bs", "set block structure to visualize", OFFSET(bs), AV_OPT_TYPE_BOOL, 
{.i64=0}, 0, 1, .flags = FLAGS },
 { "mv_type", "set motion vectors type", OFFSET(mv_type), 
AV_OPT_TYPE_FLAGS, {.i64=0}, 0, INT_MAX, FLAGS, "mv_type" },
 { "mvt", "set motion vectors type", OFFSET(mv_type), 
AV_OPT_TYPE_FLAGS, {.i64=0}, 0, INT_MAX, FLAGS, "mv_type" },
 CONST("fp", "forward predicted MVs",  MV_TYPE_FOR,  "mv_type"),
@@ -212,6 +215,30 @@ static void draw_arrow(uint8_t *buf, int sx, int sy, int 
ex,
 draw_line(buf, sx, sy, ex, ey, w, h, stride, color);
 }
 
+static void draw_block_border(AVFrame *frame, AVVideoBlockParams *b)
+{
+const int lzy = frame->linesize[0];
+uint8_t *py = frame->data[0] + b->src_y * lzy;
+
+for (int x = b->src_x; x < b->src_x + b->w; x++) {
+if (x >= frame->width)
+break;
+py[x] = py[x] * 3 / 4;
+}
+for (int y = b->src_y; y < b->src_y + b->h; y++) {
+if (y >= frame->height)
+break;
+py[b->src_x] = py[b->src_x] * 3 / 4;
+py[b->src_x + b->w - 1] = py[b->src_x + b->w - 1] * 3 / 4;
+py += lzy;
+}
+for (int x = b->src_x; x < b->src_x + b->w; x++) {
+if (x >= frame->width)
+break;
+py[x] = py[x] * 3 / 4;
+}
+}
+
 static int filter_frame(AVFilterLink *inlink, AVFrame *frame)
 {
 AVFilterContext *ctx = inlink->dst;
@@ -242,6 +269,20 @@ static int filter_frame(AVFilterLink *inlink, AVFrame 
*frame)
 }
 }
 
+if (s->bs) {
+AVFrameSideData *sd = av_frame_get_side_data(frame, 
AV_FRAME_DATA_VIDEO_ENC_PARAMS);
+if (sd) {
+AVVideoEncParams *par = (AVVideoEncParams*)sd->data;
+
+if (par->nb_blocks) {
+for (int i = 0; i < par->nb_blocks; i++) {
+AVVideoBlockParams *b = av_video_enc_params_block(par, i);
+draw_block_border(frame, b);
+}
+}
+}
+}
+
 if (s->mv || s->mv_type) {
 AVFrameSideData *sd = av_frame_get_side_data(frame, 
AV_FRAME_DATA_MOTION_VECTORS);
 if (sd) {
-- 
2.27.0.383.g050319c2ae-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".

Re: [FFmpeg-devel] [PATCH] avcodec/h264: support sps/pps AV_PKT_DATA_NEW_EXTRADATA

[James Almer]

On 6/19/2020 5:10 PM, Olly Woodman wrote:
> On Tue, 2 Jun 2020 at 22:32, Olly Woodman  wrote:
> 
>>
>>
>> On Fri, 8 May 2020 at 03:10, Oliver Woodman  wrote:
>>
>>> https://github.com/FFmpeg/FFmpeg/commit/601c238 added support
>>> for AV_PKT_DATA_NEW_EXTRADATA, but only for avcC extradata.
>>> This commit adds support for sps/pps extradata as well. This
>>> makes support consistent for passing new extradata consistent
>>> with the types of extradata that can be passed when initializing
>>> the decoder.
>>>
>>> Signed-off-by: Oliver Woodman 
>>> ---
>>>  libavcodec/h264dec.c | 13 ++---
>>>  1 file changed, 6 insertions(+), 7 deletions(-)
>>>
>>> diff --git a/libavcodec/h264dec.c b/libavcodec/h264dec.c
>>> index 4c355feb18..c1d103a474 100644
>>> --- a/libavcodec/h264dec.c
>>> +++ b/libavcodec/h264dec.c
>>> @@ -829,7 +829,7 @@ static int output_frame(H264Context *h, AVFrame *dst,
>>> H264Picture *srcp)
>>>  return 0;
>>>  }
>>>
>>> -static int is_extra(const uint8_t *buf, int buf_size)
>>> +static int is_avcc_extradata(const uint8_t *buf, int buf_size)
>>>  {
>>>  int cnt= buf[5]&0x1f;
>>>  const uint8_t *p= buf+6;
>>> @@ -956,16 +956,15 @@ static int h264_decode_frame(AVCodecContext *avctx,
>>> void *data,
>>>  if (buf_size == 0)
>>>  return send_next_delayed_frame(h, pict, got_frame, 0);
>>>
>>> -if (h->is_avc && av_packet_get_side_data(avpkt,
>>> AV_PKT_DATA_NEW_EXTRADATA, NULL)) {
>>> +if (av_packet_get_side_data(avpkt, AV_PKT_DATA_NEW_EXTRADATA, NULL))
>>> {
>>>  int side_size;
>>>  uint8_t *side = av_packet_get_side_data(avpkt,
>>> AV_PKT_DATA_NEW_EXTRADATA, _size);
>>> -if (is_extra(side, side_size))
>>> -ff_h264_decode_extradata(side, side_size,
>>> - >ps, >is_avc,
>>> >nal_length_size,
>>> - avctx->err_recognition, avctx);
>>> +ff_h264_decode_extradata(side, side_size,
>>> + >ps, >is_avc, >nal_length_size,
>>> + avctx->err_recognition, avctx);
>>>  }
>>>  if (h->is_avc && buf_size >= 9 && buf[0]==1 && buf[2]==0 &&
>>> (buf[4]&0xFC)==0xFC) {
>>> -if (is_extra(buf, buf_size))
>>> +if (is_avcc_extradata(buf, buf_size))
>>>  return ff_h264_decode_extradata(buf, buf_size,
>>>  >ps, >is_avc,
>>> >nal_length_size,
>>>  avctx->err_recognition,
>>> avctx);
>>> --
>>> 2.26.0.110.g2183baf09c-goog
>>>
>>>
>> Would it be possible for someone to take a look at this? It would be great
>> to get this merged. For context, this is needed for us to add an FFmpeg
>> video decoder extension to the Android ExoPlayer project (without having to
>> make the code to do so unnecessarily complicated / inefficient). Thanks!
>>
>>
> 
> What do I have to do to get someone to look at (and/or merge) this? Thanks.

Just applied it as I hadn't seen it till now. Thank you, and sorry.
___
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/vf_edgedetect: properly implement double_threshold()

[Alexander Strasser]

On 2020-07-04 23:19 -0400, Andriy Gelman wrote:
> On Sun, 05. Jul 09:37, lance.lmw...@gmail.com wrote:
> > On Sat, Jul 04, 2020 at 01:03:48PM -0400, Andriy Gelman wrote:
> > > On Mon, 29. Jun 09:26, Valery Kot wrote:
> > > > On Sun, Jun 28, 2020 at 12:03 AM Andriy Gelman 
> > > >  wrote:
> > > > >
> > > > > lgtm. I saw a small improvement when testing.
> > > > >
> > > > > Would be nice to allow weak edges that become strong to trigger 
> > > > > neighboring weak
> > > > > edges in the future.
> > > >
> > > > Thanks for the comment.
> > > >
> > > > You are right, ideally double_threshold should be recursive (seed from
> > > > each "high" peak and spread over "low" peaks). But then potentially we
> > > > may end up with width*height/2 recursion depth, which may lead to
> > > > stack overflow. So probably some recursion limit is needed, and hence
> > > > suboptimal solution.
> > > >
> > > > Or iterative approach, running through the complete image again and
> > > > again checking if "low" peaks are touching already selected edge
> > > > pixels. Stop when no new pixels can be added to the edge. Better, but
> > > > still potentially width*height/2 iterations with width*height
> > > > operations each, completely killing performance.
> > > >
> > > > Maybe later I'll try to implement it in a generic way, but this is out
> > > > of scope for this patch.
> > > >
> > > > Regards,
> > > >
> > > > Valery Kot
> > >
> > > Any objections if I apply this patch?
>
> >
> > The patch look fine to me, but no sign-off?
> >
>
> Thanks, will add one.

I guess it's OK to push. In my few tests for some cases it looked
a bit better.

I didn't understand why this doesn't make things worse for the
outermost frame of pixels, but Valery commented it wouldn't make
any difference because of the surrounding code.

I just looked at that function and because it checks all the eight
surrounding pixels, I thought we might now miss cases that wouldn't
have been missed before. Should of course be usually be better for
most pictures.

Anyway I couldn't get around to build a mental model for this call,
so I might well be missing context.


  Alexander
___
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] libavcodec/vp9: export block structure when segmentation isn't enable

[Yongle Lin]

it makes sense to export block structure like src_x, src_y, width and
height when segmentation isn't enable so we could visualize and see the
structure of the block.
---
 libavcodec/vp9.c | 8 +++-
 1 file changed, 3 insertions(+), 5 deletions(-)

diff --git a/libavcodec/vp9.c b/libavcodec/vp9.c
index fd0bab14a2..e700def70e 100644
--- a/libavcodec/vp9.c
+++ b/libavcodec/vp9.c
@@ -1501,10 +1501,8 @@ static int vp9_export_enc_params(VP9Context *s, VP9Frame 
*frame)
 AVVideoEncParams *par;
 unsigned int tile, nb_blocks = 0;
 
-if (s->s.h.segmentation.enabled) {
-for (tile = 0; tile < s->active_tile_cols; tile++)
-nb_blocks += s->td[tile].nb_block_structure;
-}
+for (tile = 0; tile < s->active_tile_cols; tile++)
+nb_blocks += s->td[tile].nb_block_structure;
 
 par = av_video_enc_params_create_side_data(frame->tf.f,
 AV_VIDEO_ENC_PARAMS_VP9, nb_blocks);
@@ -1536,7 +1534,7 @@ static int vp9_export_enc_params(VP9Context *s, VP9Frame 
*frame)
 b->w = 1 << (3 + 
td->block_structure[block_tile].block_size_idx_x);
 b->h = 1 << (3 + 
td->block_structure[block_tile].block_size_idx_y);
 
-if (s->s.h.segmentation.feat[seg_id].q_enabled) {
+if (s->s.h.segmentation.enabled && 
s->s.h.segmentation.feat[seg_id].q_enabled) {
 b->delta_qp = s->s.h.segmentation.feat[seg_id].q_val;
 if (s->s.h.segmentation.absolute_vals)
 b->delta_qp -= par->qp;
-- 
2.27.0.383.g050319c2ae-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".

Re: [FFmpeg-devel] [PATCH] libavfilter/vf_codecview: enable qp visualization for H264 and VP9

[Yongle Lin]

On Thu, Jun 25, 2020 at 12:09 PM Yongle Lin  wrote:

> Add qp visualization in codecview filter which supports H264 and VP9
> codecs. Add options for luma/chroma qp and AC/DC qp as well. There is a old
> way to visualize it but it's deprecated since version 58.
> example command line to visualize qp:
> ./ffmpeg -export_side_data +venc_params -i input.mp4 -vf codecview=qp=true
> output.mp4
> ---
>  doc/filters.texi   |  6 
>  libavfilter/vf_codecview.c | 69 +-
>  2 files changed, 74 insertions(+), 1 deletion(-)
>
> diff --git a/doc/filters.texi b/doc/filters.texi
> index 84567dec16..f4a57e993f 100644
> --- a/doc/filters.texi
> +++ b/doc/filters.texi
> @@ -7285,6 +7285,12 @@ backward predicted MVs of B-frames
>  @item qp
>  Display quantization parameters using the chroma planes.
>
> +@item chroma_qp
> +Display chroma quantization parameters (default luma qp) using the chroma
> planes. Should use with qp option. (e.g. codecview=qp=true:chroma_qp=true)
> +
> +@item dc_qp
> +Display DC quantization parameters (default AC qp) using the chroma
> planes. Should use with qp option. (e.g. codecview=qp=true:dc_qp=true)
> +
>  @item mv_type, mvt
>  Set motion vectors type to visualize. Includes MVs from all frames unless
> specified by @var{frame_type} option.
>
> diff --git a/libavfilter/vf_codecview.c b/libavfilter/vf_codecview.c
> index 331bfba777..f585dfe28e 100644
> --- a/libavfilter/vf_codecview.c
> +++ b/libavfilter/vf_codecview.c
> @@ -34,6 +34,7 @@
>  #include "libavutil/opt.h"
>  #include "avfilter.h"
>  #include "internal.h"
> +#include "libavutil/video_enc_params.h"
>
>  #define MV_P_FOR  (1<<0)
>  #define MV_B_FOR  (1<<1)
> @@ -51,6 +52,8 @@ typedef struct CodecViewContext {
>  unsigned mv_type;
>  int hsub, vsub;
>  int qp;
> +int chroma_qp;
> +int dc_qp;
>  } CodecViewContext;
>
>  #define OFFSET(x) offsetof(CodecViewContext, x)
> @@ -63,6 +66,8 @@ static const AVOption codecview_options[] = {
>  CONST("bf", "forward predicted MVs of B-frames",  MV_B_FOR,
> "mv"),
>  CONST("bb", "backward predicted MVs of B-frames", MV_B_BACK,
> "mv"),
>  { "qp", NULL, OFFSET(qp), AV_OPT_TYPE_BOOL, {.i64=0}, 0, 1, .flags =
> FLAGS },
> +{ "chroma_qp", NULL, OFFSET(chroma_qp), AV_OPT_TYPE_BOOL, {.i64=0},
> 0, 1, .flags = FLAGS },
> +{ "dc_qp", NULL, OFFSET(dc_qp), AV_OPT_TYPE_BOOL, {.i64=0}, 0, 1,
> .flags = FLAGS },
>  { "mv_type", "set motion vectors type", OFFSET(mv_type),
> AV_OPT_TYPE_FLAGS, {.i64=0}, 0, INT_MAX, FLAGS, "mv_type" },
>  { "mvt", "set motion vectors type", OFFSET(mv_type),
> AV_OPT_TYPE_FLAGS, {.i64=0}, 0, INT_MAX, FLAGS, "mv_type" },
>  CONST("fp", "forward predicted MVs",  MV_TYPE_FOR,  "mv_type"),
> @@ -212,6 +217,52 @@ static void draw_arrow(uint8_t *buf, int sx, int sy,
> int ex,
>  draw_line(buf, sx, sy, ex, ey, w, h, stride, color);
>  }
>
> +static int qp_color_calculate(int qp, enum AVVideoEncParamsType type) {
> +return type == AV_VIDEO_ENC_PARAMS_H264 ? qp * 128 / 31 : qp;
> +}
> +
> +static void get_block_color(AVVideoEncParams *par, AVVideoBlockParams *b,
> CodecViewContext *s, enum AVColorRange color_range, int *cu, int *cv)
> +{
> +const int plane_qp_cu_index = s->chroma_qp ? 1 : 0;
> +const int plane_qp_cv_index = s->chroma_qp ? 2 : 0;
> +const int ac_dc_index = s->dc_qp ? 0 : 1;
> +*cu = qp_color_calculate(par->qp +
> par->delta_qp[plane_qp_cu_index][ac_dc_index] + b->delta_qp, par->type);
> +*cv = qp_color_calculate(par->qp +
> par->delta_qp[plane_qp_cv_index][ac_dc_index] + b->delta_qp, par->type);
> +if (color_range == AVCOL_RANGE_MPEG) {
> +// map jpeg color range(0-255) to mpeg color range(16-235)
> +*cu = av_rescale(*cu, 73, 85) + 16;
> +*cv = av_rescale(*cv, 73, 85) + 16;
> +}
> +}
> +
> +static void color_block(AVFrame *frame, CodecViewContext *s, const int
> src_x, const int src_y, const int b_w, const int b_h, const int cu, const
> int cv)
> +{
> +const int w = AV_CEIL_RSHIFT(frame->width,  s->hsub);
> +const int h = AV_CEIL_RSHIFT(frame->height, s->vsub);
> +const int lzu = frame->linesize[1];
> +const int lzv = frame->linesize[2];
> +
> +const int plane_src_x = src_x >> s->hsub;
> +const int plane_src_y = src_y >> s->vsub;
> +const int plane_b_w = b_w >> s->hsub;
> +const int plane_b_h = b_h >> s->vsub;
> +uint8_t *pu = frame->data[1] + plane_src_y * lzu;
> +uint8_t *pv = frame->data[2] + plane_src_y * lzv;
> +
> +for (int y = plane_src_y; y < plane_src_y + plane_b_h; y++) {
> +for (int x = plane_src_x; x < plane_src_x + plane_b_w; x++) {
> +if (x >= w)
> +break;
> +pu[x] = cu;
> +pv[x] = cv;
> +}
> +if (y >= h)
> +break;
> +pu += lzu;
> +pv += lzv;
> +}
> +}
> +
>  static int filter_frame(AVFilterLink *inlink, AVFrame *frame)
>  {
>  

Re: [FFmpeg-devel] [PATCH] avcodec/libaomenc: fix build w/libaom v1.0.0

[James Zern]

James,

On Thu, Jul 2, 2020 at 10:28 AM James Zern  wrote:
>
> broken since:
> aa5c6f382b avcodec/libaomenc: Add command-line options to control the use of 
> partition tools
>
> Signed-off-by: James Zern 
> ---
>  doc/encoders.texi  | 20 ++--
>  libavcodec/libaomenc.c |  4 
>  2 files changed, 14 insertions(+), 10 deletions(-)
>

I think this addresses the comments from the first patch. I'll submit
this in the next day or so if there aren't any more comments.

> diff --git a/doc/encoders.texi b/doc/encoders.texi
> index beaa72eeaf..5406d20c00 100644
> --- a/doc/encoders.texi
> +++ b/doc/encoders.texi
> @@ -1599,34 +1599,34 @@ Enable the use of global motion for block prediction. 
> Default is true.
>  Enable block copy mode for intra block prediction. This mode is
>  useful for screen content. Default is true.
>
> -@item enable-rect-partitions (@emph{boolean})
> +@item enable-rect-partitions (@emph{boolean}) (Requires libaom >= v2.0.0)
>  Enable rectangular partitions. Default is true.
>
> -@item enable-1to4-partitions (@emph{boolean})
> +@item enable-1to4-partitions (@emph{boolean}) (Requires libaom >= v2.0.0)
>  Enable 1:4/4:1 partitions. Default is true.
>
> -@item enable-ab-partitions (@emph{boolean})
> +@item enable-ab-partitions (@emph{boolean}) (Requires libaom >= v2.0.0)
>  Enable AB shape partitions. Default is true.
>
> -@item enable-angle-delta (@emph{boolean})
> +@item enable-angle-delta (@emph{boolean}) (Requires libaom >= v2.0.0)
>  Enable angle delta intra prediction. Default is true.
>
> -@item enable-cfl-intra (@emph{boolean})
> +@item enable-cfl-intra (@emph{boolean}) (Requires libaom >= v2.0.0)
>  Enable chroma predicted from luma intra prediction. Default is true.
>
> -@item enable-filter-intra (@emph{boolean})
> +@item enable-filter-intra (@emph{boolean}) (Requires libaom >= v2.0.0)
>  Enable filter intra predictor. Default is true.
>
> -@item enable-intra-edge-filter (@emph{boolean})
> +@item enable-intra-edge-filter (@emph{boolean}) (Requires libaom >= v2.0.0)
>  Enable intra edge filter. Default is true.
>
> -@item enable-smooth-intra (@emph{boolean})
> +@item enable-smooth-intra (@emph{boolean}) (Requires libaom >= v2.0.0)
>  Enable smooth intra prediction mode. Default is true.
>
> -@item enable-paeth-intra (@emph{boolean})
> +@item enable-paeth-intra (@emph{boolean}) (Requires libaom >= v2.0.0)
>  Enable paeth predictor in intra prediction. Default is true.
>
> -@item enable-palette (@emph{boolean})
> +@item enable-palette (@emph{boolean}) (Requires libaom >= v2.0.0)
>  Enable palette prediction mode. Default is true.
>
>  @end table
> diff --git a/libavcodec/libaomenc.c b/libavcodec/libaomenc.c
> index cb6558476c..2ecb3de3a7 100644
> --- a/libavcodec/libaomenc.c
> +++ b/libavcodec/libaomenc.c
> @@ -145,6 +145,7 @@ static const char *const ctlidstr[] = {
>  #endif
>  [AV1E_SET_ENABLE_CDEF]  = "AV1E_SET_ENABLE_CDEF",
>  [AOME_SET_TUNING]   = "AOME_SET_TUNING",
> +#if AOM_ENCODER_ABI_VERSION >= 22
>  [AV1E_SET_ENABLE_1TO4_PARTITIONS] = "AV1E_SET_ENABLE_1TO4_PARTITIONS",
>  [AV1E_SET_ENABLE_AB_PARTITIONS]   = "AV1E_SET_ENABLE_AB_PARTITIONS",
>  [AV1E_SET_ENABLE_RECT_PARTITIONS] = "AV1E_SET_ENABLE_RECT_PARTITIONS",
> @@ -155,6 +156,7 @@ static const char *const ctlidstr[] = {
>  [AV1E_SET_ENABLE_PAETH_INTRA]   = "AV1E_SET_ENABLE_PAETH_INTRA",
>  [AV1E_SET_ENABLE_SMOOTH_INTRA]  = "AV1E_SET_ENABLE_SMOOTH_INTRA",
>  [AV1E_SET_ENABLE_PALETTE]   = "AV1E_SET_ENABLE_PALETTE",
> +#endif
>  };
>
>  static av_cold void log_encoder_error(AVCodecContext *avctx, const char 
> *desc)
> @@ -718,6 +720,7 @@ static av_cold int aom_init(AVCodecContext *avctx,
>  codecctl_int(avctx, AV1E_SET_ENABLE_CDEF, ctx->enable_cdef);
>  if (ctx->enable_restoration >= 0)
>  codecctl_int(avctx, AV1E_SET_ENABLE_RESTORATION, 
> ctx->enable_restoration);
> +#if AOM_ENCODER_ABI_VERSION >= 22
>  if (ctx->enable_rect_partitions >= 0)
>  codecctl_int(avctx, AV1E_SET_ENABLE_RECT_PARTITIONS, 
> ctx->enable_rect_partitions);
>  if (ctx->enable_1to4_partitions >= 0)
> @@ -738,6 +741,7 @@ static av_cold int aom_init(AVCodecContext *avctx,
>  codecctl_int(avctx, AV1E_SET_ENABLE_SMOOTH_INTRA, 
> ctx->enable_smooth_intra);
>  if (ctx->enable_palette >= 0)
>  codecctl_int(avctx, AV1E_SET_ENABLE_PALETTE, ctx->enable_palette);
> +#endif
>
>  codecctl_int(avctx, AOME_SET_STATIC_THRESHOLD, ctx->static_thresh);
>  if (ctx->crf >= 0)
> --
> 2.27.0.212.ge8ba1cc988-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".

Re: [FFmpeg-devel] [PATCH] libavfilter/vf_codecview: add block structure visualization

[Yongle Lin]

On Thu, Jul 2, 2020 at 8:09 AM Michael Niedermayer 
wrote:

> On Wed, Jul 01, 2020 at 05:42:48PM +, Yongle Lin wrote:
> > example command line to visualize block decomposition:
> > ./ffmpeg -export_side_data +venc_params -i input.webm -vf
> > codecview=bs=true output.webm
> > ---
>
> >  doc/filters.texi   |  3 +++
> >  libavcodec/vp9.c   |  8 +++-
> >  libavfilter/vf_codecview.c | 41 ++
>
> the vp9 and vf_codecview changes belong in seperate patches, these are 2
> seperate libs
>
> thx
>
> [...]
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> In a rich man's house there is no place to spit but his face.
> -- Diogenes of Sinope
> ___
> 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".


Hi Michael,

I will separate it into two patches and re-sent to you. Thanks

Best,
Yongle
___
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/isom: allow ISO 639 codes for mov

[Yongle Lin]

On Fri, Jun 19, 2020 at 5:11 PM Yongle Lin  wrote:

> Allow ISO 639 language codes for text tracks in mov format when
> strictness is set to experimental
> ---
>  libavformat/isom.c | 9 +++--
>  libavformat/isom.h | 2 +-
>  libavformat/movenc.c   | 6 +++---
>  tests/fate/mov.mak | 3 +++
>  tests/ref/fate/mov-iso639-lang | 4 
>  5 files changed, 18 insertions(+), 6 deletions(-)
>  create mode 100644 tests/ref/fate/mov-iso639-lang
>
> diff --git a/libavformat/isom.c b/libavformat/isom.c
> index 44c7b13038..de20ea8d8b 100644
> --- a/libavformat/isom.c
> +++ b/libavformat/isom.c
> @@ -416,7 +416,7 @@ static const char mov_mdhd_language_map[][4] = {
>  "cat", "lat", "que", "grn", "aym", "tat", "uig", "dzo", "jav"
>  };
>
> -int ff_mov_iso639_to_lang(const char lang[4], int mp4)
> +int ff_mov_iso639_to_lang(const char lang[4], int mp4, int
> strict_std_compliance)
>  {
>  int i, code = 0;
>
> @@ -426,8 +426,13 @@ int ff_mov_iso639_to_lang(const char lang[4], int mp4)
>  return i;
>  }
>  /* XXX:can we do that in mov too? */
> -if (!mp4)
> +if (!mp4 && (strict_std_compliance != FF_COMPLIANCE_EXPERIMENTAL ||
> !strcmp(lang, "und"))) {
> +if (strcmp(lang, "und"))
> +av_log(NULL, AV_LOG_WARNING, "Non macintosh language is
> discarded for mov\n");
>  return -1;
> +}
> +if (!mp4)
> +av_log(NULL, AV_LOG_WARNING, "Experimental behavior: enable iso
> 639 language in mov\n");
>  /* handle undefined as such */
>  if (lang[0] == '\0')
>  lang = "und";
> diff --git a/libavformat/isom.h b/libavformat/isom.h
> index 41a9c64c11..9d018ebf1f 100644
> --- a/libavformat/isom.h
> +++ b/libavformat/isom.h
> @@ -43,7 +43,7 @@ extern const AVCodecTag ff_codec_movaudio_tags[];
>  extern const AVCodecTag ff_codec_movsubtitle_tags[];
>  extern const AVCodecTag ff_codec_movdata_tags[];
>
> -int ff_mov_iso639_to_lang(const char lang[4], int mp4);
> +int ff_mov_iso639_to_lang(const char lang[4], int mp4, int
> strict_std_compliance);
>  int ff_mov_lang_to_iso639(unsigned code, char to[4]);
>
>  struct AVAESCTR;
> diff --git a/libavformat/movenc.c b/libavformat/movenc.c
> index 520aaafb74..4d7a98245e 100644
> --- a/libavformat/movenc.c
> +++ b/libavformat/movenc.c
> @@ -3429,7 +3429,7 @@ static int mov_write_string_data_tag(AVIOContext
> *pb, const char *data, int lang
>  return size;
>  } else {
>  if (!lang)
> -lang = ff_mov_iso639_to_lang("und", 1);
> +lang = ff_mov_iso639_to_lang("und", 1, FF_COMPLIANCE_NORMAL);
>  avio_wb16(pb, strlen(data)); /* string length */
>  avio_wb16(pb, lang);
>  avio_write(pb, data, strlen(data));
> @@ -3468,7 +3468,7 @@ static AVDictionaryEntry
> *get_metadata_lang(AVFormatContext *s,
>  while ((t2 = av_dict_get(s->metadata, tag2, t2,
> AV_DICT_IGNORE_SUFFIX))) {
>  len2 = strlen(t2->key);
>  if (len2 == len + 4 && !strcmp(t->value, t2->value)
> -&& (l = ff_mov_iso639_to_lang(>key[len2 - 3], 1)) >= 0) {
> +&& (l = ff_mov_iso639_to_lang(>key[len2 - 3], 1,
> s->strict_std_compliance)) >= 0) {
>  *lang = l;
>  return t;
>  }
> @@ -6445,7 +6445,7 @@ static int mov_init(AVFormatContext *s)
>
>  track->st  = st;
>  track->par = st->codecpar;
> -track->language = ff_mov_iso639_to_lang(lang?lang->value:"und",
> mov->mode!=MODE_MOV);
> +track->language = ff_mov_iso639_to_lang(lang?lang->value:"und",
> mov->mode!=MODE_MOV, s->strict_std_compliance);
>  if (track->language < 0)
>  track->language = 32767;  // Unspecified Macintosh language
> code
>  track->mode = mov->mode;
> diff --git a/tests/fate/mov.mak b/tests/fate/mov.mak
> index 7a721d7c95..a85cc1a07d 100644
> --- a/tests/fate/mov.mak
> +++ b/tests/fate/mov.mak
> @@ -29,6 +29,7 @@ FATE_MOV_FFPROBE = fate-mov-neg-firstpts-discard \
> fate-mov-guess-delay-2 \
> fate-mov-guess-delay-3 \
> fate-mov-mp4-with-mov-in24-ver \
> +   fate-mov-iso639-lang \
>
>  FATE_MOV_FASTSTART = fate-mov-faststart-4gb-overflow \
>
> @@ -124,3 +125,5 @@ fate-mov-faststart-4gb-overflow: CMP = oneline
>  fate-mov-faststart-4gb-overflow: REF = bc875921f151871e787c4b4023269b29
>
>  fate-mov-mp4-with-mov-in24-ver: CMD = run ffprobe$(PROGSSUF)$(EXESUF)
> -show_entries stream=codec_name -select_streams 1
> $(TARGET_SAMPLES)/mov/mp4-with-mov-in24-ver.mp4
> +
> +fate-mov-iso639-lang: CMD = ffmpeg$(PROGSSUF)$(EXESUF) -f lavfi -i
> sine=frequency=1000:duration=15 -strict experimental -metadata:s:a:0
> language=deu -y $(TARGET_PATH)/metadata.mov; run ffprobe -show_entries
> stream=index:stream_tags=language $(TARGET_PATH)/metadata.mov; rm
> metadata.mov
> diff --git a/tests/ref/fate/mov-iso639-lang
> b/tests/ref/fate/mov-iso639-lang
> new file mode 100644
> index 

Re: [FFmpeg-devel] [PATCH 1/3] lavu: add a template for refcounted objects.

[Alexander Strasser]

Hi all!

On 2020-07-01 17:05 +0200, Anton Khirnov wrote:
> Quoting Nicolas George (2020-06-27 17:16:44)
> > Signed-off-by: Nicolas George 
> > ---
> >  libavutil/avrefcount_template.h | 140 
> >  tests/ref/fate/source   |   1 +
> >  2 files changed, 141 insertions(+)
> >  create mode 100644 libavutil/avrefcount_template.h
> >
> >
> > I will need to refcount something soon. Recently, the need to stop
> > abusing AVBuffer for all refcounting was mentioned on the list. So here
> > is an attempt at isolating the refcounting itself.
> >
> > This is not the final verion, I will first work on the "something" to
> > make sure it suits the needs. But it is a first version.
> >
> > Anton, I would appreciate if you had a look at this and told me if there
> > is something you strongly dislike about before I have piled too much
> > efforts over it.
>
> Why a template? It seems simpler to add a struct like
> typedef struct AVRefcount {
> atomic_uint refcount;
> void   *opaque;
> void  (*free)(void *opaque);
> } AVRefcount;
> and then embed it in everything that wants to be refcounted. All just
> normal structs and functions, no layers of macros.

Maybe we need to be more precise about the goal. Or maybe we need
to find a common goal.

So my first question in this direction is:
What do we want? Do we want to make reference counting available
for internal and FFmpeg-external use?

If we want to generalize for internal use I think Nicolas' proposal
has advantages. Not because of performance, but because it makes
the definition of ref-counted types easier and more uniformly
manageable.

If we want to export ref counting, so lavu users can use it for
their own types too, I would tend to what Anton proposed.

I can go more into detail about the why, but I think we need
to find the wanted direction first.


Best regards,
  Alexander
___
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/h264: support sps/pps AV_PKT_DATA_NEW_EXTRADATA

[Paul B Mahol]

On 6/19/20, Olly Woodman  wrote:
> On Tue, 2 Jun 2020 at 22:32, Olly Woodman  wrote:
>
>>
>>
>> On Fri, 8 May 2020 at 03:10, Oliver Woodman  wrote:
>>
>>> https://github.com/FFmpeg/FFmpeg/commit/601c238 added support
>>> for AV_PKT_DATA_NEW_EXTRADATA, but only for avcC extradata.
>>> This commit adds support for sps/pps extradata as well. This
>>> makes support consistent for passing new extradata consistent
>>> with the types of extradata that can be passed when initializing
>>> the decoder.
>>>
>>> Signed-off-by: Oliver Woodman 
>>> ---
>>>  libavcodec/h264dec.c | 13 ++---
>>>  1 file changed, 6 insertions(+), 7 deletions(-)
>>>
>>> diff --git a/libavcodec/h264dec.c b/libavcodec/h264dec.c
>>> index 4c355feb18..c1d103a474 100644
>>> --- a/libavcodec/h264dec.c
>>> +++ b/libavcodec/h264dec.c
>>> @@ -829,7 +829,7 @@ static int output_frame(H264Context *h, AVFrame *dst,
>>> H264Picture *srcp)
>>>  return 0;
>>>  }
>>>
>>> -static int is_extra(const uint8_t *buf, int buf_size)
>>> +static int is_avcc_extradata(const uint8_t *buf, int buf_size)
>>>  {
>>>  int cnt= buf[5]&0x1f;
>>>  const uint8_t *p= buf+6;
>>> @@ -956,16 +956,15 @@ static int h264_decode_frame(AVCodecContext *avctx,
>>> void *data,
>>>  if (buf_size == 0)
>>>  return send_next_delayed_frame(h, pict, got_frame, 0);
>>>
>>> -if (h->is_avc && av_packet_get_side_data(avpkt,
>>> AV_PKT_DATA_NEW_EXTRADATA, NULL)) {
>>> +if (av_packet_get_side_data(avpkt, AV_PKT_DATA_NEW_EXTRADATA, NULL))
>>> {
>>>  int side_size;
>>>  uint8_t *side = av_packet_get_side_data(avpkt,
>>> AV_PKT_DATA_NEW_EXTRADATA, _size);
>>> -if (is_extra(side, side_size))
>>> -ff_h264_decode_extradata(side, side_size,
>>> - >ps, >is_avc,
>>> >nal_length_size,
>>> - avctx->err_recognition, avctx);
>>> +ff_h264_decode_extradata(side, side_size,
>>> + >ps, >is_avc,
>>> >nal_length_size,
>>> + avctx->err_recognition, avctx);
>>>  }
>>>  if (h->is_avc && buf_size >= 9 && buf[0]==1 && buf[2]==0 &&
>>> (buf[4]&0xFC)==0xFC) {
>>> -if (is_extra(buf, buf_size))
>>> +if (is_avcc_extradata(buf, buf_size))
>>>  return ff_h264_decode_extradata(buf, buf_size,
>>>  >ps, >is_avc,
>>> >nal_length_size,
>>>  avctx->err_recognition,
>>> avctx);
>>> --
>>> 2.26.0.110.g2183baf09c-goog
>>>
>>>
>> Would it be possible for someone to take a look at this? It would be great
>> to get this merged. For context, this is needed for us to add an FFmpeg
>> video decoder extension to the Android ExoPlayer project (without having
>> to
>> make the code to do so unnecessarily complicated / inefficient). Thanks!
>>
>>
>
> What do I have to do to get someone to look at (and/or merge) this? Thanks.

I'm not h264 expert so cannot look at it.
Sorry.
___
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 v5 1/6] avformat/apm: use new extradata format

[Michael Niedermayer]

On Mon, Jul 06, 2020 at 09:24:20AM +, Zane van Iperen wrote:
> Signed-off-by: Zane van Iperen 
> ---
>  libavformat/Makefile |  2 +-
>  libavformat/apm.c| 62 
>  2 files changed, 35 insertions(+), 29 deletions(-)

I think the commit message should be more elaborate
"avformat/apm: use new extradata format"
doesnt really say what changes, why its changes


[...]
> @@ -95,24 +99,29 @@ static int apm_read_header(AVFormatContext *s)
>  int64_t ret;
>  AVStream *st;
>  APMVS12Chunk vs12;
> -uint8_t buf[APM_VS12_CHUNK_SIZE];
> +uint8_t buf[APM_FILE_EXTRADATA_SIZE];
>  
>  if (!(st = avformat_new_stream(s, NULL)))
>  return AVERROR(ENOMEM);
>  
> -/* The header starts with a WAVEFORMATEX */
> -if ((ret = ff_get_wav_header(s, s->pb, st->codecpar, 
> APM_FILE_HEADER_SIZE, 0)) < 0)
> -return ret;
> -
> -if (st->codecpar->bits_per_coded_sample != 4)
> +/*
> + * This is 98% a WAVEFORMATEX, but there's something screwy with the 
> extradata
> + * that ff_get_wav_header() can't (and shouldn't) handle properly.
> + */
> +if (avio_rl16(s->pb) != APM_TAG_CODEC)
>  return AVERROR_INVALIDDATA;
>  
> -if (st->codecpar->codec_tag != APM_TAG_CODEC)
> +st->codecpar->channels  = avio_rl16(s->pb);
> +st->codecpar->sample_rate   = avio_rl32(s->pb);

> +st->codecpar->bit_rate  = avio_rl32(s->pb) * 8;

This can overflow

You also may want to add yourself to the MAINTAINERs file

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

Concerning the gods, I have no means of knowing whether they exist or not
or of what sort they may be, because of the obscurity of the subject, and
the brevity of human life -- Protagoras


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] Project orientation

[Olly Woodman]

On Mon, 6 Jul 2020 at 05:54, Jim DeLaHunt  wrote:

> On 2020-07-04 07:43, Nicolas George wrote:
> > [In the FFmpeg project,] [t]here is work in making highly-optimized
> > decoders, this work is impressive and creative…. But as far as I can see,
> > that is mostly all there is going on. The rest seems to be rather basic:
> > fixing bugs…, implementing support for
> > features that were decided and designed elsewhere.
> >
> > And it is not just that it is not happening: there is genuine opposition
> > to creativity: things that are not already justified externally, things
> > that do not look like well-known patterns, are met with scepticism and
> > eventually rejected.
> >
> > At this point, we should ask ourselves:
> >
> > Is it what we want the project to be, or is it just what we have let it
> > become?
> >
> > I do not think this evolution is the result of a deliberate choice. I
> > think it is more the result of the stress of success and the stress of a
> > fork. Success can stifle creativity, because creativity implies the risk
> > of failure: the project has become advert to risk.
> >
> > It has evolved that way, but are we fine with it?
> >
> > I personally am not….
>
> I am really happy to see this discussion starting up. It is good timing;
> some new governance committees are forming. They might be able to take
> it on. From my perspective as an outside observer, I think the project
> will benefit from you — the people who are at the heart of the project —
> having this discussion.
>
> For what purpose do all of you contribute to FFmpeg? What is the good
> you see FFmpeg doing? What is FFmpeg's purpose?  What stands in the way
> of FFmpeg achieving its purpose, and of you achieving your own
> individual purpose?
>
> For me, several comments in the thread resonated. They have a theme:
> bringing in new participants:
>
> On 2020-07-04 08:37, James Almer wrote:
> > …Another thing worth mentioning is a lack of new blood. Despite
> > participating in GSoC for a long while, i can't name a student that
> > stuck around after the fact. Mind, there are new devs that started
> > contributing for other reasons, but perhaps not enough?
>
>
> On 2020-07-04 11:20, Soft Works wrote:
>
> > …As a developer (without a well-known name) who wants to contribute a
> patch,
> > things can be quite frustrating here. When that patch accidentally hits
> an
> > area of one the very few who are caring and friendly - you're lucky.
> > But otherwise, a patch will either be ignored or talked into infinity.
> >
> > I have a number of things to contribute, but after it didn’t work well
> > with small things, I decided not to bother with the bigger ones.
>
> On 2020-07-05 11:42, Steinar H. Gunderson wrote:
> > On Sun, Jul 05, 2020 at 08:13:25PM +0200, Manolis Stamatogiannakis wrote:
> >> As a fresh contributor, setting up git send-email was a hassle, but
> >> not an insurmountable obstacle.
> > Speaking only for myself, having sent a single-digit number of patches
> > to FFmpeg ever: Setting up git send-email was not a big turnoff. Having
> your
> > patch being not responded to (whether being forgotten, not found
> interesting
> > enough, or whatever other reason) was.
>
>
> To the extent you decide that you want new participants to join you on
> FFmpeg, I'm sorry to say, I think you have a problem. My own experience
> is that this project is more hostile to newcomers than many other free
> culture projects I know (e.g. Python, Thunderbird, Gnucash, Drupal,
> MusicBrainz, Wikipedia). It's not just your rudeness to each other on
> the email lists. It's not just the inattention to patches from new
> developers. It's also a simple lack of telling newcomers: welcome, we
> are glad you are here, we want your help, we will help you learn.
>

As someone who recently tried to send their first patch to FFmpeg,
I'd also like to +1 this. It was completely ignored, despite sending
three reminders (sending a reminder is suggested in the FFmpeg
documentation for submitting patches). Perhaps it was ignored for
a good reason, but a non-response does not tell me that, and nor
does it encourage further involvement.

I've also been quite shocked by some of the rudeness on this mailing
list, and the level to which it appears to be tolerated (or at least, the
extent to which there appear to be no repercussions for those who
repeatedly behave in a way that I'd consider unacceptable in a
professional context).


> Even more deeply, the culture of this project is focussed on checking in
> compileable code to the exclusion of other kinds of contribution:
> testing, documentation, support. Those contributions seem not welcome
> simply because they are not code, and code is all that matters.
>
> I suspect that you may find that some of the things that frustrate you
> are linked to work the project does not value. Repetitive questions on
> the ffmpeg-users list may in part result from the inadequate
> documentation, which doesn't tell users what they need 

Re: [FFmpeg-devel] [PATCH] dnn_backend_native: Add overflow check for length calculation.

[Guo, Yejun]

> -Original Message-
> From: ffmpeg-devel  On Behalf Of Reimar
> D?ffinger
> Sent: 2020年7月6日 15:32
> To: ffmpeg-devel@ffmpeg.org
> Subject: [FFmpeg-devel] [PATCH] dnn_backend_native: Add overflow check for
> length calculation.
> 
> We should not silently allocate an incorrect sized buffer.
> Fixes trac issue #8718.
> TODO1: calculate_operand_dims_count is almost identical code, should they be
> merged and its usages check for overflow?
> TODO2: the -1 return value seems questionable to me, but is aligned with the
> return value used for malloc failure.
> Probably both ought to be changed to AVERROR(ENOMEM).
> 
> Signed-off-by: Reimar Döffinger 
> ---
>  libavfilter/dnn/dnn_backend_native.c   | 10 +-
>  libavfilter/dnn/dnn_backend_native.h   |  2 ++
>  libavfilter/dnn/dnn_backend_native_layer_conv2d.c  |  2 ++
>  libavfilter/dnn/dnn_backend_native_layer_depth2space.c |  2 ++
> libavfilter/dnn/dnn_backend_native_layer_mathbinary.c  |  2 ++
>  libavfilter/dnn/dnn_backend_native_layer_mathunary.c   |  2 ++
>  libavfilter/dnn/dnn_backend_native_layer_maximum.c |  2 ++
>  libavfilter/dnn/dnn_backend_native_layer_pad.c |  2 ++
>  8 files changed, 23 insertions(+), 1 deletion(-)

thanks, LGTM, will push soon.

I'll modify a little to remove the TODO in commit log, and welcome the new 
patches.

I'll also cherry-pick to release 4.3
___
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] Ticket #8750 Add inline function for the vec_xl intrinsic in non-VSX environments

[Chip Kerchner]

ffmpeg_altivec_yuv2rgb_novsx.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] Ticket #8750 Add inline function for the vec_xl intrinsic in non-VSX environments

[Chip Kerchner]

ffmpeg_altivec_yuv2rgb_novsx.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] [GSoC 1/6] avformat/abr: Adaptive Bitrate support

[Moritz Barsnick]

On Sun, Jul 05, 2020 at 19:34:54 +0800, Hongcheng Zhong wrote:
> +static int abr_rule(ABRContext *c, float bw_estimate)
> +{
> +int ret = -1;
> +
> +if (c->n_throughputs > 6) {
> +if (bw_estimate < c->variants_bitrate[c->cur_pls].value / 1000 * 1.2 
> &&
> +bw_estimate > c->variants_bitrate[c->cur_pls].value / 1000 * 0.8)

You are using floats, but this syntax promotes the calculation to
double before casting back to float.

Use 1.2f and 0.8f for float constants.

> +case SEEK_END: {
> +int64_t newpos = ffurl_seek( c->hd, pos, AVSEEK_SIZE );
> +if (newpos < 0) {
> +av_log(h, AV_LOG_ERROR,
> +"ABR: seek_end - can't get file size (pos=%lld)\r\n", (long 
> long int)pos);

Instead of casting, please just use the correct format specifier for
int64_t, which is %"PRIi64", I believe.

And no "\r\n" please - just "\n".

(Incorrect indentation as well.)

> +}
> +pos = newpos - pos;
> +}
> +break;
> +case AVSEEK_SIZE: {
> +int64_t newpos = ffurl_seek( c->hd, pos, AVSEEK_SIZE );
> +return newpos;
> +}
> +break;
> +default:
> +av_log(h, AV_LOG_ERROR,
> +"ABR: no support for seek where 'whence' is %d\r\n", whence);

Incorrect indentation.

> +return AVERROR(EINVAL);
> +}
> +
> +newpos = ffurl_seek( c->hd, c->position, SEEK_SET );
> +if (newpos < 0) {
> +av_log(h, AV_LOG_ERROR,
> +"ABR: nested protocol no support for seek or seek failed\n");

Incorrect indentation.

> +return newpos;
> +}
> +return c->position;
> +}

I believe the blocks inside the switch/case are also incorrectly
indented.

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] [PATCH v5 6/6] avcodec/adpcmenc: cleanup trellis checks

[Zane van Iperen]

Signed-off-by: Zane van Iperen 
---
 libavcodec/adpcmenc.c | 35 ++-
 1 file changed, 18 insertions(+), 17 deletions(-)

diff --git a/libavcodec/adpcmenc.c b/libavcodec/adpcmenc.c
index 4985abb163..adb7bf0bbf 100644
--- a/libavcodec/adpcmenc.c
+++ b/libavcodec/adpcmenc.c
@@ -69,25 +69,26 @@ static av_cold int adpcm_encode_init(AVCodecContext *avctx)
 return AVERROR(EINVAL);
 }
 
-if (avctx->trellis && (unsigned)avctx->trellis > 16U) {
-av_log(avctx, AV_LOG_ERROR, "invalid trellis size\n");
-return AVERROR(EINVAL);
-}
+if (avctx->trellis) {
+int frontier, max_paths;
 
-if (avctx->trellis &&
-   (avctx->codec->id == AV_CODEC_ID_ADPCM_IMA_SSI ||
-avctx->codec->id == AV_CODEC_ID_ADPCM_IMA_APM)) {
-/*
- * The current trellis implementation doesn't work for extended
- * runs of samples without periodic resets. Disallow it.
- */
-av_log(avctx, AV_LOG_ERROR, "trellis not supported\n");
-return AVERROR_PATCHWELCOME;
-}
+if ((unsigned)avctx->trellis > 16U) {
+av_log(avctx, AV_LOG_ERROR, "invalid trellis size\n");
+return AVERROR(EINVAL);
+}
 
-if (avctx->trellis) {
-int frontier  = 1 << avctx->trellis;
-int max_paths =  frontier * FREEZE_INTERVAL;
+if (avctx->codec->id == AV_CODEC_ID_ADPCM_IMA_SSI ||
+avctx->codec->id == AV_CODEC_ID_ADPCM_IMA_APM) {
+/*
+ * The current trellis implementation doesn't work for extended
+ * runs of samples without periodic resets. Disallow it.
+ */
+av_log(avctx, AV_LOG_ERROR, "trellis not supported\n");
+return AVERROR_PATCHWELCOME;
+}
+
+frontier  = 1 << avctx->trellis;
+max_paths =  frontier * FREEZE_INTERVAL;
 if (!FF_ALLOC_TYPED_ARRAY(s->paths,max_paths)||
 !FF_ALLOC_TYPED_ARRAY(s->node_buf, 2 * frontier) ||
 !FF_ALLOC_TYPED_ARRAY(s->nodep_buf,2 * frontier) ||
-- 
2.25.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 v5 5/6] fate: add adpcm_ima_apm encoding test

[Zane van Iperen]

Signed-off-by: Zane van Iperen 
---
 tests/fate/acodec.mak  | 2 ++
 tests/ref/acodec/adpcm-ima_apm | 4 
 2 files changed, 6 insertions(+)
 create mode 100644 tests/ref/acodec/adpcm-ima_apm

diff --git a/tests/fate/acodec.mak b/tests/fate/acodec.mak
index bb6bfe5ada..197b6ed7c0 100644
--- a/tests/fate/acodec.mak
+++ b/tests/fate/acodec.mak
@@ -45,6 +45,7 @@ fate-acodec-pcm-u%le: FMT = nut
 fate-acodec-pcm-f%be: FMT = au
 
 FATE_ACODEC_ADPCM-$(call ENCDEC, ADPCM_ADX, ADX)  += adx
+FATE_ACODEC_ADPCM-$(call ENCDEC, ADPCM_IMA_APM, APM)  += ima_apm
 FATE_ACODEC_ADPCM-$(call ENCDEC, ADPCM_IMA_QT,  AIFF) += ima_qt
 FATE_ACODEC_ADPCM-$(call ENCDEC, ADPCM_IMA_SSI, KVAG) += ima_ssi
 FATE_ACODEC_ADPCM-$(call ENCDEC, ADPCM_IMA_WAV, WAV)  += ima_wav
@@ -59,6 +60,7 @@ fate-acodec-adpcm: $(FATE_ACODEC_ADPCM)
 fate-acodec-adpcm-%: CODEC = adpcm_$(@:fate-acodec-adpcm-%=%)
 
 fate-acodec-adpcm-adx: FMT = adx
+fate-acodec-adpcm-ima_apm: FMT = apm
 fate-acodec-adpcm-ima_qt:  FMT = aiff
 fate-acodec-adpcm-ima_ssi: FMT = kvag
 fate-acodec-adpcm-ima_wav: FMT = wav
diff --git a/tests/ref/acodec/adpcm-ima_apm b/tests/ref/acodec/adpcm-ima_apm
new file mode 100644
index 00..83bd21f831
--- /dev/null
+++ b/tests/ref/acodec/adpcm-ima_apm
@@ -0,0 +1,4 @@
+2e795c6c06baabe01ab92864d963e71b *tests/data/fate/acodec-adpcm-ima_apm.apm
+264700 tests/data/fate/acodec-adpcm-ima_apm.apm
+201607bf7610f062b9a1e6524354c569 *tests/data/fate/acodec-adpcm-ima_apm.out.wav
+stddev:  904.76 PSNR: 37.20 MAXDIFF:34029 bytes:  1058400/  1058400
-- 
2.25.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 v5 3/6] avcodec: add adpcm_ima_apm encoder

[Zane van Iperen]

Signed-off-by: Zane van Iperen 
---
 Changelog  |  1 +
 doc/general.texi   |  2 +-
 libavcodec/Makefile|  1 +
 libavcodec/adpcmenc.c  | 34 --
 libavcodec/allcodecs.c |  1 +
 libavcodec/utils.c |  1 +
 libavcodec/version.h   |  2 +-
 7 files changed, 38 insertions(+), 4 deletions(-)

diff --git a/Changelog b/Changelog
index 1bb9931c0d..e986327172 100644
--- a/Changelog
+++ b/Changelog
@@ -5,6 +5,7 @@ version :
 - AudioToolbox output device
 - MacCaption demuxer
 - PGX decoder
+- ADPCM IMA Ubisoft APM encoder
 
 
 version 4.3:
diff --git a/doc/general.texi b/doc/general.texi
index 53d556c56c..68d386b655 100644
--- a/doc/general.texi
+++ b/doc/general.texi
@@ -1113,7 +1113,7 @@ following image formats are supported:
 @item ADPCM IMA High Voltage Software ALP   @tab @tab  X
 @item ADPCM IMA QuickTime@tab  X  @tab  X
 @item ADPCM IMA Simon & Schuster Interactive   @tab  X  @tab  X
-@item ADPCM IMA Ubisoft APM  @tab @tab X
+@item ADPCM IMA Ubisoft APM  @tab  X  @tab  X
 @item ADPCM IMA Loki SDL MJPEG  @tab @tab  X
 @item ADPCM IMA WAV  @tab  X  @tab  X
 @item ADPCM IMA Westwood @tab @tab  X
diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index 12aa43fe51..86b92aeded 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -854,6 +854,7 @@ OBJS-$(CONFIG_ADPCM_IMA_AMV_DECODER)  += adpcm.o 
adpcm_data.o
 OBJS-$(CONFIG_ADPCM_IMA_ALP_DECODER)  += adpcm.o adpcm_data.o
 OBJS-$(CONFIG_ADPCM_IMA_APC_DECODER)  += adpcm.o adpcm_data.o
 OBJS-$(CONFIG_ADPCM_IMA_APM_DECODER)  += adpcm.o adpcm_data.o
+OBJS-$(CONFIG_ADPCM_IMA_APM_ENCODER)  += adpcmenc.o adpcm_data.o
 OBJS-$(CONFIG_ADPCM_IMA_CUNNING_DECODER)  += adpcm.o adpcm_data.o
 OBJS-$(CONFIG_ADPCM_IMA_DAT4_DECODER) += adpcm.o adpcm_data.o
 OBJS-$(CONFIG_ADPCM_IMA_DK3_DECODER)  += adpcm.o adpcm_data.o
diff --git a/libavcodec/adpcmenc.c b/libavcodec/adpcmenc.c
index 1e94ef4047..4985abb163 100644
--- a/libavcodec/adpcmenc.c
+++ b/libavcodec/adpcmenc.c
@@ -74,7 +74,9 @@ static av_cold int adpcm_encode_init(AVCodecContext *avctx)
 return AVERROR(EINVAL);
 }
 
-if (avctx->trellis && avctx->codec->id == AV_CODEC_ID_ADPCM_IMA_SSI) {
+if (avctx->trellis &&
+   (avctx->codec->id == AV_CODEC_ID_ADPCM_IMA_SSI ||
+avctx->codec->id == AV_CODEC_ID_ADPCM_IMA_APM)) {
 /*
  * The current trellis implementation doesn't work for extended
  * runs of samples without periodic resets. Disallow it.
@@ -145,6 +147,14 @@ static av_cold int adpcm_encode_init(AVCodecContext *avctx)
 avctx->frame_size = BLKSIZE * 2 / avctx->channels;
 avctx->block_align = BLKSIZE;
 break;
+case AV_CODEC_ID_ADPCM_IMA_APM:
+avctx->frame_size = BLKSIZE * 2 / avctx->channels;
+avctx->block_align = BLKSIZE;
+
+if (!(avctx->extradata = av_mallocz(28 + 
AV_INPUT_BUFFER_PADDING_SIZE)))
+return AVERROR(ENOMEM);
+avctx->extradata_size = 28;
+break;
 default:
 return AVERROR(EINVAL);
 }
@@ -486,7 +496,8 @@ static int adpcm_encode_frame(AVCodecContext *avctx, 
AVPacket *avpkt,
 
 if (avctx->codec_id == AV_CODEC_ID_ADPCM_SWF)
 pkt_size = (2 + avctx->channels * (22 + 4 * (frame->nb_samples - 1)) + 
7) / 8;
-else if (avctx->codec_id == AV_CODEC_ID_ADPCM_IMA_SSI)
+else if (avctx->codec_id == AV_CODEC_ID_ADPCM_IMA_SSI ||
+ avctx->codec_id == AV_CODEC_ID_ADPCM_IMA_APM)
 pkt_size = (frame->nb_samples * avctx->channels) / 2;
 else
 pkt_size = avctx->block_align;
@@ -711,6 +722,24 @@ static int adpcm_encode_frame(AVCodecContext *avctx, 
AVPacket *avpkt,
 *dst++  = nibble;
 }
 break;
+case AV_CODEC_ID_ADPCM_IMA_APM:
+{
+PutBitContext pb;
+init_put_bits(, dst, pkt_size);
+
+av_assert0(avctx->trellis == 0);
+
+for (n = frame->nb_samples / 2; n > 0; n--) {
+for (ch = 0; ch < avctx->channels; ch++) {
+put_bits(, 4, adpcm_ima_qt_compress_sample(c->status + ch, 
*samples++));
+put_bits(, 4, adpcm_ima_qt_compress_sample(c->status + ch, 
samples[st]));
+}
+samples += avctx->channels;
+}
+
+flush_put_bits();
+break;
+}
 default:
 return AVERROR(EINVAL);
 }
@@ -743,6 +772,7 @@ AVCodec ff_ ## name_ ## _encoder = {
   \
 .caps_internal  = FF_CODEC_CAP_INIT_CLEANUP,   \
 }
 
+ADPCM_ENCODER(AV_CODEC_ID_ADPCM_IMA_APM, adpcm_ima_apm, sample_fmts,   
AV_CODEC_CAP_SMALL_LAST_FRAME, "ADPCM IMA Ubisoft APM");
 ADPCM_ENCODER(AV_CODEC_ID_ADPCM_IMA_QT,  adpcm_ima_qt,  sample_fmts_p, 0,  
   "ADPCM IMA QuickTime");
 ADPCM_ENCODER(AV_CODEC_ID_ADPCM_IMA_SSI, adpcm_ima_ssi, sample_fmts,   
AV_CODEC_CAP_SMALL_LAST_FRAME, "ADPCM IMA Simon & Schuster Interactive");
 

[FFmpeg-devel] [PATCH v5 4/6] avformat: add apm muxer

[Zane van Iperen]

Signed-off-by: Zane van Iperen 
---
 Changelog|   1 +
 libavformat/Makefile |   1 +
 libavformat/allformats.c |   1 +
 libavformat/apm.c| 110 ++-
 libavformat/version.h|   2 +-
 5 files changed, 112 insertions(+), 3 deletions(-)

diff --git a/Changelog b/Changelog
index e986327172..d905e5dc45 100644
--- a/Changelog
+++ b/Changelog
@@ -6,6 +6,7 @@ version :
 - MacCaption demuxer
 - PGX decoder
 - ADPCM IMA Ubisoft APM encoder
+- Rayman 2 APM muxer
 
 
 version 4.3:
diff --git a/libavformat/Makefile b/libavformat/Makefile
index a4113fe644..62d8cbb54e 100644
--- a/libavformat/Makefile
+++ b/libavformat/Makefile
@@ -94,6 +94,7 @@ OBJS-$(CONFIG_ANM_DEMUXER)   += anm.o
 OBJS-$(CONFIG_APC_DEMUXER)   += apc.o
 OBJS-$(CONFIG_APE_DEMUXER)   += ape.o apetag.o img2.o
 OBJS-$(CONFIG_APM_DEMUXER)   += apm.o
+OBJS-$(CONFIG_APM_MUXER) += apm.o rawenc.o
 OBJS-$(CONFIG_APNG_DEMUXER)  += apngdec.o
 OBJS-$(CONFIG_APNG_MUXER)+= apngenc.o
 OBJS-$(CONFIG_APTX_DEMUXER)  += aptxdec.o rawdec.o
diff --git a/libavformat/allformats.c b/libavformat/allformats.c
index f8527b1fd4..fd9e46e233 100644
--- a/libavformat/allformats.c
+++ b/libavformat/allformats.c
@@ -55,6 +55,7 @@ extern AVInputFormat  ff_anm_demuxer;
 extern AVInputFormat  ff_apc_demuxer;
 extern AVInputFormat  ff_ape_demuxer;
 extern AVInputFormat  ff_apm_demuxer;
+extern AVOutputFormat ff_apm_muxer;
 extern AVInputFormat  ff_apng_demuxer;
 extern AVOutputFormat ff_apng_muxer;
 extern AVInputFormat  ff_aptx_demuxer;
diff --git a/libavformat/apm.c b/libavformat/apm.c
index 666cb97fd3..32558287f9 100644
--- a/libavformat/apm.c
+++ b/libavformat/apm.c
@@ -1,5 +1,5 @@
 /*
- * Rayman 2 APM Demuxer
+ * Rayman 2 APM (De)muxer
  *
  * Copyright (C) 2020 Zane van Iperen (z...@zanevaniperen.com)
  *
@@ -21,6 +21,8 @@
  */
 #include "avformat.h"
 #include "internal.h"
+#include "rawenc.h"
+#include "libavutil/avassert.h"
 #include "libavutil/internal.h"
 #include "libavutil/intreadwrite.h"
 
@@ -48,13 +50,14 @@ typedef struct APMExtraData {
 uint32_tmagic;
 uint32_tfile_size;
 uint32_tdata_size;
-uint32_tunk1;
+int32_t unk1;
 uint32_tunk2;
 APMStatestate;
 uint32_tunk3[7];
 uint32_tdata;
 } APMExtraData;
 
+#if CONFIG_APM_DEMUXER
 static void apm_parse_extradata(APMExtraData *ext, const uint8_t *buf)
 {
 ext->magic  = AV_RL32(buf + 0);
@@ -198,3 +201,106 @@ AVInputFormat ff_apm_demuxer = {
 .read_header= apm_read_header,
 .read_packet= apm_read_packet
 };
+#endif
+
+#if CONFIG_APM_MUXER
+static int apm_write_init(AVFormatContext *s)
+{
+AVCodecParameters *par;
+
+if (s->nb_streams != 1) {
+av_log(s, AV_LOG_ERROR, "APM files have exactly one stream\n");
+return AVERROR(EINVAL);
+}
+
+par = s->streams[0]->codecpar;
+
+if (par->codec_id != AV_CODEC_ID_ADPCM_IMA_APM) {
+av_log(s, AV_LOG_ERROR, "%s codec not supported\n",
+   avcodec_get_name(par->codec_id));
+return AVERROR(EINVAL);
+}
+
+if (par->channels > 2) {
+av_log(s, AV_LOG_ERROR, "APM files only support up to 2 channels\n");
+return AVERROR(EINVAL);
+}
+
+if (par->extradata_size != APM_EXTRADATA_SIZE) {
+av_log(s, AV_LOG_ERROR, "Invalid/missing extradata\n");
+return AVERROR(EINVAL);
+}
+
+if (!(s->pb->seekable & AVIO_SEEKABLE_NORMAL)) {
+av_log(s, AV_LOG_ERROR, "Stream not seekable, unable to write output 
file\n");
+return AVERROR(EINVAL);
+}
+
+return 0;
+}
+
+static int apm_write_header(AVFormatContext *s)
+{
+uint8_t buf[APM_FILE_EXTRADATA_SIZE] = { 0 };
+AVCodecParameters *par = s->streams[0]->codecpar;
+
+/*
+ * Bodge a WAVEFORMATEX manually, ff_put_wav_header() can't
+ * be used because of the extra 2 bytes.
+ */
+avio_wl16(s->pb, APM_TAG_CODEC);
+avio_wl16(s->pb, par->channels);
+avio_wl32(s->pb, par->sample_rate);
+avio_wl32(s->pb, par->sample_rate * par->channels * 2);
+avio_wl16(s->pb, par->block_align);
+avio_wl16(s->pb, par->bits_per_coded_sample);
+avio_wl16(s->pb, APM_FILE_EXTRADATA_SIZE);
+
+avio_wl16(s->pb, 0); /* pad */
+
+/*
+ * Build the extradata. Assume the codec's given us correct data.
+ * File and data sizes are fixed later.
+ */
+AV_WL32(buf +  0, APM_TAG_VS12); /* magic */
+AV_WL32(buf + 12, -1);   /* unk1, always seems to be -1 */
+memcpy( buf + 20, par->extradata, APM_EXTRADATA_SIZE);
+AV_WL32(buf + 76, APM_TAG_DATA); /* data */
+
+avio_write(s->pb, buf, APM_FILE_EXTRADATA_SIZE);
+return 0;
+}
+
+static int apm_write_trailer(AVFormatContext *s)
+{
+int64_t file_size, data_size;
+
+file_size = avio_tell(s->pb);
+data_size = file_size - (APM_FILE_HEADER_SIZE + 2 + 

[FFmpeg-devel] [PATCH v5 0/6] adpcm_ima_apm encoder + apm muxer

[Zane van Iperen]

Add support for encoding adpcm_ima_apm and muxing to apm.

v5: [7]
* split out cosmetic changes into their own patch

v4:
* fix rebase issues

v3: [4][5][6]
* Support both extradata formats
  - fixes FATE failure + preserves compatibility
* EINVAL->ERANGE

v2: [1][2][3]
* fix mixed declarations and code
* remove unused variable
* fix array initialisation
* LOG_WARNING->LOG_ERROR
* reorder "name and probe fix"

[1] https://ffmpeg.org/pipermail/ffmpeg-devel/2020-June/264310.html
[2] https://ffmpeg.org/pipermail/ffmpeg-devel/2020-June/264309.html
[3] https://ffmpeg.org/pipermail/ffmpeg-devel/2020-June/264308.html
[4] https://ffmpeg.org/pipermail/ffmpeg-devel/2020-June/264328.html
[5] https://ffmpeg.org/pipermail/ffmpeg-devel/2020-June/264329.html
[6] https://ffmpeg.org/pipermail/ffmpeg-devel/2020-June/264326.html
[7] https://ffmpeg.org/pipermail/ffmpeg-devel/2020-June/265218.html

Zane van Iperen (6):
  avformat/apm: use new extradata format
  avformat/apm: fix variable/structure names and cosmetics
  avcodec: add adpcm_ima_apm encoder
  avformat: add apm muxer
  fate: add adpcm_ima_apm encoding test
  avcodec/adpcmenc: cleanup trellis checks

 Changelog  |   2 +
 doc/general.texi   |   2 +-
 libavcodec/Makefile|   1 +
 libavcodec/adpcmenc.c  |  63 ++---
 libavcodec/allcodecs.c |   1 +
 libavcodec/utils.c |   1 +
 libavcodec/version.h   |   2 +-
 libavformat/Makefile   |   3 +-
 libavformat/allformats.c   |   1 +
 libavformat/apm.c  | 240 -
 libavformat/version.h  |   2 +-
 tests/fate/acodec.mak  |   2 +
 tests/ref/acodec/adpcm-ima_apm |   4 +
 13 files changed, 241 insertions(+), 83 deletions(-)
 create mode 100644 tests/ref/acodec/adpcm-ima_apm

-- 
2.25.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 v5 2/6] avformat/apm: fix variable/structure names and cosmetics

[Zane van Iperen]

Signed-off-by: Zane van Iperen 
---
 libavformat/apm.c | 94 ---
 1 file changed, 48 insertions(+), 46 deletions(-)

diff --git a/libavformat/apm.c b/libavformat/apm.c
index b51b9fcbe6..666cb97fd3 100644
--- a/libavformat/apm.c
+++ b/libavformat/apm.c
@@ -44,37 +44,37 @@ typedef struct APMState {
 int32_t saved_l;
 } APMState;
 
-typedef struct APMVS12Chunk {
+typedef struct APMExtraData {
 uint32_tmagic;
 uint32_tfile_size;
 uint32_tdata_size;
 uint32_tunk1;
 uint32_tunk2;
 APMStatestate;
-uint32_tpad[7];
+uint32_tunk3[7];
 uint32_tdata;
-} APMVS12Chunk;
+} APMExtraData;
 
-static void apm_parse_vs12(APMVS12Chunk *vs12, const uint8_t *buf)
+static void apm_parse_extradata(APMExtraData *ext, const uint8_t *buf)
 {
-vs12->magic = AV_RL32(buf + 0);
-vs12->file_size = AV_RL32(buf + 4);
-vs12->data_size = AV_RL32(buf + 8);
-vs12->unk1  = AV_RL32(buf + 12);
-vs12->unk2  = AV_RL32(buf + 16);
-
-vs12->state.has_saved   = AV_RL32(buf + 20);
-vs12->state.predictor_r = AV_RL32(buf + 24);
-vs12->state.step_index_r= AV_RL32(buf + 28);
-vs12->state.saved_r = AV_RL32(buf + 32);
-vs12->state.predictor_l = AV_RL32(buf + 36);
-vs12->state.step_index_l= AV_RL32(buf + 40);
-vs12->state.saved_l = AV_RL32(buf + 44);
-
-for (int i = 0; i < FF_ARRAY_ELEMS(vs12->pad); i++)
-vs12->pad[i]= AV_RL32(buf + 48 + (i * 4));
-
-vs12->data  = AV_RL32(buf + 76);
+ext->magic  = AV_RL32(buf + 0);
+ext->file_size  = AV_RL32(buf + 4);
+ext->data_size  = AV_RL32(buf + 8);
+ext->unk1   = AV_RL32(buf + 12);
+ext->unk2   = AV_RL32(buf + 16);
+
+ext->state.has_saved= AV_RL32(buf + 20);
+ext->state.predictor_r  = AV_RL32(buf + 24);
+ext->state.step_index_r = AV_RL32(buf + 28);
+ext->state.saved_r  = AV_RL32(buf + 32);
+ext->state.predictor_l  = AV_RL32(buf + 36);
+ext->state.step_index_l = AV_RL32(buf + 40);
+ext->state.saved_l  = AV_RL32(buf + 44);
+
+for (int i = 0; i < FF_ARRAY_ELEMS(ext->unk3); i++)
+ext->unk3[i]= AV_RL32(buf + 48 + (i * 4));
+
+ext->data   = AV_RL32(buf + 76);
 }
 
 static int apm_probe(const AVProbeData *p)
@@ -98,7 +98,8 @@ static int apm_read_header(AVFormatContext *s)
 {
 int64_t ret;
 AVStream *st;
-APMVS12Chunk vs12;
+APMExtraData extradata;
+AVCodecParameters *par;
 uint8_t buf[APM_FILE_EXTRADATA_SIZE];
 
 if (!(st = avformat_new_stream(s, NULL)))
@@ -111,29 +112,30 @@ static int apm_read_header(AVFormatContext *s)
 if (avio_rl16(s->pb) != APM_TAG_CODEC)
 return AVERROR_INVALIDDATA;
 
-st->codecpar->channels  = avio_rl16(s->pb);
-st->codecpar->sample_rate   = avio_rl32(s->pb);
-st->codecpar->bit_rate  = avio_rl32(s->pb) * 8;
-st->codecpar->block_align   = avio_rl16(s->pb);
-st->codecpar->bits_per_coded_sample = avio_rl16(s->pb);
+par = st->codecpar;
+par->channels  = avio_rl16(s->pb);
+par->sample_rate   = avio_rl32(s->pb);
+par->bit_rate  = avio_rl32(s->pb) * 8;
+par->block_align   = avio_rl16(s->pb);
+par->bits_per_coded_sample = avio_rl16(s->pb);
 
 if (avio_rl16(s->pb) != APM_FILE_EXTRADATA_SIZE)
 return AVERROR_INVALIDDATA;
 
-if (st->codecpar->bits_per_coded_sample != 4)
+if (par->bits_per_coded_sample != 4)
 return AVERROR_INVALIDDATA;
 
-if (st->codecpar->channels == 2)
-st->codecpar->channel_layout= AV_CH_LAYOUT_STEREO;
-else if (st->codecpar->channels == 1)
-st->codecpar->channel_layout= AV_CH_LAYOUT_MONO;
+if (par->channels == 2)
+par->channel_layout= AV_CH_LAYOUT_STEREO;
+else if (par->channels == 1)
+par->channel_layout= AV_CH_LAYOUT_MONO;
 else
 return AVERROR_INVALIDDATA;
 
-st->codecpar->codec_type= AVMEDIA_TYPE_AUDIO;
-st->codecpar->codec_id  = AV_CODEC_ID_ADPCM_IMA_APM;
-st->codecpar->format= AV_SAMPLE_FMT_S16;
-st->codecpar->bits_per_raw_sample   = 16;
+par->codec_type= AVMEDIA_TYPE_AUDIO;
+par->codec_id  = AV_CODEC_ID_ADPCM_IMA_APM;
+par->format= AV_SAMPLE_FMT_S16;
+par->bits_per_raw_sample   = 16;
 
 /* Now skip the pad that ruins everything. */
 if ((ret = avio_skip(s->pb, 2)) < 0)
@@ -144,27 +146,27 @@ static int apm_read_header(AVFormatContext *s)
 else if (ret != APM_FILE_EXTRADATA_SIZE)
 return AVERROR(EIO);
 
-apm_parse_vs12(, buf);
+apm_parse_extradata(, buf);
 
-if (vs12.magic != APM_TAG_VS12 || vs12.data != APM_TAG_DATA)
+

[FFmpeg-devel] [PATCH v5 1/6] avformat/apm: use new extradata format

[Zane van Iperen]

Signed-off-by: Zane van Iperen 
---
 libavformat/Makefile |  2 +-
 libavformat/apm.c| 62 
 2 files changed, 35 insertions(+), 29 deletions(-)

diff --git a/libavformat/Makefile b/libavformat/Makefile
index 26af859a28..a4113fe644 100644
--- a/libavformat/Makefile
+++ b/libavformat/Makefile
@@ -93,7 +93,7 @@ OBJS-$(CONFIG_AMRWB_DEMUXER) += amr.o
 OBJS-$(CONFIG_ANM_DEMUXER)   += anm.o
 OBJS-$(CONFIG_APC_DEMUXER)   += apc.o
 OBJS-$(CONFIG_APE_DEMUXER)   += ape.o apetag.o img2.o
-OBJS-$(CONFIG_APM_DEMUXER)   += apm.o riffdec.o
+OBJS-$(CONFIG_APM_DEMUXER)   += apm.o
 OBJS-$(CONFIG_APNG_DEMUXER)  += apngdec.o
 OBJS-$(CONFIG_APNG_MUXER)+= apngenc.o
 OBJS-$(CONFIG_APTX_DEMUXER)  += aptxdec.o rawdec.o
diff --git a/libavformat/apm.c b/libavformat/apm.c
index dc59c16562..b51b9fcbe6 100644
--- a/libavformat/apm.c
+++ b/libavformat/apm.c
@@ -21,12 +21,13 @@
  */
 #include "avformat.h"
 #include "internal.h"
-#include "riff.h"
 #include "libavutil/internal.h"
 #include "libavutil/intreadwrite.h"
 
-#define APM_FILE_HEADER_SIZE20
-#define APM_VS12_CHUNK_SIZE 76
+#define APM_FILE_HEADER_SIZE18
+#define APM_FILE_EXTRADATA_SIZE 80
+#define APM_EXTRADATA_SIZE  28
+
 #define APM_MAX_READ_SIZE   4096
 
 #define APM_TAG_CODEC   0x2000
@@ -51,6 +52,7 @@ typedef struct APMVS12Chunk {
 uint32_tunk2;
 APMStatestate;
 uint32_tpad[7];
+uint32_tdata;
 } APMVS12Chunk;
 
 static void apm_parse_vs12(APMVS12Chunk *vs12, const uint8_t *buf)
@@ -71,6 +73,8 @@ static void apm_parse_vs12(APMVS12Chunk *vs12, const uint8_t 
*buf)
 
 for (int i = 0; i < FF_ARRAY_ELEMS(vs12->pad); i++)
 vs12->pad[i]= AV_RL32(buf + 48 + (i * 4));
+
+vs12->data  = AV_RL32(buf + 76);
 }
 
 static int apm_probe(const AVProbeData *p)
@@ -95,24 +99,29 @@ static int apm_read_header(AVFormatContext *s)
 int64_t ret;
 AVStream *st;
 APMVS12Chunk vs12;
-uint8_t buf[APM_VS12_CHUNK_SIZE];
+uint8_t buf[APM_FILE_EXTRADATA_SIZE];
 
 if (!(st = avformat_new_stream(s, NULL)))
 return AVERROR(ENOMEM);
 
-/* The header starts with a WAVEFORMATEX */
-if ((ret = ff_get_wav_header(s, s->pb, st->codecpar, APM_FILE_HEADER_SIZE, 
0)) < 0)
-return ret;
-
-if (st->codecpar->bits_per_coded_sample != 4)
+/*
+ * This is 98% a WAVEFORMATEX, but there's something screwy with the 
extradata
+ * that ff_get_wav_header() can't (and shouldn't) handle properly.
+ */
+if (avio_rl16(s->pb) != APM_TAG_CODEC)
 return AVERROR_INVALIDDATA;
 
-if (st->codecpar->codec_tag != APM_TAG_CODEC)
+st->codecpar->channels  = avio_rl16(s->pb);
+st->codecpar->sample_rate   = avio_rl32(s->pb);
+st->codecpar->bit_rate  = avio_rl32(s->pb) * 8;
+st->codecpar->block_align   = avio_rl16(s->pb);
+st->codecpar->bits_per_coded_sample = avio_rl16(s->pb);
+
+if (avio_rl16(s->pb) != APM_FILE_EXTRADATA_SIZE)
 return AVERROR_INVALIDDATA;
 
-/* ff_get_wav_header() does most of the work, but we need to fix a few 
things. */
-st->codecpar->codec_id  = AV_CODEC_ID_ADPCM_IMA_APM;
-st->codecpar->codec_tag = 0;
+if (st->codecpar->bits_per_coded_sample != 4)
+return AVERROR_INVALIDDATA;
 
 if (st->codecpar->channels == 2)
 st->codecpar->channel_layout= AV_CH_LAYOUT_STEREO;
@@ -121,38 +130,35 @@ static int apm_read_header(AVFormatContext *s)
 else
 return AVERROR_INVALIDDATA;
 
+st->codecpar->codec_type= AVMEDIA_TYPE_AUDIO;
+st->codecpar->codec_id  = AV_CODEC_ID_ADPCM_IMA_APM;
 st->codecpar->format= AV_SAMPLE_FMT_S16;
 st->codecpar->bits_per_raw_sample   = 16;
-st->codecpar->bit_rate  = st->codecpar->channels *
-  st->codecpar->sample_rate *
-  st->codecpar->bits_per_coded_sample;
 
-if ((ret = avio_read(s->pb, buf, APM_VS12_CHUNK_SIZE)) < 0)
+/* Now skip the pad that ruins everything. */
+if ((ret = avio_skip(s->pb, 2)) < 0)
+return ret;
+
+if ((ret = avio_read(s->pb, buf, APM_FILE_EXTRADATA_SIZE)) < 0)
 return ret;
-else if (ret != APM_VS12_CHUNK_SIZE)
+else if (ret != APM_FILE_EXTRADATA_SIZE)
 return AVERROR(EIO);
 
 apm_parse_vs12(, buf);
 
-if (vs12.magic != APM_TAG_VS12) {
+if (vs12.magic != APM_TAG_VS12 || vs12.data != APM_TAG_DATA)
 return AVERROR_INVALIDDATA;
-}
 
 if (vs12.state.has_saved) {
 avpriv_request_sample(s, "Saved Samples");
 return AVERROR_PATCHWELCOME;
 }
 
-if (avio_rl32(s->pb) != APM_TAG_DATA)
-return AVERROR_INVALIDDATA;
-
-if ((ret = ff_alloc_extradata(st->codecpar, 

Re: [FFmpeg-devel] Project orientation

[Kieran Kunhya]

> Is it? It works easily for me just using msmtp or a similar
> sendmail implementation that speaks SMTP.
> No need for a mail server.
> If you think it's an issue, maybe it needs to be documented?


See the comments about Gmail above from a few people.
Yes it can be done but it's another barrier to entry.

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] [GSoC 3/6] avformat/hls: use abr to switch streams

[Steven Liu]

Hongcheng Zhong  于2020年7月5日周日 下午7:35写道：
>
> From: spartazhc 
>
> When abr is enable, it will take over the task to call http to
> download segments, and will return a switch-request for hls to
> switch streams.
> For reason not to waste segments that have been downloaded,
> switch will become effective after old segments is used out.
> Abr cannot work with http_persistent option, and currently use
> http_multiple.
>
> Signed-off-by: spartazhc 
> ---
>  doc/demuxers.texi |   3 +
>  libavformat/hls.c | 222 --
>  2 files changed, 218 insertions(+), 7 deletions(-)
>
> diff --git a/doc/demuxers.texi b/doc/demuxers.texi
> index 3c15ab9eee..4cdbd95962 100644
> --- a/doc/demuxers.texi
> +++ b/doc/demuxers.texi
> @@ -321,6 +321,9 @@ available in a metadata key named "variant_bitrate".
>  It accepts the following options:
>
>  @table @option
> +@item abr
> +enable abr to switch streams.
> +
>  @item live_start_index
>  segment index to start live streams at (negative values are from the end).
>
> diff --git a/libavformat/hls.c b/libavformat/hls.c
> index 3798bdd5d1..b8f202e6a8 100644
> --- a/libavformat/hls.c
> +++ b/libavformat/hls.c
> @@ -189,6 +189,15 @@ struct variant {
>  char subtitles_group[MAX_FIELD_LEN];
>  };
>
> +struct throughput {
> +int n_throughputs;
> +
> +/* throughputs are in kbps, always record the last 20 times */
Why 20 times? Why not 10, 30, 40 times, or set by user?
> +float throughput_fifo[20];
> +int head;
> +int tail;
> +};
> +
>  typedef struct HLSContext {
>  AVClass *class;
>  AVFormatContext *ctx;
> @@ -213,8 +222,36 @@ typedef struct HLSContext {
>  int http_multiple;
>  int http_seekable;
>  AVIOContext *playlist_pb;
> +
> +int abr;
> +struct throughput *throughputs;
> +int can_switch;
> +int switch_request2;
> +int switch_delay;
> +int64_t switch_timestamp;
> +int64_t delta_timestamp;
> +int cur_pls;
>  } HLSContext;
>
> +static struct segment *next_segment(struct playlist *pls);
> +static int open_input(HLSContext *c, struct playlist *pls, struct segment 
> *seg, AVIOContext **in);
> +
> +static void sync_cur_seq(HLSContext *c) {
> +int i;
> +for (i = 0; i < c->n_playlists; i++) {
> +struct playlist *pls = c->playlists[i];
> +pls->cur_seq_no = c->cur_seq_no;
> +}
> +}
> +
> +static struct segment *next2_segment(struct playlist *pls)
> +{
> +int n = pls->cur_seq_no - pls->start_seq_no + 2;
> +if (n >= pls->n_segments)
> +return NULL;
> +return pls->segments[n];
> +}
> +
>  static void free_segment_dynarray(struct segment **segments, int n_segments)
>  {
>  int i;
> @@ -624,6 +661,33 @@ static int open_url_keepalive(AVFormatContext *s, 
> AVIOContext **pb,
>  #endif
>  }
>
> +static int update_throughputs(struct throughput *thr, float time, int 
> pb_size)
> +{
> +if (pb_size <= 0 || time <= 0)
> +return -1;
> +if (thr->n_throughputs < 20) {
have same question as the above comment in the struct.
> +++thr->n_throughputs;
> +thr->throughput_fifo[thr->tail] = (float)(pb_size) / time;

> +} else {
> +thr->throughput_fifo[thr->tail] = (float)(pb_size) / time;

> +++thr->head;
> +}
thr->throughput_fifo[thr->tail] = (float)(pb_size) / time;
What about move it here;
> +
> +thr->tail = (thr->tail + 1) % 20;
have same question as the above comment in the struct.
> +return 0;
> +}
> +
> +static int64_t get_switch_timestamp(HLSContext *c, struct playlist *pls)
> +{
> +int64_t pos = c->first_timestamp == AV_NOPTS_VALUE ?
> +  0 : c->first_timestamp;
> +
> +for (int i = 0; i < pls->cur_seq_no + 2; i++) {
> +pos += pls->segments[i]->duration;
> +}
> +return pos;
> +}
> +
>  static int open_url(AVFormatContext *s, AVIOContext **pb, const char *url,
>  AVDictionary *opts, AVDictionary *opts2, int 
> *is_http_out)
>  {
> @@ -633,7 +697,10 @@ static int open_url(AVFormatContext *s, AVIOContext 
> **pb, const char *url,
>  int ret;
>  int is_http = 0;
>
> -if (av_strstart(url, "crypto", NULL)) {
> +if (av_strstart(url, "abr", NULL)) {
> +if (url[3] == '+' || url[3] == ':')
> +proto_name = avio_find_protocol_name(url + 4);
> +} else if (av_strstart(url, "crypto", NULL)) {
>  if (url[6] == '+' || url[6] == ':')
>  proto_name = avio_find_protocol_name(url + 7);
>  } else if (av_strstart(url, "data", NULL)) {
> @@ -665,6 +732,8 @@ static int open_url(AVFormatContext *s, AVIOContext **pb, 
> const char *url,
>
>  if (!strncmp(proto_name, url, strlen(proto_name)) && 
> url[strlen(proto_name)] == ':')
>  ;
> +else if (av_strstart(url, "abr", NULL) && !strncmp(proto_name, url + 4, 
> strlen(proto_name)) && url[4 + strlen(proto_name)] == ':')
> +;
>  else if (av_strstart(url, "crypto", NULL) && !strncmp(proto_name, url + 
> 7, 

Re: [FFmpeg-devel] [PATCH] [GSoC 1/6] avformat/abr: Adaptive Bitrate support

[Steven Liu]

Hongcheng Zhong  于2020年7月5日周日 下午7:35写道：
>
> From: spartazhc 
>
> Add abr module for hls/dash.
>
> Signed-off-by: spartazhc 
> ---
>  doc/protocols.texi  |   7 +
>  libavformat/Makefile|   1 +
>  libavformat/abr.c   | 282 
>  libavformat/protocols.c |   1 +
>  4 files changed, 291 insertions(+)
>  create mode 100644 libavformat/abr.c
>
> diff --git a/doc/protocols.texi b/doc/protocols.texi
> index 644a17963d..fc80209884 100644
> --- a/doc/protocols.texi
> +++ b/doc/protocols.texi
> @@ -51,6 +51,13 @@ in microseconds.
>
>  A description of the currently available protocols follows.
>
> +@section abr
> +
> +Adaptive bitrate sub-protocol work for hls/dash.
> +
> +The abr protocol takes stream information from hls/dash as input,
> +use bandwidth estimation to decide whether to switch or not.
> +
>  @section amqp
>
>  Advanced Message Queueing Protocol (AMQP) version 0-9-1 is a broker based
> diff --git a/libavformat/Makefile b/libavformat/Makefile
> index 26af859a28..3c08289d5e 100644
> --- a/libavformat/Makefile
> +++ b/libavformat/Makefile
> @@ -588,6 +588,7 @@ OBJS-$(CONFIG_LIBOPENMPT_DEMUXER)+= libopenmpt.o
>  OBJS-$(CONFIG_VAPOURSYNTH_DEMUXER)   += vapoursynth.o
>
>  # protocols I/O
> +OBJS-$(CONFIG_ABR_PROTOCOL)  += abr.o
>  OBJS-$(CONFIG_ASYNC_PROTOCOL)+= async.o
>  OBJS-$(CONFIG_APPLEHTTP_PROTOCOL)+= hlsproto.o
>  OBJS-$(CONFIG_BLURAY_PROTOCOL)   += bluray.o
> diff --git a/libavformat/abr.c b/libavformat/abr.c
> new file mode 100644
> index 00..b7d00efcae
> --- /dev/null
> +++ b/libavformat/abr.c
> @@ -0,0 +1,282 @@
> +/*
> + * Adaptive Bitrate Module for HLS / DASH
> + * Copyright (c) 2020 Hongcheng Zhong
> + *
> + * This file is part of FFmpeg.
> + *
> + * FFmpeg is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU Lesser General Public
> + * License as published by the Free Software Foundation; either
> + * version 2.1 of the License, or (at your option) any later version.
> + *
> + * FFmpeg is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
> + * Lesser General Public License for more details.
> + *
> + * You should have received a copy of the GNU Lesser General Public
> + * License along with FFmpeg; if not, write to the Free Software
> + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 
> USA
> + */
> +
> +#include "avformat.h"
> +#include "libavutil/opt.h"
> +#include "libavutil/time.h"
> +#include "libavutil/avstring.h"
> +#include "url.h"
> +#include 
> +
> +enum ABRFormatType {
> +ABR_TYPE_HLS,
> +ABR_TYPE_DASH
> +};
> +
> +typedef struct variant_bitrate {
> +int value;
> +int index;
> +} variant_bitrate;
> +
> +typedef struct ABRContext {
> +AVClass *class;
> +URLContext *hd;
> +AVDictionary *abr_params;
> +AVDictionary *abr_metadata;
> +enum ABRFormatType format;
> +int cur_pls;
> +int can_switch;
> +int n_variants;
> +variant_bitrate *variants_bitrate;
> +int index;
> +int n_throughputs;
> +float *throughputs;
> +int64_t position;
> +} ABRContext;
> +
> +static float harmonic_mean(int num, float* arr)
> +{
> +float tmp = 0;
> +
> +if (num <= 0) return 0;
> +
> +for (size_t i = 0; i < num; i++) {
> +tmp += 1 / arr[i];
> +}
> +
> +return num / tmp;
> +}
> +
> +static int hls_param_parse(ABRContext *c, const char *key, const char *value)
> +{
> +if (!av_strcasecmp(key, "cur_pls")) {
> +c->cur_pls = atoi(value);
> +} else if (!av_strcasecmp(key, "can_switch")) {
> +c->can_switch = atoi(value);
> +} else if (!av_strcasecmp(key, "n_variants")) {
> +c->n_variants = atoi(value);
> +c->variants_bitrate = av_mallocz(sizeof(variant_bitrate) * 
> c->n_variants);
> +if (!c->variants_bitrate)
> +return -1;
> +} else if (av_strstart(key, "variant_bitrate", NULL)) {
> +c->variants_bitrate[c->index].value = atoi(value);
> +c->variants_bitrate[c->index].index = c->index;
> +c->index++;
> +} else if (!av_strcasecmp(key, "n_throughputs")) {
> +c->n_throughputs = atoi(value);
> +c->index = 0;
> +if (c->n_throughputs > 0) {
> +c->throughputs = av_malloc(sizeof(float) * c->n_throughputs);
> +if (!c->throughputs)
> +return -1;
> +}
> +} else if (av_strstart(key, "throughputs", NULL))
> +c->throughputs[c->index++] = atof(value);
> +return 0;
> +}
> +
> +static int dash_param_parse(ABRContext *c, const char *key, const char 
> *value)
> +{
> +return 0;
> +}
> +
> +static int abr_param_parse(ABRContext *c, enum ABRFormatType type, const 
> char *key, const char *value)
> +{
> +if (type == ABR_TYPE_HLS) {
> +

Re: [FFmpeg-devel] Project orientation

[Reimar Döffinger]

On Sun, Jul 05, 2020 at 10:50:14PM +0200, Michael Niedermayer wrote:
> To Achieve this, we could try to
> * attract more developers doing reviews, i have generally suggested
>   contributors to help review other peoples patches. Maybe i should
>   take a step back and ask developers to ask developers to do this
>   instead. It is a way out of this problem
> * make people have a burning desire to review patches. I understand
>   this would work very well but iam not sure how to achieve this
> * pay developers to do reviews, i think we do not yet have the funds
>   for this as reviews take alot of time and thus this would not be
>   cheap

Maybe there's not enough people like me to matter, but for me it's
that I don't have time to read the whole mailing list to find the
patches I might be able to contribute to with a review.
I also add the caveat I wouldn't be able to do a super-deep technical
review, but there seem to be enough integer overflow issues (and
I mean the we-all-agree-it's-a-bug type) and other bugs getting
through that anyone familiar with reviewing code would be able
to contribute.
___
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] RfP Candidates

[Jean-Baptiste Kempf]

On Mon, Jul 6, 2020, at 09:48, Paul B Mahol wrote:
> On 7/3/20, Jean-Baptiste Kempf  wrote:
> > On Thu, Jul 2, 2020, at 12:46, Jean-Baptiste Kempf wrote:
> >> We'll accept candidates until Saturday night, 23:59UTC.
> >
> > 24-hours remaining ping.
> >
> > Everyone can make it :)
> 
> Time passed.
> 
> Is there enough candidates?

Sure.

> Or we vote like in North Korea?

I've never been to North Korea. :)

-- 
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] RfP Candidates

[Paul B Mahol]

On 7/3/20, Jean-Baptiste Kempf  wrote:
> On Thu, Jul 2, 2020, at 12:46, Jean-Baptiste Kempf wrote:
>> We'll accept candidates until Saturday night, 23:59UTC.
>
> 24-hours remaining ping.
>
> Everyone can make it :)

Time passed.

Is there enough candidates?
Or we vote like in North Korea?

> --
> 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".
___
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] Project orientation

[Reimar Döffinger]

On Sun, Jul 05, 2020 at 06:18:20PM +0100, Kieran Kunhya wrote:
> On Sun, Jul 5, 2020 at 6:01 PM Kieran Kunhya  wrote:
> >
> > Going back to the original point in hand.
> > Many patches aren't getting reviewed and pushed any more.
> >
> > In part this is because in 2020 whether we like it or not mailing
> > lists are not the way to do Git based development.
> > The kernel is the exception to the rule, as Linus says it has a whole
> > load of grey-bearded system maintainers who are paid full time to work
> > on it.
> >
> > For new contributors git send-email is annoying. For people wanting to
> > push, the .mbox format is annoying, Gmail doesn't support it any more.
> > And you can't get new contributors to start using CLI based email
> > clients or run their own mail server, that's not going to happen.
> >
> > A solution like Gitlab is the only way forward. It has worked well for
> > dav1d, it can run regression tests on all platforms for all commits:
> > https://code.videolan.org/videolan/dav1d
> >
> > Merges are done with one push of a button. Yes, the branch sprawl is
> > not great but it's better than now.
> > It has inline patch reviews which are nice.
> >
> > Whether we like it or not web interfaces are the way 95% of the world
> > does Git and we have to move with the times.
>
> Not my intention to top post but gmail hides quoted text.
> Forgot to add that git send-email is quite complex to setup now
> without your own mail server.
> This also restricts our ability to add new developers.

Is it? It works easily for me just using msmtp or a similar
sendmail implementation that speaks SMTP.
No need for a mail server.
If you think it's an issue, maybe it needs to be documented?
That said, email lists are bad for quick drive-by patches
and there is far too much on this list.
Then again, github/gitlab aren't good for reviews either,
and plain atrocious for community and discussion, IMHO.

Best regards,
Reimar
___
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] Project orientation

[Steinar H. Gunderson]

On Sun, Jul 05, 2020 at 11:42:19PM +, Soft Works wrote:
> When then reviewer would not have to look for code style and could
> assume that this is all right, he would be free to focus on the actual things.

FWIW: At work, we went to clang-format to simply automate away 90%
of these things completely. (Some things, like naming conventions, are still
manual.) I was skeptical at first, but it showed to be a huge win; maybe not
as much because it made the reviewer's job easier, but because it made it
_harder_. When you can no longer make a few easy comments about braces and
that's the review, you're forced to go more in-depth, and quality of review
goes up.

This is probably too drastic a step for FFmpeg at this point, but I wanted
to mention it anyway.

/* Steinar */
-- 
Homepage: https://www.sesse.net/
___
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] dnn_backend_native: Add overflow check for length calculation.

[Reimar Döffinger]

We should not silently allocate an incorrect sized buffer.
Fixes trac issue #8718.
TODO1: calculate_operand_dims_count is almost identical code,
should they be merged and its usages check for overflow?
TODO2: the -1 return value seems questionable to me, but is
aligned with the return value used for malloc failure.
Probably both ought to be changed to AVERROR(ENOMEM).

Signed-off-by: Reimar Döffinger 
---
 libavfilter/dnn/dnn_backend_native.c   | 10 +-
 libavfilter/dnn/dnn_backend_native.h   |  2 ++
 libavfilter/dnn/dnn_backend_native_layer_conv2d.c  |  2 ++
 libavfilter/dnn/dnn_backend_native_layer_depth2space.c |  2 ++
 libavfilter/dnn/dnn_backend_native_layer_mathbinary.c  |  2 ++
 libavfilter/dnn/dnn_backend_native_layer_mathunary.c   |  2 ++
 libavfilter/dnn/dnn_backend_native_layer_maximum.c |  2 ++
 libavfilter/dnn/dnn_backend_native_layer_pad.c |  2 ++
 8 files changed, 23 insertions(+), 1 deletion(-)

diff --git a/libavfilter/dnn/dnn_backend_native.c 
b/libavfilter/dnn/dnn_backend_native.c
index 35236fc66f..a685efb092 100644
--- a/libavfilter/dnn/dnn_backend_native.c
+++ b/libavfilter/dnn/dnn_backend_native.c
@@ -79,6 +79,8 @@ static DNNReturnType set_input_output_native(void *model, 
DNNData *input, const

 av_freep(>data);
 oprd->length = calculate_operand_data_length(oprd);
+if (oprd->length <= 0)
+return DNN_ERROR;
 oprd->data = av_malloc(oprd->length);
 if (!oprd->data)
 return DNN_ERROR;
@@ -295,7 +297,13 @@ int32_t calculate_operand_dims_count(const DnnOperand 
*oprd)
 int32_t calculate_operand_data_length(const DnnOperand* oprd)
 {
 // currently, we just support DNN_FLOAT
-return oprd->dims[0] * oprd->dims[1] * oprd->dims[2] * oprd->dims[3] * 
sizeof(float);
+uint64_t len = sizeof(float);
+for (int i = 0; i < 4; i++) {
+len *= oprd->dims[i];
+if (len > INT32_MAX)
+return 0;
+}
+return len;
 }

 void ff_dnn_free_model_native(DNNModel **model)
diff --git a/libavfilter/dnn/dnn_backend_native.h 
b/libavfilter/dnn/dnn_backend_native.h
index bec63be450..62191ffe88 100644
--- a/libavfilter/dnn/dnn_backend_native.h
+++ b/libavfilter/dnn/dnn_backend_native.h
@@ -120,6 +120,8 @@ DNNReturnType ff_dnn_execute_model_native(const DNNModel 
*model, DNNData *output

 void ff_dnn_free_model_native(DNNModel **model);

+// NOTE: User must check for error (return value <= 0) to handle
+// case like integer overflow.
 int32_t calculate_operand_data_length(const DnnOperand *oprd);
 int32_t calculate_operand_dims_count(const DnnOperand *oprd);
 #endif
diff --git a/libavfilter/dnn/dnn_backend_native_layer_conv2d.c 
b/libavfilter/dnn/dnn_backend_native_layer_conv2d.c
index c05bb5eca9..a2202e4073 100644
--- a/libavfilter/dnn/dnn_backend_native_layer_conv2d.c
+++ b/libavfilter/dnn/dnn_backend_native_layer_conv2d.c
@@ -113,6 +113,8 @@ int dnn_execute_layer_conv2d(DnnOperand *operands, const 
int32_t *input_operand_
 output_operand->dims[3] = conv_params->output_num;
 output_operand->data_type = operands[input_operand_index].data_type;
 output_operand->length = calculate_operand_data_length(output_operand);
+if (output_operand->length <= 0)
+return -1;
 output_operand->data = av_realloc(output_operand->data, 
output_operand->length);
 if (!output_operand->data)
 return -1;
diff --git a/libavfilter/dnn/dnn_backend_native_layer_depth2space.c 
b/libavfilter/dnn/dnn_backend_native_layer_depth2space.c
index 324871ceca..2c8bddf23d 100644
--- a/libavfilter/dnn/dnn_backend_native_layer_depth2space.c
+++ b/libavfilter/dnn/dnn_backend_native_layer_depth2space.c
@@ -75,6 +75,8 @@ int dnn_execute_layer_depth2space(DnnOperand *operands, const 
int32_t *input_ope
 output_operand->dims[3] = new_channels;
 output_operand->data_type = operands[input_operand_index].data_type;
 output_operand->length = calculate_operand_data_length(output_operand);
+if (output_operand->length <= 0)
+return -1;
 output_operand->data = av_realloc(output_operand->data, 
output_operand->length);
 if (!output_operand->data)
 return -1;
diff --git a/libavfilter/dnn/dnn_backend_native_layer_mathbinary.c 
b/libavfilter/dnn/dnn_backend_native_layer_mathbinary.c
index b239a20058..dd42c329a9 100644
--- a/libavfilter/dnn/dnn_backend_native_layer_mathbinary.c
+++ b/libavfilter/dnn/dnn_backend_native_layer_mathbinary.c
@@ -91,6 +91,8 @@ int dnn_execute_layer_math_binary(DnnOperand *operands, const 
int32_t *input_ope

 output->data_type = input->data_type;
 output->length = calculate_operand_data_length(output);
+if (output->length <= 0)
+return DNN_ERROR;
 output->data = av_realloc(output->data, output->length);
 if (!output->data)
 return DNN_ERROR;
diff --git a/libavfilter/dnn/dnn_backend_native_layer_mathunary.c 
b/libavfilter/dnn/dnn_backend_native_layer_mathunary.c
index 42615c43d5..8a4bd3c600 100644
--- 

[FFmpeg-devel] [PATCH] dnn_backend_native: Add overflow check for length calculation.

[Reimar Döffinger]

We should not silently allocate an incorrect sized buffer.
Fixes trac issue #8718.
TODO1: calculate_operand_dims_count is almost identical code,
should they be merged and its usages check for overflow?
TODO2: the -1 return value seems questionable to me, but is
aligned with the return value used for malloc failure.
Probably both ought to be changed to AVERROR(ENOMEM).

Signed-off-by: Reimar Döffinger 
---
 libavfilter/dnn/dnn_backend_native.c   | 10 +-
 libavfilter/dnn/dnn_backend_native.h   |  2 ++
 libavfilter/dnn/dnn_backend_native_layer_conv2d.c  |  2 ++
 libavfilter/dnn/dnn_backend_native_layer_depth2space.c |  2 ++
 libavfilter/dnn/dnn_backend_native_layer_mathbinary.c  |  2 ++
 libavfilter/dnn/dnn_backend_native_layer_mathunary.c   |  2 ++
 libavfilter/dnn/dnn_backend_native_layer_maximum.c |  2 ++
 libavfilter/dnn/dnn_backend_native_layer_pad.c |  2 ++
 8 files changed, 23 insertions(+), 1 deletion(-)

diff --git a/libavfilter/dnn/dnn_backend_native.c 
b/libavfilter/dnn/dnn_backend_native.c
index 35236fc66f..a685efb092 100644
--- a/libavfilter/dnn/dnn_backend_native.c
+++ b/libavfilter/dnn/dnn_backend_native.c
@@ -79,6 +79,8 @@ static DNNReturnType set_input_output_native(void *model, 
DNNData *input, const

 av_freep(>data);
 oprd->length = calculate_operand_data_length(oprd);
+if (oprd->length <= 0)
+return DNN_ERROR;
 oprd->data = av_malloc(oprd->length);
 if (!oprd->data)
 return DNN_ERROR;
@@ -295,7 +297,13 @@ int32_t calculate_operand_dims_count(const DnnOperand 
*oprd)
 int32_t calculate_operand_data_length(const DnnOperand* oprd)
 {
 // currently, we just support DNN_FLOAT
-return oprd->dims[0] * oprd->dims[1] * oprd->dims[2] * oprd->dims[3] * 
sizeof(float);
+uint64_t len = sizeof(float);
+for (int i = 0; i < 4; i++) {
+len *= oprd->dims[i];
+if (len > INT32_MAX)
+return 0;
+}
+return len;
 }

 void ff_dnn_free_model_native(DNNModel **model)
diff --git a/libavfilter/dnn/dnn_backend_native.h 
b/libavfilter/dnn/dnn_backend_native.h
index bec63be450..62191ffe88 100644
--- a/libavfilter/dnn/dnn_backend_native.h
+++ b/libavfilter/dnn/dnn_backend_native.h
@@ -120,6 +120,8 @@ DNNReturnType ff_dnn_execute_model_native(const DNNModel 
*model, DNNData *output

 void ff_dnn_free_model_native(DNNModel **model);

+// NOTE: User must check for error (return value <= 0) to handle
+// case like integer overflow.
 int32_t calculate_operand_data_length(const DnnOperand *oprd);
 int32_t calculate_operand_dims_count(const DnnOperand *oprd);
 #endif
diff --git a/libavfilter/dnn/dnn_backend_native_layer_conv2d.c 
b/libavfilter/dnn/dnn_backend_native_layer_conv2d.c
index c05bb5eca9..a2202e4073 100644
--- a/libavfilter/dnn/dnn_backend_native_layer_conv2d.c
+++ b/libavfilter/dnn/dnn_backend_native_layer_conv2d.c
@@ -113,6 +113,8 @@ int dnn_execute_layer_conv2d(DnnOperand *operands, const 
int32_t *input_operand_
 output_operand->dims[3] = conv_params->output_num;
 output_operand->data_type = operands[input_operand_index].data_type;
 output_operand->length = calculate_operand_data_length(output_operand);
+if (output_operand->length <= 0)
+return -1;
 output_operand->data = av_realloc(output_operand->data, 
output_operand->length);
 if (!output_operand->data)
 return -1;
diff --git a/libavfilter/dnn/dnn_backend_native_layer_depth2space.c 
b/libavfilter/dnn/dnn_backend_native_layer_depth2space.c
index 324871ceca..2c8bddf23d 100644
--- a/libavfilter/dnn/dnn_backend_native_layer_depth2space.c
+++ b/libavfilter/dnn/dnn_backend_native_layer_depth2space.c
@@ -75,6 +75,8 @@ int dnn_execute_layer_depth2space(DnnOperand *operands, const 
int32_t *input_ope
 output_operand->dims[3] = new_channels;
 output_operand->data_type = operands[input_operand_index].data_type;
 output_operand->length = calculate_operand_data_length(output_operand);
+if (output_operand->length <= 0)
+return -1;
 output_operand->data = av_realloc(output_operand->data, 
output_operand->length);
 if (!output_operand->data)
 return -1;
diff --git a/libavfilter/dnn/dnn_backend_native_layer_mathbinary.c 
b/libavfilter/dnn/dnn_backend_native_layer_mathbinary.c
index b239a20058..bb30ccf154 100644
--- a/libavfilter/dnn/dnn_backend_native_layer_mathbinary.c
+++ b/libavfilter/dnn/dnn_backend_native_layer_mathbinary.c
@@ -91,6 +91,8 @@ int dnn_execute_layer_math_binary(DnnOperand *operands, const 
int32_t *input_ope

 output->data_type = input->data_type;
 output->length = calculate_operand_data_length(output);
+if (output->length)
+return DNN_ERROR;
 output->data = av_realloc(output->data, output->length);
 if (!output->data)
 return DNN_ERROR;
diff --git a/libavfilter/dnn/dnn_backend_native_layer_mathunary.c 
b/libavfilter/dnn/dnn_backend_native_layer_mathunary.c
index 42615c43d5..8a4bd3c600 100644
--- 

Re: [FFmpeg-devel] [PATCH V2 12/12] dnn-layer-math-unary-test: add unit test for atanh

[Guo, Yejun]

> -Original Message-
> From: ffmpeg-devel  On Behalf Of Ting Fu
> Sent: 2020年6月29日 22:54
> To: ffmpeg-devel@ffmpeg.org
> Subject: [FFmpeg-devel] [PATCH V2 12/12] dnn-layer-math-unary-test: add unit
> test for atanh
> 
> Signed-off-by: Ting Fu 
> ---
>  tests/dnn/dnn-layer-mathunary-test.c | 10 +++---
>  1 file changed, 7 insertions(+), 3 deletions(-)

this patch set looks good to me, will push soon, 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".