[FFmpeg-devel] [PATCH] avformat/flvdec: RtmpSampleAccess no longer breaks stream detection
Since release 4.2, FFmpeg fails to detect the correct streams in an RTMP
stream that contains a |RtmpSampleAccess AMF object prior to the
onMetaData AMF object. In the debug log it would show "[flv] Unknown
type |RtmpSampleAccess".
This functionality broke in commit d7638d8dfc3c4ffd0dc18a64937a5a07ed67b354
as unknown metadata packets now result in an opaque data stream, and the
|RtmpSampleAccess packet was an "unknown" metadata packet type.
With this change the RTMP streams are correctly detected when there
is a |RtmpSampleAccess object prior to the onMetaData object.
Signed-off-by: Peter van der Spek
---
libavformat/flvdec.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavformat/flvdec.c b/libavformat/flvdec.c
index 0862273..d480d0b 100644
--- a/libavformat/flvdec.c
+++ b/libavformat/flvdec.c
@@ -715,7 +715,7 @@ static int flv_read_metabody(AVFormatContext *s, int64_t
next_pos)
if (!strcmp(buffer, "onCaptionInfo"))
return TYPE_ONCAPTIONINFO;
-if (strcmp(buffer, "onMetaData") && strcmp(buffer, "onCuePoint")) {
+if (strcmp(buffer, "onMetaData") && strcmp(buffer, "onCuePoint") &&
strcmp(buffer, "|RtmpSampleAccess")) {
av_log(s, AV_LOG_DEBUG, "Unknown type %s\n", buffer);
return TYPE_UNKNOWN;
}
--
2.10.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 2/4] libavcodec/j2kenc: Fix tag tree coding
On Wed, Aug 19, 2020 at 01:10:35AM +0530, gautamr...@gmail.com wrote: > From: Gautam Ramakrishnan > > This patch fixes tag tree coding for JPEG2000 > encoder. > --- > libavcodec/j2kenc.c | 43 +-- > libavcodec/jpeg2000.c | 1 + > libavcodec/jpeg2000.h | 1 + > 3 files changed, 27 insertions(+), 18 deletions(-) > > diff --git a/libavcodec/j2kenc.c b/libavcodec/j2kenc.c > index 16863f8e8c..1c31e48d61 100644 > --- a/libavcodec/j2kenc.c > +++ b/libavcodec/j2kenc.c > @@ -239,30 +239,37 @@ static void j2k_flush(Jpeg2000EncoderContext *s) > /* tag tree routines */ > > /** code the value stored in node */ > -static void tag_tree_code(Jpeg2000EncoderContext *s, Jpeg2000TgtNode *node, > int threshold) > +static void tag_tree_code(Jpeg2000EncoderContext *s, Jpeg2000TgtNode *node, > int threshold, int log) This breaks build until a subsequent patch [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB I do not agree with what you have to say, but I'll defend to the death your right to say it. -- Voltaire signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] Set AVSTREAM_PARSE_HEADERS flag for AV1 MP4 streams.
From: Vikas Agarwal
It allow AV1 header parsing and help initialize chroma format and other
info properly.
Chroma format wasn't correct if we use below code:
avformat_find_stream_info(fmtc, NULL); iVideoStream =
av_find_best_stream(fmtc, AVMEDIA_TYPE_VIDEO, -1, -1, NULL, 0);
eChromaFormat = (AVPixelFormat)fmtc->streams[iVideoStream]->codecpar->
format;
---
libavformat/mov.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/libavformat/mov.c b/libavformat/mov.c
index 1532e74d67..4d4b5c0f48 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -7615,6 +7615,8 @@ static int mov_read_header(AVFormatContext *s)
av_log(s, AV_LOG_VERBOSE, "Forcing full parsing for mp3 stream\n");
st->need_parsing = AVSTREAM_PARSE_FULL;
}
+if (st->codecpar->codec_id == AV_CODEC_ID_AV1)
+st->need_parsing = AVSTREAM_PARSE_HEADERS;
}
if (mov->trex_data) {
--
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".
Re: [FFmpeg-devel] [PATCH 1/1] Added avs2 tags for MKV
Ze Yuan: >>> The ordinary versions of these players don't use libavformat's Matroska >>> demuxer at all, so I presume that your patch intends to fix the problem >>> by changing how the files are muxed. > > Right. Without avs2 tag, MKV will use AVI compatible mode automatically I > think. > >>> Matroska does not support AVS2 natively at all atm. If you want to >>> change that, you should open an issue/pull request at [1]. And you >>> should refrain from already creating such files (or use a CodecID like >>> "V_AVS2/EXPERIMENTAL"). As long as there is no official support for AVS2 >>> in Matroska, there won't be support for it in FFmpeg. > > I think we can still try. It seems HEVC was supported by many tools before > MKV mapping added. Also the encoder (ffmpeg) and the popular > players(ffplay/vlc/mpc-hc) all work perfectly with this change. > For a long time, MKVToolNix de-facto set the standards for how to mux certain codecs into Matroska and other tools (like FFmpeg) simply followed its lead. This was never how it was supposed to happen, but it was necessary to get things done. But times have changed and today a codec mapping is a prerequisite for adding support for a codec. - 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 4/5] avcodec/dvbsubdec: request samples for missing coding methods
On Tue, Aug 18, 2020 at 10:55:34PM +0200, Clément Bœsch wrote: > --- > libavcodec/dvbsubdec.c | 7 --- > 1 file changed, 4 insertions(+), 3 deletions(-) LGTM thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Any man who breaks a law that conscience tells him is unjust and willingly accepts the penalty by staying in jail in order to arouse the conscience of the community on the injustice of the law is at that moment expressing the very highest respect for law. - Martin Luther King Jr signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 1/5] avcodec/dvbsubenc: merge rectangle encode code blocks
On Tue, Aug 18, 2020 at 10:55:31PM +0200, Clément Bœsch wrote: > --- > libavcodec/dvbsubenc.c | 3 --- > 1 file changed, 3 deletions(-) probably ok thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Observe your enemies, for they first find out your faults. -- Antisthenes signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 2/2] qsv: remove audio error code
On Wed, Aug 19, 2020 at 2:10 PM Haihao Xiang wrote:
>
> ---
> libavcodec/qsv.c | 3 ---
> 1 file changed, 3 deletions(-)
>
> diff --git a/libavcodec/qsv.c b/libavcodec/qsv.c
> index faa424bb68..6776b745b9 100644
> --- a/libavcodec/qsv.c
> +++ b/libavcodec/qsv.c
> @@ -143,8 +143,6 @@ static const struct {
> { MFX_ERR_INVALID_VIDEO_PARAM, AVERROR(EINVAL), "invalid video
> parameters" },
> { MFX_ERR_UNDEFINED_BEHAVIOR, AVERROR_BUG, "undefined
> behavior" },
> { MFX_ERR_DEVICE_FAILED,AVERROR(EIO),"device failed"
>},
> -{ MFX_ERR_INCOMPATIBLE_AUDIO_PARAM, AVERROR(EINVAL), "incompatible audio
> parameters"},
> -{ MFX_ERR_INVALID_AUDIO_PARAM, AVERROR(EINVAL), "invalid audio
> parameters" },
>
> { MFX_WRN_IN_EXECUTION, 0, "operation in
> execution" },
> { MFX_WRN_DEVICE_BUSY, 0, "device busy"
>},
> @@ -154,7 +152,6 @@ static const struct {
> { MFX_WRN_VALUE_NOT_CHANGED,0, "value is
> saturated" },
> { MFX_WRN_OUT_OF_RANGE, 0, "value out of
> range" },
> { MFX_WRN_FILTER_SKIPPED, 0, "filter skipped"
>},
> -{ MFX_WRN_INCOMPATIBLE_AUDIO_PARAM, 0, "incompatible audio
> parameters"},
> };
>
> int ff_qsv_map_error(mfxStatus mfx_err, const char **desc)
> --
> 2.25.1
LGTM
___
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] qsv: remove audio error code
Haihao Xiang (12020-08-19):
> ---
> libavcodec/qsv.c | 3 ---
> 1 file changed, 3 deletions(-)
>
> diff --git a/libavcodec/qsv.c b/libavcodec/qsv.c
> index faa424bb68..6776b745b9 100644
> --- a/libavcodec/qsv.c
> +++ b/libavcodec/qsv.c
> @@ -143,8 +143,6 @@ static const struct {
> { MFX_ERR_INVALID_VIDEO_PARAM, AVERROR(EINVAL), "invalid video
> parameters" },
> { MFX_ERR_UNDEFINED_BEHAVIOR, AVERROR_BUG, "undefined
> behavior" },
> { MFX_ERR_DEVICE_FAILED,AVERROR(EIO),"device failed"
>},
> -{ MFX_ERR_INCOMPATIBLE_AUDIO_PARAM, AVERROR(EINVAL), "incompatible audio
> parameters"},
> -{ MFX_ERR_INVALID_AUDIO_PARAM, AVERROR(EINVAL), "invalid audio
> parameters" },
>
> { MFX_WRN_IN_EXECUTION, 0, "operation in
> execution" },
> { MFX_WRN_DEVICE_BUSY, 0, "device busy"
>},
> @@ -154,7 +152,6 @@ static const struct {
> { MFX_WRN_VALUE_NOT_CHANGED,0, "value is
> saturated" },
> { MFX_WRN_OUT_OF_RANGE, 0, "value out of
> range" },
> { MFX_WRN_FILTER_SKIPPED, 0, "filter skipped"
>},
> -{ MFX_WRN_INCOMPATIBLE_AUDIO_PARAM, 0, "incompatible audio
> parameters"},
> };
>
> int ff_qsv_map_error(mfxStatus mfx_err, const char **desc)
Why?
Regards,
--
Nicolas George
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [aarch64] yuv2planeX - unroll outer loop by 4 to increase performance by 6.3%
On Tue, Aug 18, 2020 at 01:11:30PM -0500, Sebastian Pop wrote: > Hi, > > Unrolling by 4 the outer loop in yuv2planeX reduces the number of cache > accesses by 7.5%. > The values loaded for the filter are used in the 4 unrolled iterations and > avoids reloading 3 times the same values. > The performance was measured on an Arm64 Neoverse-N1 Graviton2 c6g.metal > instance with the following command: > $ perf stat -e cache-references ./ffmpeg_g -nostats -f lavfi -i > testsrc2=4k:d=2 -vf bench=start,scale=1024x1024,bench=stop -f null - > > before: 1551591469 cache-references > after: 1436140431 cache-references > > before: [bench @ 0xc62b7d30] t:0.013226 avg:0.013219 max:0.013537 > min:0.012975 > after: [bench @ 0xd84f3d30] t:0.012355 avg:0.012381 max:0.013164 > min:0.012158 > > Ok to commit? faster is better obviously, so if its tested with odd sizes and arm developers had a chance to comment. it should be ok one potential improvment is to use the unrolled code for odd width too and use the non unrolled for the end thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Many things microsoft did are stupid, but not doing something just because microsoft did it is even more stupid. If everything ms did were stupid they would be bankrupt already. signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [RFC PATCH 3/4] libavcodec/jpeg2000: Modify cleanup
From: Gautam Ramakrishnan
This patch makes the ff_jpeg2000_cleanup
function take in an extra parameter which
indicates whether it is called from the
encoder or decoder.
---
libavcodec/j2kenc.c | 2 +-
libavcodec/jpeg2000.c| 2 +-
libavcodec/jpeg2000.h| 2 +-
libavcodec/jpeg2000dec.c | 2 +-
4 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/libavcodec/j2kenc.c b/libavcodec/j2kenc.c
index d9777fe07f..8699296434 100644
--- a/libavcodec/j2kenc.c
+++ b/libavcodec/j2kenc.c
@@ -1218,7 +1218,7 @@ static void cleanup(Jpeg2000EncoderContext *s)
for (tileno = 0; tileno < s->numXtiles * s->numYtiles; tileno++){
for (compno = 0; compno < s->ncomponents; compno++){
Jpeg2000Component *comp = s->tile[tileno].comp + compno;
-ff_jpeg2000_cleanup(comp, codsty);
+ff_jpeg2000_cleanup(comp, codsty, 1);
}
av_freep(&s->tile[tileno].comp);
}
diff --git a/libavcodec/jpeg2000.c b/libavcodec/jpeg2000.c
index 3d3e7ec313..70c25a0ca2 100644
--- a/libavcodec/jpeg2000.c
+++ b/libavcodec/jpeg2000.c
@@ -580,7 +580,7 @@ void ff_jpeg2000_reinit(Jpeg2000Component *comp,
Jpeg2000CodingStyle *codsty)
}
}
-void ff_jpeg2000_cleanup(Jpeg2000Component *comp, Jpeg2000CodingStyle *codsty)
+void ff_jpeg2000_cleanup(Jpeg2000Component *comp, Jpeg2000CodingStyle *codsty,
int isencoder)
{
int reslevelno, bandno, precno;
for (reslevelno = 0;
diff --git a/libavcodec/jpeg2000.h b/libavcodec/jpeg2000.h
index ad58b1ae88..fee9607e86 100644
--- a/libavcodec/jpeg2000.h
+++ b/libavcodec/jpeg2000.h
@@ -272,7 +272,7 @@ int ff_jpeg2000_init_component(Jpeg2000Component *comp,
void ff_jpeg2000_reinit(Jpeg2000Component *comp, Jpeg2000CodingStyle *codsty);
-void ff_jpeg2000_cleanup(Jpeg2000Component *comp, Jpeg2000CodingStyle *codsty);
+void ff_jpeg2000_cleanup(Jpeg2000Component *comp, Jpeg2000CodingStyle *codsty,
int isencoder);
static inline int needs_termination(int style, int passno) {
if (style & JPEG2000_CBLK_BYPASS) {
diff --git a/libavcodec/jpeg2000dec.c b/libavcodec/jpeg2000dec.c
index 624542c2f8..c5192d007f 100644
--- a/libavcodec/jpeg2000dec.c
+++ b/libavcodec/jpeg2000dec.c
@@ -2123,7 +2123,7 @@ static void jpeg2000_dec_cleanup(Jpeg2000DecoderContext
*s)
Jpeg2000Component *comp = s->tile[tileno].comp + compno;
Jpeg2000CodingStyle *codsty = s->tile[tileno].codsty + compno;
-ff_jpeg2000_cleanup(comp, codsty);
+ff_jpeg2000_cleanup(comp, codsty, 0);
}
av_freep(&s->tile[tileno].comp);
av_freep(&s->tile[tileno].packed_headers);
--
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] [RFC PATCH 1/4] libavcodec/jpeg2000: Make tag tree functions non static
From: Gautam Ramakrishnan
This patch makes the tag_tree_zero() and tag_tree_size()
functions non static and callable from other files.
---
libavcodec/jpeg2000.c | 12 ++--
libavcodec/jpeg2000.h | 3 +++
2 files changed, 9 insertions(+), 6 deletions(-)
diff --git a/libavcodec/jpeg2000.c b/libavcodec/jpeg2000.c
index 1aca31ffa4..26e09fbe38 100644
--- a/libavcodec/jpeg2000.c
+++ b/libavcodec/jpeg2000.c
@@ -39,7 +39,7 @@
/* tag tree routines */
/* allocate the memory for tag tree */
-static int32_t tag_tree_size(int w, int h)
+int32_t ff_tag_tree_size(int w, int h)
{
int64_t res = 0;
while (w > 1 || h > 1) {
@@ -57,7 +57,7 @@ static Jpeg2000TgtNode *ff_jpeg2000_tag_tree_init(int w, int
h)
Jpeg2000TgtNode *res, *t, *t2;
int32_t tt_size;
-tt_size = tag_tree_size(w, h);
+tt_size = ff_tag_tree_size(w, h);
t = res = av_mallocz_array(tt_size, sizeof(*t));
if (!res)
@@ -82,9 +82,9 @@ static Jpeg2000TgtNode *ff_jpeg2000_tag_tree_init(int w, int
h)
return res;
}
-static void tag_tree_zero(Jpeg2000TgtNode *t, int w, int h)
+void ff_tag_tree_zero(Jpeg2000TgtNode *t, int w, int h)
{
-int i, siz = tag_tree_size(w, h);
+int i, siz = ff_tag_tree_size(w, h);
for (i = 0; i < siz; i++) {
t[i].val = 0;
@@ -567,8 +567,8 @@ void ff_jpeg2000_reinit(Jpeg2000Component *comp,
Jpeg2000CodingStyle *codsty)
Jpeg2000Band *band = rlevel->band + bandno;
for(precno = 0; precno < rlevel->num_precincts_x *
rlevel->num_precincts_y; precno++) {
Jpeg2000Prec *prec = band->prec + precno;
-tag_tree_zero(prec->zerobits, prec->nb_codeblocks_width,
prec->nb_codeblocks_height);
-tag_tree_zero(prec->cblkincl, prec->nb_codeblocks_width,
prec->nb_codeblocks_height);
+ff_tag_tree_zero(prec->zerobits, prec->nb_codeblocks_width,
prec->nb_codeblocks_height);
+ff_tag_tree_zero(prec->cblkincl, prec->nb_codeblocks_width,
prec->nb_codeblocks_height);
for (cblkno = 0; cblkno < prec->nb_codeblocks_width *
prec->nb_codeblocks_height; cblkno++) {
Jpeg2000Cblk *cblk = prec->cblk + cblkno;
cblk->length = 0;
diff --git a/libavcodec/jpeg2000.h b/libavcodec/jpeg2000.h
index 5b0627c3dc..c3437b02fe 100644
--- a/libavcodec/jpeg2000.h
+++ b/libavcodec/jpeg2000.h
@@ -290,4 +290,7 @@ static inline int needs_termination(int style, int passno) {
return 0;
}
+int32_t ff_tag_tree_size(int w, int h);
+void ff_tag_tree_zero(Jpeg2000TgtNode *t, int w, int h);
+
#endif /* AVCODEC_JPEG2000_H */
--
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] [RFC PATCH 4/4] libavcodec/j2kenc: Support for multiple layers
From: Gautam Ramakrishnan
This patch allows setting a compression ratio and to
set multiple layers. The user has to input a compression
ratio for each layer.
The per layer compression ration can be set as follows:
-layer_rates "r1,r2,...rn"
for to create 'n' layers.
---
libavcodec/j2kenc.c | 443 ++
libavcodec/jpeg2000.c | 13 +-
libavcodec/jpeg2000.h | 10 +
3 files changed, 384 insertions(+), 82 deletions(-)
diff --git a/libavcodec/j2kenc.c b/libavcodec/j2kenc.c
index 8699296434..b09db36c14 100644
--- a/libavcodec/j2kenc.c
+++ b/libavcodec/j2kenc.c
@@ -32,6 +32,7 @@
* Copyright (c) 2003-2007, Francois-Olivier Devaux and Antonin Descampe
* Copyright (c) 2005, Herve Drolon, FreeImage Team
* Copyright (c) 2007, Callum Lerwick
+ * Copyright (c) 2020, Gautam Ramakrishnan
* All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
@@ -100,6 +101,7 @@ static const int dwt_norms[2][4][10] = { //
[dwt_type][band][rlevel] (multiplied
typedef struct {
Jpeg2000Component *comp;
+ double *layer_rates;
} Jpeg2000Tile;
typedef struct {
@@ -126,12 +128,15 @@ typedef struct {
Jpeg2000QuantStyle qntsty;
Jpeg2000Tile *tile;
+int layer_rates[100];
int format;
int pred;
int sop;
int eph;
int prog;
+int nlayers;
+char *lr_str;
} Jpeg2000EncoderContext;
@@ -332,7 +337,7 @@ static int put_cod(Jpeg2000EncoderContext *s)
bytestream_put_byte(&s->buf, scod); // Scod
// SGcod
bytestream_put_byte(&s->buf, s->prog); // progression level
-bytestream_put_be16(&s->buf, 1); // num of layers
+bytestream_put_be16(&s->buf, s->nlayers); // num of layers
if(s->avctx->pix_fmt == AV_PIX_FMT_YUV444P){
bytestream_put_byte(&s->buf, 0); // unspecified
}else{
@@ -411,6 +416,31 @@ static uint8_t *put_sot(Jpeg2000EncoderContext *s, int
tileno)
return psotptr;
}
+static void compute_rates(Jpeg2000EncoderContext* s)
+{
+int i, j;
+int layno, compno;
+for (i = 0; i < s->numYtiles; i++) {
+for (j = 0; j < s->numXtiles; j++) {
+Jpeg2000Tile *tile = &s->tile[s->numXtiles * i + j];
+for (compno = 0; compno < s->ncomponents; compno++) {
+int tilew = tile->comp[compno].coord[0][1] -
tile->comp[compno].coord[0][0];
+int tileh = tile->comp[compno].coord[1][1] -
tile->comp[compno].coord[1][0];
+int scale = (compno?1 << s->chroma_shift[0]:1) * (compno?1 <<
s->chroma_shift[1]:1);
+for (layno = 0; layno < s->nlayers; layno++) {
+if (s->layer_rates[layno] > 0.0f) {
+tile->layer_rates[layno] += (double)(tilew * tileh) *
s->ncomponents * s->cbps[compno] /
+
(double)(s->layer_rates[layno] * 8 * scale);
+} else {
+tile->layer_rates[layno] = 0.0f;
+}
+}
+}
+}
+}
+
+}
+
/**
* compute the sizes of tiles, resolution levels, bands, etc.
* allocate memory for them
@@ -448,6 +478,10 @@ static int init_tiles(Jpeg2000EncoderContext *s)
for (j = 0; j < 2; j++)
comp->coord[i][j] = comp->coord_o[i][j] =
ff_jpeg2000_ceildivpow2(comp->coord[i][j], s->chroma_shift[i]);
+tile->layer_rates = av_mallocz_array(s->ncomponents,
sizeof(*tile->layer_rates));
+if (!tile->layer_rates)
+return AVERROR(ENOMEM);
+
if ((ret = ff_jpeg2000_init_component(comp,
codsty,
qntsty,
@@ -459,6 +493,7 @@ static int init_tiles(Jpeg2000EncoderContext *s)
return ret;
}
}
+compute_rates(s);
return 0;
}
@@ -701,6 +736,8 @@ static void encode_cblk(Jpeg2000EncoderContext *s,
Jpeg2000T1Context *t1, Jpeg20
}
cblk->passes[passno].rate = ff_mqc_flush_to(&t1->mqc,
cblk->passes[passno].flushed, &cblk->passes[passno].flushed_len);
+cblk->passes[passno].rate -= cblk->passes[passno].flushed_len;
+
wmsedec += (int64_t)nmsedec << (2*bpno);
cblk->passes[passno].disto = wmsedec;
@@ -733,10 +770,12 @@ static void putnumpasses(Jpeg2000EncoderContext *s, int n)
}
-static int encode_packet(Jpeg2000EncoderContext *s, Jpeg2000ResLevel *rlevel,
int precno,
- uint8_t *expn, int numgbits, int packetno)
+static int encode_packet(Jpeg2000EncoderContext *s, Jpeg2000ResLevel *rlevel,
int layno,
+ int precno, uint8_t *expn, int numgbits, int packetno,
+ int nlayers)
{
int bandno, empty = 1;
+int i;
// init bitstream
*s->buf = 0;
s->bit_index = 0;
@@ -748,18 +787,61 @@ static int encode_packet(
[FFmpeg-devel] [RFC PATCH 2/4] libavcodec/j2kenc: Fix tag tree coding
From: Gautam Ramakrishnan
This patch fixes tag tree coding for JPEG2000
encoder.
---
libavcodec/j2kenc.c | 41 -
libavcodec/jpeg2000.c | 1 +
libavcodec/jpeg2000.h | 1 +
3 files changed, 26 insertions(+), 17 deletions(-)
diff --git a/libavcodec/j2kenc.c b/libavcodec/j2kenc.c
index 16863f8e8c..d9777fe07f 100644
--- a/libavcodec/j2kenc.c
+++ b/libavcodec/j2kenc.c
@@ -242,27 +242,34 @@ static void j2k_flush(Jpeg2000EncoderContext *s)
static void tag_tree_code(Jpeg2000EncoderContext *s, Jpeg2000TgtNode *node,
int threshold)
{
Jpeg2000TgtNode *stack[30];
-int sp = 1, curval = 0;
-stack[0] = node;
+int sp = -1, curval = 0;
-node = node->parent;
-while(node){
-if (node->vis){
-curval = node->val;
-break;
-}
-node->vis++;
-stack[sp++] = node;
+while(node->parent){
+stack[++sp] = node;
node = node->parent;
}
-while(--sp >= 0){
-if (stack[sp]->val >= threshold){
-put_bits(s, 0, threshold - curval);
-break;
+
+while (1) {
+if (curval > node->temp_val)
+node->temp_val = curval;
+else {
+curval = node->temp_val;
}
-put_bits(s, 0, stack[sp]->val - curval);
-put_bits(s, 1, 1);
-curval = stack[sp]->val;
+while (curval < threshold) {
+if (curval >= node->val) {
+if (!node->vis) {
+node->vis = 1;
+put_bits(s, 1, 1);
+}
+break;
+}
+put_bits(s, 0, 1);
+curval++;
+}
+node->temp_val = curval;
+if (sp < 0)
+break;
+node = stack[sp--];
}
}
diff --git a/libavcodec/jpeg2000.c b/libavcodec/jpeg2000.c
index 26e09fbe38..3d3e7ec313 100644
--- a/libavcodec/jpeg2000.c
+++ b/libavcodec/jpeg2000.c
@@ -88,6 +88,7 @@ void ff_tag_tree_zero(Jpeg2000TgtNode *t, int w, int h)
for (i = 0; i < siz; i++) {
t[i].val = 0;
+t[i].temp_val = 0;
t[i].vis = 0;
}
}
diff --git a/libavcodec/jpeg2000.h b/libavcodec/jpeg2000.h
index c3437b02fe..ad58b1ae88 100644
--- a/libavcodec/jpeg2000.h
+++ b/libavcodec/jpeg2000.h
@@ -127,6 +127,7 @@ typedef struct Jpeg2000T1Context {
typedef struct Jpeg2000TgtNode {
uint8_t val;
+uint8_t temp_val;
uint8_t vis;
struct Jpeg2000TgtNode *parent;
} Jpeg2000TgtNode;
--
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".
Re: [FFmpeg-devel] [PATCH v4]libavfilter/asrc_atone.c : generate algorithmic music
Ashutosh Pradhan (12020-08-18): > Generate algorithmic music using riffs, lindenmayer systems, cellular > automaton and rhythm algorithms. > Fixed the error that was causing segmentation fault in the previous patch. Thanks. (But this last sentence should be below the --- in the mail, not in the commit message.) I also notice that the output with the options given in example is much more interesting than the default, and can justify the usefulness of the filter. Good job! Two points: - Since it uses fluidsynth, the filter would probably better be called like that, especially since it does not produces tones but almost-real instrument sounds. Let us keep "atone" for a 100% internal implementation. - I would really appreciate an answer to this question: >> Since you know the API best, could you say in a few words how hard it >> would be to get rid of fluidsynth and use an internal synthesizer >> instead? Regards, -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v5 2/5] lavc/avs3: add AVS3 related definitions
hwr...@126.com (12020-08-19): > From: hwren > > Signed-off-by: hwren > --- > libavcodec/Makefile | 2 + > libavcodec/avs3.c | 95 + > libavcodec/avs3.h | 52 + > 3 files changed, 149 insertions(+) > create mode 100644 libavcodec/avs3.c > create mode 100644 libavcodec/avs3.h Except ff_avs3_frame_rate_tab, all these tables are only used in the decoder. Is there a reason you want them in a separate header? Regards, -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [mov] See if mfra makes up the difference for an incomplete sidx.
On Tue, Aug 18, 2020 at 02:04:04PM +0100, Derek Buitenhuis wrote: > On 18/08/2020 04:57, Dale Curtis wrote: > > Can't be an else statement since the prior clause modifies is_complete. > > Ah, you're right. > > New version LGTM. if someone applies this, please add a "avformat/mov: " or equivalent prefix to teh commit message thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The day soldiers stop bringing you their problems is the day you have stopped leading them. They have either lost confidence that you can help or concluded you do not care. Either case is a failure of leadership. - Colin Powell signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v5 2/5] lavc/avs3: add AVS3 related definitions
hwr...@126.com:
> From: hwren
>
> Signed-off-by: hwren
> ---
> libavcodec/Makefile | 2 +
> libavcodec/avs3.c | 95 +
> libavcodec/avs3.h | 52 +
> 3 files changed, 149 insertions(+)
> create mode 100644 libavcodec/avs3.c
> create mode 100644 libavcodec/avs3.h
>
> diff --git a/libavcodec/Makefile b/libavcodec/Makefile
> index 3431ba2dca..e1e0c4629d 100644
> --- a/libavcodec/Makefile
> +++ b/libavcodec/Makefile
> @@ -6,6 +6,7 @@ HEADERS = ac3_parser.h
> \
>avcodec.h \
>avdct.h \
>avfft.h \
> + avs3.h\
>bsf.h \
>codec.h \
>codec_desc.h \
> @@ -32,6 +33,7 @@ OBJS = ac3_parser.o
> \
> avdct.o \
> avpacket.o \
> avpicture.o \
> + avs3.o \
> bitstream.o \
> bitstream_filter.o \
> bitstream_filters.o \
> diff --git a/libavcodec/avs3.c b/libavcodec/avs3.c
> new file mode 100644
> index 00..8587e36def
> --- /dev/null
> +++ b/libavcodec/avs3.c
> @@ -0,0 +1,95 @@
> +/*
> + * AVS3 related definition
> + *
> + * Copyright (C) 2020 Huiwen Ren,
> + *
> + * 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 "avs3.h"
> +
> +const AVRational ff_avs3_frame_rate_tab[16] = {
> +{ 0, 0 }, // forbid
> +{ 24000, 1001},
> +{ 24 , 1 },
> +{ 25 , 1 },
> +{ 3, 1001},
> +{ 30 , 1 },
> +{ 50 , 1 },
> +{ 6, 1001},
> +{ 60 , 1 },
> +{ 100 , 1 },
> +{ 120 , 1 },
> +{ 200 , 1 },
> +{ 240 , 1 },
> +{ 300 , 1 },
> +{ 0, 0 }, // reserved
> +{ 0, 0 } // reserved
> +};
> +
> +const int ff_avs3_color_primaries_tab[10] = {
> +AVCOL_PRI_RESERVED0 ,// 0
> +AVCOL_PRI_BT709 ,// 1
> +AVCOL_PRI_UNSPECIFIED ,// 2
> +AVCOL_PRI_RESERVED,// 3
> +AVCOL_PRI_BT470M ,// 4
> +AVCOL_PRI_BT470BG ,// 5
> +AVCOL_PRI_SMPTE170M ,// 6
> +AVCOL_PRI_SMPTE240M ,// 7
> +AVCOL_PRI_FILM,// 8
> +AVCOL_PRI_BT2020 // 9
> +};
> +
> +const enum AVPictureType ff_avs3_image_type[4] = {
> +AV_PICTURE_TYPE_NONE,
> +AV_PICTURE_TYPE_I,
> +AV_PICTURE_TYPE_P,
> +AV_PICTURE_TYPE_B
> +};
These two coincide with the values of the constants, so they could be
removed.
> \ No newline at end of file
This should be fixed.
- Andreas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] dnn/native: rename struct ConvolutionalNetwork to NativeModel
Signed-off-by: Ting Fu
---
libavfilter/dnn/dnn_backend_native.c | 112 +--
libavfilter/dnn/dnn_backend_native.h | 4 +-
libavfilter/dnn/dnn_backend_tf.c | 24 +++---
3 files changed, 70 insertions(+), 70 deletions(-)
diff --git a/libavfilter/dnn/dnn_backend_native.c
b/libavfilter/dnn/dnn_backend_native.c
index adc652a2c4..0be9c0b53c 100644
--- a/libavfilter/dnn/dnn_backend_native.c
+++ b/libavfilter/dnn/dnn_backend_native.c
@@ -30,10 +30,10 @@
static DNNReturnType get_input_native(void *model, DNNData *input, const char
*input_name)
{
-ConvolutionalNetwork *network = (ConvolutionalNetwork *)model;
+NativeModel *native_model = (NativeModel *)model;
-for (int i = 0; i < network->operands_num; ++i) {
-DnnOperand *oprd = &network->operands[i];
+for (int i = 0; i < native_model->operands_num; ++i) {
+DnnOperand *oprd = &native_model->operands[i];
if (strcmp(oprd->name, input_name) == 0) {
if (oprd->type != DOT_INPUT)
return DNN_ERROR;
@@ -52,15 +52,15 @@ static DNNReturnType get_input_native(void *model, DNNData
*input, const char *i
static DNNReturnType set_input_output_native(void *model, DNNData *input,
const char *input_name, const char **output_names, uint32_t nb_output)
{
-ConvolutionalNetwork *network = (ConvolutionalNetwork *)model;
+NativeModel *native_model = (NativeModel *)model;
DnnOperand *oprd = NULL;
-if (network->layers_num <= 0 || network->operands_num <= 0)
+if (native_model->layers_num <= 0 || native_model->operands_num <= 0)
return DNN_ERROR;
/* inputs */
-for (int i = 0; i < network->operands_num; ++i) {
-oprd = &network->operands[i];
+for (int i = 0; i < native_model->operands_num; ++i) {
+oprd = &native_model->operands[i];
if (strcmp(oprd->name, input_name) == 0) {
if (oprd->type != DOT_INPUT)
return DNN_ERROR;
@@ -88,24 +88,24 @@ static DNNReturnType set_input_output_native(void *model,
DNNData *input, const
input->data = oprd->data;
/* outputs */
-network->nb_output = 0;
-av_freep(&network->output_indexes);
-network->output_indexes = av_mallocz_array(nb_output,
sizeof(*network->output_indexes));
-if (!network->output_indexes)
+native_model->nb_output = 0;
+av_freep(&native_model->output_indexes);
+native_model->output_indexes = av_mallocz_array(nb_output,
sizeof(*native_model->output_indexes));
+if (!native_model->output_indexes)
return DNN_ERROR;
for (uint32_t i = 0; i < nb_output; ++i) {
const char *output_name = output_names[i];
-for (int j = 0; j < network->operands_num; ++j) {
-oprd = &network->operands[j];
+for (int j = 0; j < native_model->operands_num; ++j) {
+oprd = &native_model->operands[j];
if (strcmp(oprd->name, output_name) == 0) {
-network->output_indexes[network->nb_output++] = j;
+native_model->output_indexes[native_model->nb_output++] = j;
break;
}
}
}
-if (network->nb_output != nb_output)
+if (native_model->nb_output != nb_output)
return DNN_ERROR;
return DNN_SUCCESS;
@@ -122,7 +122,7 @@ DNNModel *ff_dnn_load_model_native(const char
*model_filename, const char *optio
char *buf;
size_t size;
int version, header_size, major_version_expected = 1;
-ConvolutionalNetwork *network = NULL;
+NativeModel *native_model = NULL;
AVIOContext *model_file_context;
int file_size, dnn_size, parsed_size;
int32_t layer;
@@ -167,29 +167,29 @@ DNNModel *ff_dnn_load_model_native(const char
*model_filename, const char *optio
dnn_size += 4;
header_size = dnn_size;
-network = av_mallocz(sizeof(ConvolutionalNetwork));
-if (!network){
+native_model = av_mallocz(sizeof(NativeModel));
+if (!native_model){
goto fail;
}
-model->model = (void *)network;
+model->model = (void *)native_model;
avio_seek(model_file_context, file_size - 8, SEEK_SET);
-network->layers_num = (int32_t)avio_rl32(model_file_context);
-network->operands_num = (int32_t)avio_rl32(model_file_context);
+native_model->layers_num = (int32_t)avio_rl32(model_file_context);
+native_model->operands_num = (int32_t)avio_rl32(model_file_context);
dnn_size += 8;
avio_seek(model_file_context, header_size, SEEK_SET);
-network->layers = av_mallocz(network->layers_num * sizeof(Layer));
-if (!network->layers){
+native_model->layers = av_mallocz(native_model->layers_num *
sizeof(Layer));
+if (!native_model->layers){
goto fail;
}
-network->operands = av_mallocz(network->operands_num * sizeof(DnnOperand));
-if (!network->operands){
+native_model->operands = av_mallocz(native_model->operands_num *
sizeof(DnnOperand));
+if (!native_model->o
Re: [FFmpeg-devel] [PATCH 7/7] avcodec/aacdec_template: add support for 22.2 / channel_config 13
On Tue, Aug 18, 2020 at 7:45 PM Paul B Mahol wrote: > > On 8/18/20, Jan Ekström wrote: > > On Tue, Aug 18, 2020 at 12:45 PM Jan Ekström wrote: > >> > >> On Tue, Aug 18, 2020 at 12:17 PM Paul B Mahol wrote: > >> > > >> > I think there is open bug report about SEGV regarding this commit on > >> > trac. > >> > > >> > Please revert or fix ASAP! > >> > > >> > >> Thank you for letting me know about this. I will take a look at this > >> after work. Please do not yell at me, I am not your enemy. > >> > >> Jan > >> > > > > If this is about https://trac.ffmpeg.org/ticket/8845 , that is a > > *fuzzer* sample causing issues. > > > > While it is not nice, and I *am* now looking at it, why on earth do > > you have to go to this "revert or fix ASAP!" drama? > > Because open security issues are never ok. > Sorry for disturbing you. > It's OK, you just would have gotten my attention quicker in other ways if you wanted to get that. For future reference, please keep in mind that I do attempt to not do public hurrying or shaming in a very public media unless I feel there is clearly no other way forward, and thus I do get upset if people consider me as someone requiring such behavior, as I consider myself being able to respond to queries relatively quickly and to not create complete breakages in master/releases and leave them be even to the disdain of others and with no response to queries. You can usually get in touch with me more quickly on IRC, ML requires me to a) open it up and b) have enough time on a non-dayjob related machine to word a proper response. Jan ___ 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 3/5] lavc/avs3_parser: add avs3 parser
On Wed, Aug 19, 2020 at 14:25:54 +0800, hwr...@126.com wrote:
> +for (; cur < buf_size; ++cur) {
> +state = (state << 8) | buf[cur];
> +if (ISPIC(buf[cur])){
> +++cur;
ffmpeg prefers the "cur++" style (twice in this block, and elsewhere).
> +// Skip bits: resv(1)
> +//bitrate_low(18)
> +//resv(1)
> +//bitrate_high(12)
> +//low_delay
> +skip_bits(&gb, 32);
Is "low_delay" part of the skipped bits? The rest already adds up to
32.
> +av_log(avctx, AV_LOG_DEBUG,
> + "avs3 parse seq hdr: profile %d; coded wxh: %dx%d; "
> + "frame_rate_code %d\n", profile, avctx->width,
> avctx->height, ratecode);
Incorrect indentation.
Cheers,
Moritz
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v5 2/5] lavc/avs3: add AVS3 related definitions
On Wed, Aug 19, 2020 at 14:25:53 +0800, hwr...@126.com wrote: > + * AVS3 related definition definitions? > +}; > \ No newline at end of file Please amend a carriage return to the last line. > + * AVS3 related definition definitions? Moritz ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v5 5/5] lavc, doc: add libuavs3d video decoder wrapper
On Wed, Aug 19, 2020 at 14:25:56 +0800, hwr...@126.com wrote: > - AV1 Low overhead bitstream format demuxer > +- AVS3 video decoder via libuavs3d I wonder whether the raw demuxer should have been mentioned in its respective patch. Moritz ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v4]libavfilter/asrc_atone.c : generate algorithmic music
On 8/19/20, Nicolas George wrote: > Ashutosh Pradhan (12020-08-18): >> Generate algorithmic music using riffs, lindenmayer systems, cellular >> automaton and rhythm algorithms. >> Fixed the error that was causing segmentation fault in the previous >> patch. > > Thanks. (But this last sentence should be below the --- in the mail, not > in the commit message.) > > I also notice that the output with the options given in example is much > more interesting than the default, and can justify the usefulness of the > filter. Good job! > > Two points: > > - Since it uses fluidsynth, the filter would probably better be called > like that, especially since it does not produces tones but almost-real > instrument sounds. Let us keep "atone" for a 100% internal > implementation. Hmm, something about fluidsynthsounds? > > - I would really appreciate an answer to this question: > >>> Since you know the API best, could you say in a few words how hard it >>> would be to get rid of fluidsynth and use an internal synthesizer >>> instead? Writing excellent synthesizer is not trivial task. > > Regards, > > -- > Nicolas George > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 1/3] avcodec/h2645_parse: always return 0 on successful h{264, evc}_parse_nal_header() calls
On 8/12/2020 3:25 PM, James Almer wrote:
> HEVC NALs are no longer being skipped based on their nuh_layer_id
> value since ad326379c6.
>
> Signed-off-by: James Almer
> ---
> libavcodec/h2645_parse.c | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/libavcodec/h2645_parse.c b/libavcodec/h2645_parse.c
> index 2e03871640..a7cdf76e87 100644
> --- a/libavcodec/h2645_parse.c
> +++ b/libavcodec/h2645_parse.c
> @@ -287,7 +287,7 @@ static int get_bit_length(H2645NAL *nal, int
> skip_trailing_zeros)
>
> /**
> * @return AVERROR_INVALIDDATA if the packet is not a valid NAL unit,
> - * 0 if the unit should be skipped, 1 otherwise
> + * 0 otherwise
> */
> static int hevc_parse_nal_header(H2645NAL *nal, void *logctx)
> {
> @@ -307,7 +307,7 @@ static int hevc_parse_nal_header(H2645NAL *nal, void
> *logctx)
> "nal_unit_type: %d(%s), nuh_layer_id: %d, temporal_id: %d\n",
> nal->type, hevc_nal_unit_name(nal->type), nal->nuh_layer_id,
> nal->temporal_id);
>
> -return 1;
> +return 0;
> }
>
> static int h264_parse_nal_header(H2645NAL *nal, void *logctx)
> @@ -324,7 +324,7 @@ static int h264_parse_nal_header(H2645NAL *nal, void
> *logctx)
> "nal_unit_type: %d(%s), nal_ref_idc: %d\n",
> nal->type, h264_nal_unit_name(nal->type), nal->ref_idc);
>
> -return 1;
> +return 0;
> }
>
> static int find_next_start_code(const uint8_t *buf, const uint8_t *next_avc)
> @@ -504,7 +504,7 @@ int ff_h2645_packet_split(H2645Packet *pkt, const uint8_t
> *buf, int length,
> ret = hevc_parse_nal_header(nal, logctx);
> else
> ret = h264_parse_nal_header(nal, logctx);
> -if (ret <= 0 || nal->size <= 0 || nal->size_bits <= 0) {
> +if (ret < 0 || nal->size <= 0 || nal->size_bits <= 0) {
> if (ret < 0) {
> av_log(logctx, AV_LOG_WARNING, "Invalid NAL unit %d,
> skipping.\n",
> nal->type);
>
Will apply the set soon.
___
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] Set AVSTREAM_PARSE_HEADERS flag for AV1 MP4 streams.
On 8/19/2020 6:50 AM, ManojGuptaBonda wrote:
> From: Vikas Agarwal
>
> It allow AV1 header parsing and help initialize chroma format and other
> info properly.
>
> Chroma format wasn't correct if we use below code:
>
> avformat_find_stream_info(fmtc, NULL); iVideoStream =
> av_find_best_stream(fmtc, AVMEDIA_TYPE_VIDEO, -1, -1, NULL, 0);
> eChromaFormat = (AVPixelFormat)fmtc->streams[iVideoStream]->codecpar->
> format;
> ---
> libavformat/mov.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/libavformat/mov.c b/libavformat/mov.c
> index 1532e74d67..4d4b5c0f48 100644
> --- a/libavformat/mov.c
> +++ b/libavformat/mov.c
> @@ -7615,6 +7615,8 @@ static int mov_read_header(AVFormatContext *s)
> av_log(s, AV_LOG_VERBOSE, "Forcing full parsing for mp3
> stream\n");
> st->need_parsing = AVSTREAM_PARSE_FULL;
> }
> +if (st->codecpar->codec_id == AV_CODEC_ID_AV1)
> +st->need_parsing = AVSTREAM_PARSE_HEADERS;
Could you add this at the end of mov_finalize_stsd_codec() instead?
> }
>
> if (mov->trex_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 1/7] avfilter/formats: Make check for buffer overflow redundant
Andreas Rheinhardt (12020-08-15): > and remove the redundant check. > > This check for whether the allocated buffer is sufficient has been added > in commit 1cbf7fb4345a3e5b7791d483241bf4759bde4ece (merging commit > 5775a1832c4165e6acc1d307004b38701bb463f4). It is not sufficient to > detect invalid input lists (namely lists with duplicates); its only use > is to avoid buffer overflows. And this can be achieved by simpler means: > Make sure that one allocates space for so many elements as the outer loop > ranges over and break out of the inner loop if a match has been found. > For valid input without duplicates, no further match will be found anyway. > > This change will temporarily make the allocated formats array larger > than before and larger than necessary; this will be fixed in a later > commit that avoids the allocation altogether. > > If a check for duplicates in the lists is deemed necessary, it should be > done properly somewhere else. > > Finally, the error message that is removed in this commit used > __FUNCTION__, which is a GCC extension (C99 added __func__ for this). > So this commit removes a warning when compiling in -pedantic mode. > > Signed-off-by: Andreas Rheinhardt > --- > libavfilter/formats.c | 9 ++--- > 1 file changed, 2 insertions(+), 7 deletions(-) LGTM. Regards, -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 2/7] avfilter/formats: Avoid allocations when merging formats and samplerates
Andreas Rheinhardt (12020-08-15): > This is the analogue of cfc65520324ae640299bd321ef88ae76dcee6f78 for > formats and samplerates; in contrast to said commit, one can avoid > allocating a new array for formats as well (the complications of the > generic channel layouts made this impossible for channel layouts). > > This commit also starts to move the line continuation '\' chars to the > left to keep them in line with MERGE_REF() as well as with the 80 lines > limit. > > Signed-off-by: Andreas Rheinhardt > --- > libavfilter/formats.c | 85 --- > 1 file changed, 24 insertions(+), 61 deletions(-) LGTM, I think. Regards, -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 3/7] avfilter/formats: Resize potentially oversized arrays
Andreas Rheinhardt (12020-08-15): > Signed-off-by: Andreas Rheinhardt > --- > libavfilter/formats.c | 4 > 1 file changed, 4 insertions(+) The patch works, but I do not think it is necessary or even useful: these arrays are short-lived anyway, they will be freed very soon anyway. (Also, we may want to make them power-of-two dynarrays at some places, to avoid quadratic adds of formats.) Regards, -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 4/7] avfilter/formats: Avoid code duplication when merging samplerates
Andreas Rheinhardt (12020-08-15):
> by adapting the MERGE_FORMATS() so that only one instance of the
> MERGE_REF() macro needs to exist in ff_merge_samplerates().
Nit: the first line of the commit message should be a short summary.
>
> Signed-off-by: Andreas Rheinhardt
> ---
> libavfilter/formats.c | 26 ++
> 1 file changed, 14 insertions(+), 12 deletions(-)
>
> diff --git a/libavfilter/formats.c b/libavfilter/formats.c
> index 4efbcbebfe..e8a43a434d 100644
> --- a/libavfilter/formats.c
> +++ b/libavfilter/formats.c
> @@ -56,12 +56,21 @@ do {
> \
>
> /**
> * Add all formats common to a and b to a, add b's refs to a and destroy b.
> + * If empty_allowed is set and one of a,b->nb is zero, the lists are
> + * merged; otherwise, it is treated as error.
> */
> -#define MERGE_FORMATS(a, b, fmts, nb, type, fail_statement)\
> +#define MERGE_FORMATS(a, b, fmts, nb, type, fail_statement, empty_allowed) \
> do {
>\
> int i, j, k = 0; \
> void *tmp; \
>
>\
> +if (empty_allowed) { \
> +if (!a->nb || !b->nb) {\
> +if (!a->nb)\
> +FFSWAP(type *, a, b); \
> +goto merge_ref;\
> +} \
> +} \
I think a big if () / else would be better than a goto.
> for (i = 0; i < a->nb; i++)
>\
> for (j = 0; j < b->nb; j++)
>\
> if (a->fmts[i] == b->fmts[j]) {
>\
> @@ -77,6 +86,7 @@ do {
> if (tmp) \
> a->fmts = tmp; \
>
>\
> +merge_ref: \
> MERGE_REF(a, b, fmts, type, fail_statement); \
> } while (0)
>
> @@ -114,7 +124,7 @@ AVFilterFormats *ff_merge_formats(AVFilterFormats *a,
> AVFilterFormats *b,
> if (alpha2 > alpha1 || chroma2 > chroma1)
> return NULL;
>
> -MERGE_FORMATS(a, b, formats, nb_formats, AVFilterFormats, return NULL;);
> +MERGE_FORMATS(a, b, formats, nb_formats, AVFilterFormats, return NULL;,
> 0);
>
> return a;
> }
> @@ -124,16 +134,8 @@ AVFilterFormats *ff_merge_samplerates(AVFilterFormats *a,
> {
> if (a == b) return a;
>
> -if (a->nb_formats && b->nb_formats) {
> -MERGE_FORMATS(a, b, formats, nb_formats, AVFilterFormats, return
> NULL;);
> -return a;
> -} else if (a->nb_formats) {
> -MERGE_REF(a, b, formats, AVFilterFormats, return NULL;);
> -return a;
> -} else {
> -MERGE_REF(b, a, formats, AVFilterFormats, return NULL;);
> -return b;
> -}
> +MERGE_FORMATS(a, b, formats, nb_formats, AVFilterFormats, return NULL;,
> 1);
> +return a;
> }
>
> AVFilterChannelLayouts *ff_merge_channel_layouts(AVFilterChannelLayouts *a,
Overall, it does not look very beneficial, but I suppose it is ok.
Regards,
--
Nicolas George
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 5/7] avfilter/formats: Factor checking for mergeability out of ff_merge_*
Andreas Rheinhardt (12020-08-15): > The callers of the ff_merge_*() functions fall into two categories with > quite different needs: > > One caller is can_merge_formats() which only wants to test for mergeability > without it merging anything. In order to do so, it duplicates the lists > it intends to test and resets their owners so that they are not modified > by ff_merge_*(). It also means that it needs to receive the merged list > (and not only an int containing whether the lists are mergeable) to > properly free it. > > The other callers want the lists to be actually merged. But given the > fact that ff_merge_*() automatically updates the owners of the lists, > they only want the information whether the merge succeeded or not; they > don't want a link to the new list. > > Therefore this commit splits these functions in two: ff_merge_*() for > the latter callers and ff_can_merge_*() for the former. > ff_merge_*() doesn't need to return a pointer to the combined list at all > and hence these functions have been modified to return an int, which > allows to distinguish between incompability and memory allocation failures. > > ff_can_merge_*() meanwhile doesn't modify its arguments at all obviating > the need for copies. This in turn implies that there is no reason to > return a pointer to the new list, as nothing needs to be freed. These > functions therefore return an int as well. This allowed to completely > remove can_merge_formats() in avfiltergraph.c. > > Notice that no ff_can_merge_channel_layouts() has been created, because > there is currently no caller for this. It could be added if needed. > > Signed-off-by: Andreas Rheinhardt LGTM, well done. Regards, -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 6/7] avfilter/formats: Always keep longer references list when merging lists
Andreas Rheinhardt (12020-08-15): > This means that one only needs to update the shorter list of references. > > Signed-off-by: Andreas Rheinhardt > --- > I doubt that this optimizations is worth the additional complexity. I > have just added it for you to decide. I must say, I do not understand the logic, especially the preserve_fmts bit. I think we can leave it for later. Have you given thought to the linked list option I suggested? Regards, -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v4]libavfilter/asrc_atone.c : generate algorithmic music
Paul B Mahol (12020-08-19): > Hmm, something about fluidsynthsounds? That would be ok by me. Other suggestions: fluidsynthmusic, fluidmusic. > Writing excellent synthesizer is not trivial task. Indeed. But it is also of little use for this project. On the other hand, writing a correct synthesizer that is also trustworthy and bit-exact is achievable, and it would be very useful for testing. Therefore, I would really appreciate that Ashutosh Pradhan takes a few instants to answer the question: how hard would it be to plug another synthesizer? I do not know what use you had in mind when proposing this project, but the original proposal was never intended for listening, it was always for testing, the audio equivalent of testsrc2. Regards, -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v4]libavfilter/asrc_atone.c : generate algorithmic music
On 8/19/20, Nicolas George wrote: > Paul B Mahol (12020-08-19): >> Hmm, something about fluidsynthsounds? > > That would be ok by me. Other suggestions: fluidsynthmusic, fluidmusic. > >> Writing excellent synthesizer is not trivial task. > > Indeed. But it is also of little use for this project. > > On the other hand, writing a correct synthesizer that is also > trustworthy and bit-exact is achievable, and it would be very useful for > testing. > > Therefore, I would really appreciate that Ashutosh Pradhan takes a few > instants to answer the question: how hard would it be to plug another > synthesizer? > > I do not know what use you had in mind when proposing this project, but > the original proposal was never intended for listening, it was always > for testing, the audio equivalent of testsrc2. Disagree, beside, you have already written correct, always bitexact synthesizer that does not depend on external tools. So use that for testing? > > Regards, > > -- > Nicolas George > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 1/6] avfilter/formats: Remove ff_make_formatu64_list()
On 8/8/20, Andreas Rheinhardt wrote: > It is unused since 8cbb055760c725d0fb99fb759caabb5f4e37e340 and it > actually coincides with avfilter_make_format64_list(). LGTM. ___ 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 7/7] avfilter/formats: Cosmetics
On 8/15/20, Andreas Rheinhardt wrote: > Signed-off-by: Andreas Rheinhardt > --- > libavfilter/formats.c | 18 +- > 1 file changed, 9 insertions(+), 9 deletions(-) > LGTM ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 3/3] avformat/mlvdec: Only store dimensions after having validated them
On 8/10/20, Andreas Rheinhardt wrote: > Otherwise it might happen that invalid dimensions are used when reading > a video packet; this might lead to undefined overflow. > > Signed-off-by: Andreas Rheinhardt > --- > libavformat/mlvdec.c | 20 +++- > 1 file changed, 11 insertions(+), 9 deletions(-) > LGTM ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 1/3] avformat/vividas: Check return value before storing it in smaller type
On 8/6/20, Andreas Rheinhardt wrote: > Signed-off-by: Andreas Rheinhardt > --- > libavformat/vividas.c | 9 + > 1 file changed, 5 insertions(+), 4 deletions(-) > Probably OK ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 1/2] ffmpeg: add disable_all_auto_conversion_filters option.
On 8/17/20, Alexander Strasser wrote:
> On 2020-08-16 23:12 +0200, Nicolas George wrote:
>> Alexander Strasser (12020-08-16):
>> > I dislike the negative name too, because like mentioned by Marton it
>> > doesn't work well with overriding the option to turn it off.
>> >
>> > On one hand for this option in particular it wouldn't be that important,
>> > on the other hand it will be something (new) developers will see when
>> > writing tests and scratch their heads about it.
>>
>> But I want new developers writing tests to see it and scratch their
>> head! I want to scratch their heads and find a better way if
>> implementing their test. It is one of the points of the patch: find where
>> tests are inefficients and give an incentive to make them more
>> efficient.
>>
>> And I want reviewers to see the option, and make a comment about it;
>> tests lines are frequently long, a short option is easy to overlook.
>
> I need to differentiate here. I agree on adding an option to the tests
> where there are still autoconversions happening.
>
> I'm not in favor of adding an option with an unwieldy name and double
> negation (nodisable).
>
> I think the pendulum can swing in both direction here. So the overall
> effect is not clear to me. E.g. one developer may think
>
> "hey what's this -> i need to fix it"
>
> another might think
>
> "hey what's this -> better just copy and not look into it"
>
> and a third might think
>
> "hey what's this -> just another idiosyncrasy :("
>
>
>> > I'm not convinced that using the long name on purpose is good here
>> > or in general.
>> >
>> > 1. It would not be so great to have to invent convenient names for
>> >every option that shouldn't be used "normally"
>> > 2. If users want to use an option they will use it no matter how
>> >long the name. (This is from experience, we had a very longish
>> >and worse named option in MPlayer for a similar reason.)
>>
>> At least, it will make Carl Eugen's work easier, or whoever deals with
>> user questions on the mailing list somewhat easier: if somebody uses the
>> option and break their command line cluelessly, it will be easy to spot,
>> even in the middle of half a page of scale= arithmetic formulas and
>> unrelated encoding options.
>
> Might be. I suspect it will not help much, but sure I might be wrong.
> I didn't do lots of bug wrangling in the last years.
>
>
>> I am not adamant on the name. If somebody suggests something better and
>> there is a consensus, I will change it, of course. But I think these are
>> good points for a very visible name.
>
> I'm neither insisting on anything. I like this patch set.
>
> Here are some suggestions in no particular order:
>
> * auto_conversion_filters (from Marton)
This is very good one.
The double negation is making user and developers think about it
several times upon reading.
> * lavfi_auto_conversion
> * lavfi_autoconv
> * lavfi_sample_format_conversion
> * lavfi_fmt_conversion (in reference to pix_fmt and sample_fmt)
> * lavfi_fmt_conv
>
>
> 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".
___
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/4] lavfi/vaf_spectrumsynth: switch to activate.
On 8/12/20, Nicolas George wrote:
> Preserve the original workings, that does not use frames timestamps
> and therefore is very fragile.
That could be added later.
>
> Allow to remove needs_fifo.
>
Patch OK.
> Signed-off-by: Nicolas George
> ---
> libavfilter/vaf_spectrumsynth.c | 69 -
> 1 file changed, 34 insertions(+), 35 deletions(-)
>
>
> Tested with the example in the doc.
>
>
> diff --git a/libavfilter/vaf_spectrumsynth.c
> b/libavfilter/vaf_spectrumsynth.c
> index fed2cbba03..6a0c45450d 100644
> --- a/libavfilter/vaf_spectrumsynth.c
> +++ b/libavfilter/vaf_spectrumsynth.c
> @@ -34,6 +34,7 @@
> #include "formats.h"
> #include "audio.h"
> #include "video.h"
> +#include "filters.h"
> #include "internal.h"
> #include "window_func.h"
>
> @@ -222,25 +223,6 @@ static int config_output(AVFilterLink *outlink)
> return 0;
> }
>
> -static int request_frame(AVFilterLink *outlink)
> -{
> -AVFilterContext *ctx = outlink->src;
> -SpectrumSynthContext *s = ctx->priv;
> -int ret;
> -
> -if (!s->magnitude) {
> -ret = ff_request_frame(ctx->inputs[0]);
> -if (ret < 0)
> -return ret;
> -}
> -if (!s->phase) {
> -ret = ff_request_frame(ctx->inputs[1]);
> -if (ret < 0)
> -return ret;
> -}
> -return 0;
> -}
> -
> static void read16_fft_bin(SpectrumSynthContext *s,
> int x, int y, int f, int ch)
> {
> @@ -470,22 +452,43 @@ static int try_push_frames(AVFilterContext *ctx)
> return ret;
> }
>
> -static int filter_frame_magnitude(AVFilterLink *inlink, AVFrame *magnitude)
> +static int activate(AVFilterContext *ctx)
> {
> -AVFilterContext *ctx = inlink->dst;
> SpectrumSynthContext *s = ctx->priv;
> +AVFrame **staging[2] = { &s->magnitude, &s->phase };
> +int64_t pts;
> +int i, ret;
>
> -s->magnitude = magnitude;
> -return try_push_frames(ctx);
> -}
> +FF_FILTER_FORWARD_STATUS_BACK_ALL(ctx->outputs[0], ctx);
>
> -static int filter_frame_phase(AVFilterLink *inlink, AVFrame *phase)
> -{
> -AVFilterContext *ctx = inlink->dst;
> -SpectrumSynthContext *s = ctx->priv;
> +for (i = 0; i < 2; i++) {
> +if (*staging[i])
> +continue;
> +ret = ff_inlink_consume_frame(ctx->inputs[i], staging[i]);
> +if (ret < 0)
> +return ret;
> +if (ret) {
> +ff_filter_set_ready(ctx, 10);
> +return try_push_frames(ctx);
> +}
> +}
> +
> +for (i = 0; i < 2; i++) {
> +if (ff_inlink_acknowledge_status(ctx->inputs[i], &ret, &pts)) {
> +ff_outlink_set_status(ctx->outputs[0], ret, pts);
> +ff_inlink_set_status(ctx->inputs[1 - i], ret);
> +return 0;
> +}
> +}
> +
> +if (ff_outlink_frame_wanted(ctx->outputs[0])) {
> +for (i = 0; i < 2; i++) {
> +if (!*staging[i])
> +ff_inlink_request_frame(ctx->inputs[i]);
> +}
> +}
>
> -s->phase = phase;
> -return try_push_frames(ctx);
> +return FFERROR_NOT_READY;
> }
>
> static av_cold void uninit(AVFilterContext *ctx)
> @@ -509,14 +512,10 @@ static const AVFilterPad spectrumsynth_inputs[] = {
> {
> .name = "magnitude",
> .type = AVMEDIA_TYPE_VIDEO,
> -.filter_frame = filter_frame_magnitude,
> -.needs_fifo = 1,
> },
> {
> .name = "phase",
> .type = AVMEDIA_TYPE_VIDEO,
> -.filter_frame = filter_frame_phase,
> -.needs_fifo = 1,
> },
> { NULL }
> };
> @@ -526,7 +525,6 @@ static const AVFilterPad spectrumsynth_outputs[] = {
> .name = "default",
> .type = AVMEDIA_TYPE_AUDIO,
> .config_props = config_output,
> -.request_frame = request_frame,
> },
> { NULL }
> };
> @@ -536,6 +534,7 @@ AVFilter ff_vaf_spectrumsynth = {
> .description = NULL_IF_CONFIG_SMALL("Convert input spectrum videos to
> audio output."),
> .uninit= uninit,
> .query_formats = query_formats,
> +.activate = activate,
> .priv_size = sizeof(SpectrumSynthContext),
> .inputs= spectrumsynth_inputs,
> .outputs = spectrumsynth_outputs,
> --
> 2.28.0
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 1/4] lavfi/vf_overlay_qsv: remove needs_fifo.
On 8/12/20, Nicolas George wrote:
> It is not relevant when using activate and framesync.
>
Nice catch, patch OK.
> Signed-off-by: Nicolas George
> ---
> libavfilter/vf_overlay_qsv.c | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/libavfilter/vf_overlay_qsv.c b/libavfilter/vf_overlay_qsv.c
> index 2a4dc5cb58..11f5fc2242 100644
> --- a/libavfilter/vf_overlay_qsv.c
> +++ b/libavfilter/vf_overlay_qsv.c
> @@ -398,13 +398,11 @@ static const AVFilterPad overlay_qsv_inputs[] = {
> .name = "main",
> .type = AVMEDIA_TYPE_VIDEO,
> .config_props = config_main_input,
> -.needs_fifo= 1,
> },
> {
> .name = "overlay",
> .type = AVMEDIA_TYPE_VIDEO,
> .config_props = config_overlay_input,
> -.needs_fifo= 1,
> },
> { NULL }
> };
> --
> 2.28.0
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 3/4] lavfi: remove needs_fifo.
On 8/12/20, Nicolas George wrote: > Signed-off-by: Nicolas George > --- > libavfilter/avfilter.h | 3 +-- > libavfilter/avfiltergraph.c | 40 - > libavfilter/internal.h | 8 > 3 files changed, 1 insertion(+), 50 deletions(-) > LGTM ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 1/4] lavfi/buffersink: remove redundant channel layouts.
On 8/14/20, Nicolas George wrote:
> Signed-off-by: Nicolas George
> ---
> libavfilter/buffersink.c | 23 +++
> 1 file changed, 23 insertions(+)
>
How they are currently redundant?
Sorry, its not obvious to me from code.
> diff --git a/libavfilter/buffersink.c b/libavfilter/buffersink.c
> index 76a46f6678..c58daf6124 100644
> --- a/libavfilter/buffersink.c
> +++ b/libavfilter/buffersink.c
> @@ -62,6 +62,28 @@ typedef struct BufferSinkContext {
>
> #define NB_ITEMS(list) (list ## _size / sizeof(*list))
>
> +static void cleanup_redundant_layouts(AVFilterContext *ctx)
> +{
> +BufferSinkContext *buf = ctx->priv;
> +int nb_layouts = NB_ITEMS(buf->channel_layouts);
> +int nb_counts = NB_ITEMS(buf->channel_counts);
> +int l, lc, c, n;
> +
> +for (l = lc = 0; l < nb_layouts; l++) {
> +n = av_get_channel_layout_nb_channels(buf->channel_layouts[l]);
> +for (c = 0; c < nb_counts; c++)
> +if (n == buf->channel_counts[c])
> +break;
> +if (c < nb_counts)
> +av_log(ctx, AV_LOG_WARNING,
> + "Removing channel layout 0x%"PRIx64", redundant with %d
> channels\n",
> + buf->channel_layouts[l], buf->channel_counts[c]);
> +else
> +buf->channel_layouts[lc++] = buf->channel_layouts[l];
> +}
> +buf->channel_layouts_size = lc * sizeof(*buf->channel_layouts);
> +}
> +
> int attribute_align_arg av_buffersink_get_frame(AVFilterContext *ctx,
> AVFrame *frame)
> {
> return av_buffersink_get_frame_flags(ctx, frame, 0);
> @@ -253,6 +275,7 @@ static int asink_query_formats(AVFilterContext *ctx)
>
> if (buf->channel_layouts_size || buf->channel_counts_size ||
> buf->all_channel_counts) {
> +cleanup_redundant_layouts(ctx);
> for (i = 0; i < NB_ITEMS(buf->channel_layouts); i++)
> if ((ret = ff_add_channel_layout(&layouts,
> buf->channel_layouts[i])) < 0)
> return ret;
> --
> 2.28.0
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
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/4] lavfi/buffersink: clearly document that the Params struct are unused.
On 8/14/20, Nicolas George wrote: > Signed-off-by: Nicolas George > --- > libavfilter/buffersink.h | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) LGTM ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC PATCH 4/4] libavcodec/j2kenc: Support for multiple layers
On Wed, Aug 19, 2020 at 5:51 PM wrote:
>
> From: Gautam Ramakrishnan
>
> This patch allows setting a compression ratio and to
> set multiple layers. The user has to input a compression
> ratio for each layer.
> The per layer compression ration can be set as follows:
> -layer_rates "r1,r2,...rn"
> for to create 'n' layers.
> ---
> libavcodec/j2kenc.c | 443 ++
> libavcodec/jpeg2000.c | 13 +-
> libavcodec/jpeg2000.h | 10 +
> 3 files changed, 384 insertions(+), 82 deletions(-)
>
> diff --git a/libavcodec/j2kenc.c b/libavcodec/j2kenc.c
> index 8699296434..b09db36c14 100644
> --- a/libavcodec/j2kenc.c
> +++ b/libavcodec/j2kenc.c
> @@ -32,6 +32,7 @@
> * Copyright (c) 2003-2007, Francois-Olivier Devaux and Antonin Descampe
> * Copyright (c) 2005, Herve Drolon, FreeImage Team
> * Copyright (c) 2007, Callum Lerwick
> + * Copyright (c) 2020, Gautam Ramakrishnan
> * All rights reserved.
> *
> * Redistribution and use in source and binary forms, with or without
> @@ -100,6 +101,7 @@ static const int dwt_norms[2][4][10] = { //
> [dwt_type][band][rlevel] (multiplied
>
> typedef struct {
> Jpeg2000Component *comp;
> + double *layer_rates;
> } Jpeg2000Tile;
>
> typedef struct {
> @@ -126,12 +128,15 @@ typedef struct {
> Jpeg2000QuantStyle qntsty;
>
> Jpeg2000Tile *tile;
> +int layer_rates[100];
>
> int format;
> int pred;
> int sop;
> int eph;
> int prog;
> +int nlayers;
> +char *lr_str;
> } Jpeg2000EncoderContext;
>
>
> @@ -332,7 +337,7 @@ static int put_cod(Jpeg2000EncoderContext *s)
> bytestream_put_byte(&s->buf, scod); // Scod
> // SGcod
> bytestream_put_byte(&s->buf, s->prog); // progression level
> -bytestream_put_be16(&s->buf, 1); // num of layers
> +bytestream_put_be16(&s->buf, s->nlayers); // num of layers
> if(s->avctx->pix_fmt == AV_PIX_FMT_YUV444P){
> bytestream_put_byte(&s->buf, 0); // unspecified
> }else{
> @@ -411,6 +416,31 @@ static uint8_t *put_sot(Jpeg2000EncoderContext *s, int
> tileno)
> return psotptr;
> }
>
> +static void compute_rates(Jpeg2000EncoderContext* s)
> +{
> +int i, j;
> +int layno, compno;
> +for (i = 0; i < s->numYtiles; i++) {
> +for (j = 0; j < s->numXtiles; j++) {
> +Jpeg2000Tile *tile = &s->tile[s->numXtiles * i + j];
> +for (compno = 0; compno < s->ncomponents; compno++) {
> +int tilew = tile->comp[compno].coord[0][1] -
> tile->comp[compno].coord[0][0];
> +int tileh = tile->comp[compno].coord[1][1] -
> tile->comp[compno].coord[1][0];
> +int scale = (compno?1 << s->chroma_shift[0]:1) * (compno?1
> << s->chroma_shift[1]:1);
> +for (layno = 0; layno < s->nlayers; layno++) {
> +if (s->layer_rates[layno] > 0.0f) {
> +tile->layer_rates[layno] += (double)(tilew * tileh)
> * s->ncomponents * s->cbps[compno] /
> +
> (double)(s->layer_rates[layno] * 8 * scale);
> +} else {
> +tile->layer_rates[layno] = 0.0f;
> +}
> +}
> +}
> +}
> +}
> +
> +}
> +
> /**
> * compute the sizes of tiles, resolution levels, bands, etc.
> * allocate memory for them
> @@ -448,6 +478,10 @@ static int init_tiles(Jpeg2000EncoderContext *s)
> for (j = 0; j < 2; j++)
> comp->coord[i][j] = comp->coord_o[i][j] =
> ff_jpeg2000_ceildivpow2(comp->coord[i][j], s->chroma_shift[i]);
>
> +tile->layer_rates = av_mallocz_array(s->ncomponents,
> sizeof(*tile->layer_rates));
> +if (!tile->layer_rates)
> +return AVERROR(ENOMEM);
> +
> if ((ret = ff_jpeg2000_init_component(comp,
> codsty,
> qntsty,
> @@ -459,6 +493,7 @@ static int init_tiles(Jpeg2000EncoderContext *s)
> return ret;
> }
> }
> +compute_rates(s);
> return 0;
> }
>
> @@ -701,6 +736,8 @@ static void encode_cblk(Jpeg2000EncoderContext *s,
> Jpeg2000T1Context *t1, Jpeg20
> }
>
> cblk->passes[passno].rate = ff_mqc_flush_to(&t1->mqc,
> cblk->passes[passno].flushed, &cblk->passes[passno].flushed_len);
> +cblk->passes[passno].rate -= cblk->passes[passno].flushed_len;
> +
> wmsedec += (int64_t)nmsedec << (2*bpno);
> cblk->passes[passno].disto = wmsedec;
>
> @@ -733,10 +770,12 @@ static void putnumpasses(Jpeg2000EncoderContext *s, int
> n)
> }
>
>
> -static int encode_packet(Jpeg2000EncoderContext *s, Jpeg2000ResLevel
> *rlevel, int precno,
> - uint8_t *expn, int numgbits, int packetno)
> +static int encode_packet(Jpeg2000EncoderContext *s, Jpeg2000ResLevel
>
Re: [FFmpeg-devel] [PATCH 3/4] lavfi/buffersink: add a summary documentation of the API.
On 8/14/20, Nicolas George wrote: > Signed-off-by: Nicolas George > --- > libavfilter/buffersink.h | 36 > 1 file changed, 36 insertions(+) > LGTM ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 4/4] ffplay: do not set redundant channel count on abuffersink.
On 8/14/20, Nicolas George wrote: > Signed-off-by: Nicolas George > --- > fftools/ffplay.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > Looks OK, but I'm not maintainer of this code. ___ 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 software and patch management
On 19.08.2020 20:25, Carter, Tenisha [USA] wrote: Hello, Ffmpeg is currently being used on a system that I support and I need clarification that version 3.4 is still being maintained and patched on a daily basis. Can you please provide me a statement indicating that this software is still supported and a date of how long it will be supported? Occasionally applicable and security-relevant patches are still backported, but overall 3.4 is pretty dead and does not receive any active maintenance anymore since quite a while. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [aarch64] yuv2planeX - unroll outer loop by 4 to increase performance by 6.3%
Thanks Michael for your feedback. On Wed, Aug 19, 2020 at 6:55 AM Michael Niedermayer wrote: > faster is better obviously, so if its tested with odd sizes and arm > developers had a chance to comment. it should be ok > > The current patch was tested with `make check` on Arm64 Graviton2. I also have tested randomly selected rescale factors, for example: ./ffmpeg -nostats -f lavfi -i testsrc2=4k:d=2 -vf bench=start,scale=1023x42,bench=stop -f null - > one potential improvment is to use the unrolled code for odd width > too and use the non unrolled for the end > Done. Please see the amended patch. Thanks, Sebastian 0001-aarch64-yuv2planeX-unroll-outer-loop-by-4-increases-.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] ffmpeg software and patch management
Am Mi., 19. Aug. 2020 um 20:25 Uhr schrieb Carter, Tenisha [USA] : > Ffmpeg is currently being used on a system that I support and I need > clarification that version 3.4 is still being maintained and patched on a > daily basis. Can you please provide me a statement indicating that this > software is still supported and a date of how long it will be supported? While I am not a native speaker, I believe the most important clarification is that you should absolutely read again the no-warranty clause of the (L)GPL, if you don't agree with it, you cannot (legally) use FFmpeg. That being said, I believe I can clarify that 3.4 is not patched on a "daily basis". Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 4/4] lavfi: remove request_samples.
On 8/12/20, Nicolas George wrote: > Filters can use min_samples/max_samples if the number is constant > or activate and ff_inlink_consume_samples(). > LGTM ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 5/5] avcodec/dvbsubdec: error out on unsupported coding methods
On 8/18/20, Clément Bœsch wrote: > --- > libavcodec/dvbsubdec.c | 3 +++ > 1 file changed, 3 insertions(+) > LGTM ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 2/5] avcodec/dvbsubenc: reindent after previous commit
On 8/18/20, Clément Bœsch wrote: > --- > libavcodec/dvbsubenc.c | 78 +- > 1 file changed, 39 insertions(+), 39 deletions(-) > LGTM ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 3/5] avcodec/dvbsubenc: fix onject/object typo
On 8/18/20, Clément Bœsch wrote: > --- > libavcodec/dvbsubenc.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > OK ___ 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/3] [RFC] lavc: add FLIF decoding support
On 8/17/20, Anamitra Ghorui wrote: > On Sat, 15 Aug 2020 00:29:10 +0530 > Anamitra Ghorui wrote: > >> This patch fixes a few cosmetic errors mentioned in v3, an error in the >> ColorBuckets reading function and removes a few redundancies in the >> rangecoder initialisation. >> >> Co-authored-by: Anamitra Ghorui >> Co-authored-by: Kartik K Khullar >> >> Signed-off-by: Anamitra Ghorui >> --- >> libavcodec/Makefile|2 + >> libavcodec/allcodecs.c |1 + >> libavcodec/codec_desc.c|7 + >> libavcodec/codec_id.h |1 + >> libavcodec/flif16.c| 191 ++ >> libavcodec/flif16.h| 282 +++ >> libavcodec/flif16_parser.c | 193 ++ >> libavcodec/flif16_rangecoder.c | 804 + >> libavcodec/flif16_rangecoder.h | 397 + >> libavcodec/flif16_transform.c | 3009 >> libavcodec/flif16_transform.h | 124 ++ >> libavcodec/flif16dec.c | 1779 +++ >> libavcodec/parsers.c |1 + >> libavcodec/version.h |2 +- >> 14 files changed, 6792 insertions(+), 1 deletion(-) >> create mode 100644 libavcodec/flif16.c >> create mode 100644 libavcodec/flif16.h >> create mode 100644 libavcodec/flif16_parser.c >> create mode 100644 libavcodec/flif16_rangecoder.c >> create mode 100644 libavcodec/flif16_rangecoder.h >> create mode 100644 libavcodec/flif16_transform.c >> create mode 100644 libavcodec/flif16_transform.h >> create mode 100644 libavcodec/flif16dec.c > > A few more things I have noticed since uploading this patch: > > * In flif16_rangecoder.h, the variable left and the if statement at the > end of the while loop of ff_flif16_rac_renorm is entirely redundant. > > * The reverse transform loop has been written once in the main state > loop of flif16_decode_frame, and once again in flif16_read_ni_image. > This is entirely redundant. > > * There is a case of strange spacing in ff_flif16_rac_init(), in > flif16_rangecoder.h. > > * GetByteContext is useless in FLIF16Context, and should be shifted to > FLIF16DecoderContext instead. > > > All these corrections have been made by me locally, but I would like to > wait for some further review (self and otherwise) before posting again. > Please make use of av_clip and FFMIN/FFMAX macros. > Regards, > Anamitra > > ___ > 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 2/3] avformat/mlvdec: Don't leak open AVIOContexts on error
On 8/10/20, Andreas Rheinhardt wrote: > Signed-off-by: Andreas Rheinhardt > --- > libavformat/mlvdec.c | 3 +++ > 1 file changed, 3 insertions(+) > Probably OK ___ 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/8] avcodec/smacker: Don't warn for Huffmann tables with one element
On 7/31/20, Andreas Rheinhardt wrote: > The Huffmann tables used by Smacker can consist of exactly one leaf only > in which case the length of the corresponding code is zero; there is > then exactly one value encoded. Our VLC can't handle this and therefore > this case needs to be treated separately; it has been implemented in > commit 48cbdaea157671d456750e00fde37c6d7595fad6. Yet said commit also > made the decoder emit an error message (despite not erroring out) in this > case, although it seems that this is rather a limitation of our VLC API. > > Signed-off-by: Andreas Rheinhardt > --- Probably OK ___ 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 20/21] avcodec/smacker: Use unsigned for prediction values
On 8/1/20, Andreas Rheinhardt wrote:
> Up until now, the Smacker decoder has pretended that the prediction
> values are signed in code like 'pred[0] += (unsigned)sign_extend(val, 16)'
> (the cast has been added to this code later to fix undefined behaviour).
> This has been even done in case the PCM format is u8.
>
> Yet in case of 8/16 bit samples, only the lower 8/16 bit of the predicition
> values are ever used, so one can just as well just use unsigned and
> remove the sign extensions. This is what this commit does.
>
> For GCC 9 the time for one call to smka_decode_frame() for the sample from
> ticket #2425 decreased from 1709043 to 1693619 decicycles; for Clang 9
> it went up from 1355273 to 1369089 decicycles.
>
> Signed-off-by: Andreas Rheinhardt
> ---
Should be fine if this code is completely covered by fate and thus
checksum are not changed.
> libavcodec/smacker.c | 13 ++---
> 1 file changed, 6 insertions(+), 7 deletions(-)
>
> diff --git a/libavcodec/smacker.c b/libavcodec/smacker.c
> index e588b03820..d2b1c68162 100644
> --- a/libavcodec/smacker.c
> +++ b/libavcodec/smacker.c
> @@ -595,11 +595,10 @@ static int smka_decode_frame(AVCodecContext *avctx,
> void *data,
> int16_t *samples;
> uint8_t *samples8;
> uint8_t values[4];
> -int val;
> int i, res, ret;
> int unp_size;
> int bits, stereo;
> -int pred[2] = {0, 0};
> +unsigned pred[2], val;
>
> if (buf_size <= 4) {
> av_log(avctx, AV_LOG_ERROR, "packet is too small\n");
> @@ -668,7 +667,7 @@ static int smka_decode_frame(AVCodecContext *avctx, void
> *data,
> /* this codec relies on wraparound instead of clipping audio */
> if(bits) { //decode 16-bit data
> for(i = stereo; i >= 0; i--)
> -pred[i] = sign_extend(av_bswap16(get_bits(&gb, 16)), 16);
> +pred[i] = av_bswap16(get_bits(&gb, 16));
> for(i = 0; i <= stereo; i++)
> *samples++ = pred[i];
> for(; i < unp_size / 2; i++) {
> @@ -687,7 +686,7 @@ static int smka_decode_frame(AVCodecContext *avctx, void
> *data,
> else
> res = values[3];
> val |= res << 8;
> -pred[1] += (unsigned)sign_extend(val, 16);
> +pred[1] += val;
> *samples++ = pred[1];
> } else {
> if(vlc[0].table)
> @@ -700,7 +699,7 @@ static int smka_decode_frame(AVCodecContext *avctx, void
> *data,
> else
> res = values[1];
> val |= res << 8;
> -pred[0] += (unsigned)sign_extend(val, 16);
> +pred[0] += val;
> *samples++ = pred[0];
> }
> }
> @@ -719,14 +718,14 @@ static int smka_decode_frame(AVCodecContext *avctx,
> void *data,
> res = get_vlc2(&gb, vlc[1].table, SMKTREE_BITS, 3);
> else
> res = values[1];
> -pred[1] += sign_extend(res, 8);
> +pred[1] += res;
> *samples8++ = pred[1];
> } else {
> if(vlc[0].table)
> res = get_vlc2(&gb, vlc[0].table, SMKTREE_BITS, 3);
> else
> res = values[0];
> -pred[0] += sign_extend(res, 8);
> +pred[0] += res;
> *samples8++ = pred[0];
> }
> }
> --
> 2.20.1
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel 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 7/8] avcodec/smacker: Use same variable for return values and errors
On 7/31/20, Andreas Rheinhardt wrote:
> smacker_decode_header_tree() uses different variables for return values
> (res) and for errors (err) leading to code like
> res = foo(bar);
> if (res < 0) {
> err = res;
> goto error;
> }
> Given that no positive return value is ever used at all one can simplify
> the above by removing the intermediate res.
>
LGTM
___
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 13/21] avfilter/vf_remap: Fix double-free of AVFilterFormats on error
On 8/9/20, Andreas Rheinhardt wrote: > The query_formats function of the remap filter tries to allocate > two lists of formats which on success are attached to more permanent objects > (AVFilterLinks) for storage afterwards. If attaching a list to an > AVFilterLink succeeds, it is in turn owned by the AVFilterLink (or more > exactly, the AVFilterLink becomes one of the common owners of the list). > Yet if attaching a list to one of its links succeeds and an error happens > lateron, both lists were manually freed, which means that is wrong if the > list is already owned by one or more links; these links' pointers to > their lists will become dangling and there will be a double-free/use-after- > free when these links are cleaned up automatically. > > This commit fixes this by removing the custom free code; this will > temporarily add a leaking codepath (if attaching a list not already > owned by a link to a link fails, the list will leak), but this will > be fixed soon by making sure that an AVFilterFormats without owner will > be automatically freed when attaching it to an AVFilterLink fails. > Notice at most one list leaks because a new list is only allocated > after the old list has been successfully attached to a link. > > Signed-off-by: Andreas Rheinhardt > --- > libavfilter/vf_remap.c | 24 +++- > 1 file changed, 7 insertions(+), 17 deletions(-) > LGTM ___ 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 6/8] avcodec/smacker: Directly goto error in case of error
On 7/31/20, Andreas Rheinhardt wrote:
> Signed-off-by: Andreas Rheinhardt
> ---
> libavcodec/smacker.c | 7 ---
> 1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/libavcodec/smacker.c b/libavcodec/smacker.c
> index 8a4d88cfed..4b1f0f1b7c 100644
> --- a/libavcodec/smacker.c
> +++ b/libavcodec/smacker.c
> @@ -251,17 +251,18 @@ static int smacker_decode_header_tree(SmackVContext
> *smk, GetBitContext *gb, int
> err = AVERROR(ENOMEM);
> goto error;
> }
> +*recodes = huff.values;
>
> res = smacker_decode_bigtree(gb, &huff, &ctx, 0);
> -if (res < 0)
> +if (res < 0) {
> err = res;
> +goto error;
> +}
> skip_bits1(gb);
> if(ctx.last[0] == -1) ctx.last[0] = huff.current++;
> if(ctx.last[1] == -1) ctx.last[1] = huff.current++;
> if(ctx.last[2] == -1) ctx.last[2] = huff.current++;
>
> -*recodes = huff.values;
Commit log does not explain this change at all.
And it looks wrong at first look.
> -
> error:
> for (int i = 0; i < 2; i++) {
> if (vlc[i].table)
> --
> 2.20.1
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC PATCH 4/4] libavcodec/j2kenc: Support for multiple layers
On 8/19/20, Gautam Ramakrishnan wrote:
> On Wed, Aug 19, 2020 at 5:51 PM wrote:
>>
>> From: Gautam Ramakrishnan
>>
>> This patch allows setting a compression ratio and to
>> set multiple layers. The user has to input a compression
>> ratio for each layer.
>> The per layer compression ration can be set as follows:
>> -layer_rates "r1,r2,...rn"
>> for to create 'n' layers.
>> ---
>> libavcodec/j2kenc.c | 443 ++
>> libavcodec/jpeg2000.c | 13 +-
>> libavcodec/jpeg2000.h | 10 +
>> 3 files changed, 384 insertions(+), 82 deletions(-)
>>
>> diff --git a/libavcodec/j2kenc.c b/libavcodec/j2kenc.c
>> index 8699296434..b09db36c14 100644
>> --- a/libavcodec/j2kenc.c
>> +++ b/libavcodec/j2kenc.c
>> @@ -32,6 +32,7 @@
>> * Copyright (c) 2003-2007, Francois-Olivier Devaux and Antonin Descampe
>> * Copyright (c) 2005, Herve Drolon, FreeImage Team
>> * Copyright (c) 2007, Callum Lerwick
>> + * Copyright (c) 2020, Gautam Ramakrishnan
>> * All rights reserved.
>> *
>> * Redistribution and use in source and binary forms, with or without
>> @@ -100,6 +101,7 @@ static const int dwt_norms[2][4][10] = { //
>> [dwt_type][band][rlevel] (multiplied
>>
>> typedef struct {
>> Jpeg2000Component *comp;
>> + double *layer_rates;
>> } Jpeg2000Tile;
>>
>> typedef struct {
>> @@ -126,12 +128,15 @@ typedef struct {
>> Jpeg2000QuantStyle qntsty;
>>
>> Jpeg2000Tile *tile;
>> +int layer_rates[100];
>>
>> int format;
>> int pred;
>> int sop;
>> int eph;
>> int prog;
>> +int nlayers;
>> +char *lr_str;
>> } Jpeg2000EncoderContext;
>>
>>
>> @@ -332,7 +337,7 @@ static int put_cod(Jpeg2000EncoderContext *s)
>> bytestream_put_byte(&s->buf, scod); // Scod
>> // SGcod
>> bytestream_put_byte(&s->buf, s->prog); // progression level
>> -bytestream_put_be16(&s->buf, 1); // num of layers
>> +bytestream_put_be16(&s->buf, s->nlayers); // num of layers
>> if(s->avctx->pix_fmt == AV_PIX_FMT_YUV444P){
>> bytestream_put_byte(&s->buf, 0); // unspecified
>> }else{
>> @@ -411,6 +416,31 @@ static uint8_t *put_sot(Jpeg2000EncoderContext *s,
>> int tileno)
>> return psotptr;
>> }
>>
>> +static void compute_rates(Jpeg2000EncoderContext* s)
>> +{
>> +int i, j;
>> +int layno, compno;
>> +for (i = 0; i < s->numYtiles; i++) {
>> +for (j = 0; j < s->numXtiles; j++) {
>> +Jpeg2000Tile *tile = &s->tile[s->numXtiles * i + j];
>> +for (compno = 0; compno < s->ncomponents; compno++) {
>> +int tilew = tile->comp[compno].coord[0][1] -
>> tile->comp[compno].coord[0][0];
>> +int tileh = tile->comp[compno].coord[1][1] -
>> tile->comp[compno].coord[1][0];
>> +int scale = (compno?1 << s->chroma_shift[0]:1) *
>> (compno?1 << s->chroma_shift[1]:1);
>> +for (layno = 0; layno < s->nlayers; layno++) {
>> +if (s->layer_rates[layno] > 0.0f) {
>> +tile->layer_rates[layno] += (double)(tilew *
>> tileh) * s->ncomponents * s->cbps[compno] /
>> +
>> (double)(s->layer_rates[layno] * 8 * scale);
>> +} else {
>> +tile->layer_rates[layno] = 0.0f;
>> +}
>> +}
>> +}
>> +}
>> +}
>> +
>> +}
>> +
>> /**
>> * compute the sizes of tiles, resolution levels, bands, etc.
>> * allocate memory for them
>> @@ -448,6 +478,10 @@ static int init_tiles(Jpeg2000EncoderContext *s)
>> for (j = 0; j < 2; j++)
>> comp->coord[i][j] = comp->coord_o[i][j] =
>> ff_jpeg2000_ceildivpow2(comp->coord[i][j], s->chroma_shift[i]);
>>
>> +tile->layer_rates = av_mallocz_array(s->ncomponents,
>> sizeof(*tile->layer_rates));
>> +if (!tile->layer_rates)
>> +return AVERROR(ENOMEM);
>> +
>> if ((ret = ff_jpeg2000_init_component(comp,
>> codsty,
>> qntsty,
>> @@ -459,6 +493,7 @@ static int init_tiles(Jpeg2000EncoderContext *s)
>> return ret;
>> }
>> }
>> +compute_rates(s);
>> return 0;
>> }
>>
>> @@ -701,6 +736,8 @@ static void encode_cblk(Jpeg2000EncoderContext *s,
>> Jpeg2000T1Context *t1, Jpeg20
>> }
>>
>> cblk->passes[passno].rate = ff_mqc_flush_to(&t1->mqc,
>> cblk->passes[passno].flushed, &cblk->passes[passno].flushed_len);
>> +cblk->passes[passno].rate -= cblk->passes[passno].flushed_len;
>> +
>> wmsedec += (int64_t)nmsedec << (2*bpno);
>> cblk->passes[passno].disto = wmsedec;
>>
>> @@ -733,10 +770,12 @@ static void putnumpasses(Jpeg2000EncoderContext *s,
>> int n)
>> }
>>
>>
>> -static int encode_packet(Jpeg2000EncoderContext *s, Jpeg2000ResLevel
>> *rlevel, int precno,
>> -
Re: [FFmpeg-devel] [RFC PATCH 4/4] libavcodec/j2kenc: Support for multiple layers
Gautam Ramakrishnan:
> On Wed, Aug 19, 2020 at 5:51 PM wrote:
>>
>> From: Gautam Ramakrishnan
>>
>> This patch allows setting a compression ratio and to
>> set multiple layers. The user has to input a compression
>> ratio for each layer.
>> The per layer compression ration can be set as follows:
>> -layer_rates "r1,r2,...rn"
>> for to create 'n' layers.
>> ---
>> libavcodec/j2kenc.c | 443 ++
>> libavcodec/jpeg2000.c | 13 +-
>> libavcodec/jpeg2000.h | 10 +
>> 3 files changed, 384 insertions(+), 82 deletions(-)
>>
[...]
>> +static int inline check_number(char* st, int* ret) {
>> +int stlen = strlen(st);
>> +int i;
>> +*ret = 0;
>> +if (stlen <= 0) {
>> +return AVERROR_INVALIDDATA;
>> +}
>> +for (i = 0; i < stlen; i++) {
>> +if (st[i] >= '0' && st[i] <= '9') {
>> +*ret = (*ret) * 10 + (st[i] - '0');
>> +} else {
>> +return AVERROR_INVALIDDATA;
>> +}
>> +}
>> +return 0;
>> +}
>> +
>> +static int parse_layer_rates(Jpeg2000EncoderContext *s)
>> +{
>> +int i;
>> +char* token;
>> +int rate;
>> +int nlayers = 0;
>> +if (!s->lr_str) {
>> +s->nlayers = 1;
>> +s->layer_rates[0] = 0;
>> +return 0;
>> +}
>> +
>> +token = strtok(s->lr_str, ",");
>> +if (!check_number(token, &rate)) {
>> +s->layer_rates[0] = rate <= 1 ? 0:rate;
>> +nlayers++;
>> +} else {
>> +return AVERROR_INVALIDDATA;
>> +}
>> +
>> +while (1) {
>> +token = strtok(NULL, ",");
>> +if (!token)
>> +break;
>> +if (!check_number(token, &rate)) {
>> +s->layer_rates[nlayers] = rate <= 1 ? 0:rate;
>> +nlayers++;
>> +} else {
>> +return AVERROR_INVALIDDATA;
>> +}
>> +}
>> +
>> +for (i = 1; i < nlayers; i++) {
>> +if (s->layer_rates[i] >= s->layer_rates[i-1]) {
>> +return AVERROR_INVALIDDATA;
>> +}
>> +}
>> +s->nlayers = nlayers;
>> +return 0;
>> +}
>> +
>> static av_cold int j2kenc_init(AVCodecContext *avctx)
>> {
>> int i, ret;
>> @@ -1388,6 +1664,11 @@ static av_cold int j2kenc_init(AVCodecContext *avctx)
>>
>> s->avctx = avctx;
>> av_log(s->avctx, AV_LOG_DEBUG, "init\n");
>> +if (parse_layer_rates(s)) {
>> +av_log(s, AV_LOG_WARNING, "Layer rates invalid. Shall encode with 1
>> layer.\n");
>> +s->nlayers = 1;
>> +s->layer_rates[0] = 0;
>> +}
>>
>> #if FF_API_PRIVATE_OPT
>> FF_DISABLE_DEPRECATION_WARNINGS
>> @@ -1408,6 +1689,7 @@ FF_ENABLE_DEPRECATION_WARNINGS
>> memset(codsty->log2_prec_heights, 15,
>> sizeof(codsty->log2_prec_heights));
>> codsty->nreslevels2decode=
>> codsty->nreslevels = 7;
>> +codsty->nlayers = s->nlayers;
>> codsty->log2_cblk_width = 4;
>> codsty->log2_cblk_height = 4;
>> codsty->transform= s->pred ? FF_DWT53 : FF_DWT97_INT;
>> @@ -1489,6 +1771,7 @@ static const AVOption options[] = {
>> { "rpcl", NULL,OFFSET(prog),
>> AV_OPT_TYPE_CONST, { .i64 = JPEG2000_PGOD_RPCL}, 0, 0,
>> VE, "prog" },
>> { "pcrl", NULL,OFFSET(prog),
>> AV_OPT_TYPE_CONST, { .i64 = JPEG2000_PGOD_PCRL}, 0, 0,
>> VE, "prog" },
>> { "cprl", NULL,OFFSET(prog),
>> AV_OPT_TYPE_CONST, { .i64 = JPEG2000_PGOD_CPRL}, 0, 0,
>> VE, "prog" },
>> +{ "layer_rates", "Layer Rates", OFFSET(lr_str),
>> AV_OPT_TYPE_STRING, { .str = NULL }, 0, 0, VE },
>> { NULL }
>> };
>>
>>
>> --
>> 2.17.1
>>
>
> This patch seems to be breaking FATE.
> I believe that the error is because the patch modifies the encoder
> such that the encoded files will be slightly different now.
> How can this be handled?
>
Look at the created files and see if they are ok (ideally, they should
show an improvement). If not, modify/drop your patch; otherwise update
the reference files by running make fate GEN=1.
Just by looking at https://patchwork.ffmpeg.org/check/15622/ (i.e.
without taking a look at the actual files and without having run fate
with your patch myself) I can say that your patch is not ok:
-8bb707e596f97451fd325dec2dd610a7 *tests/data/fate/vsynth1-jpeg2000-97.avi
-3654620 tests/data/fate/vsynth1-jpeg2000-97.avi
-5073771a78e1f5366a7eb0df341662fc
*tests/data/fate/vsynth1-jpeg2000-97.out.rawvideo
-stddev:4.23 PSNR: 35.59 MAXDIFF: 53 bytes: 7603200/ 7603200
+5178195043ecfd671d79a194611d3573 *tests/data/fate/vsynth1-jpeg2000-97.avi
+9986568 tests/data/fate/vsynth1-jpeg2000-97.avi
+023623c97973489ba9cf1618b3cd25d3
*tests/data/fate/vsynth1-jpeg2000-97.out.rawvideo
+stddev:3.58 PSNR: 37.04 MAXDIFF: 49 bytes: 7603200/ 7603200
The size of the created files increased from 365
Re: [FFmpeg-devel] [PATCH 5/8] avcodec/smacker: Improve header table error checks
On 7/31/20, Andreas Rheinhardt wrote: > The extradata for Smacker video contains Huffman trees as well as a > field containing the size (in bytes) of said Huffman tree when stored > as a table. Due to three special values the decoder allocates more than > the size field indicates; yet when it parses the table it only errors > out if the number of elements exceeds the number of allocated elements > and not the number of elements as indicated by the size field. As a > consequence, there might be less than three elements available at the > end, so that another check for this is necessary. > > This commit changes this: It is always made sure that the three elements > reserved to (potentially) use them to store the special values are not > used to store ordinary tree entries. This allows to remove the extra > check at the end. > > Signed-off-by: Andreas Rheinhardt > --- > libavcodec/smacker.c | 12 +++- > 1 file changed, 3 insertions(+), 9 deletions(-) > Probably OK ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 4/8] avcodec/smacker: Remove code duplication when decoding header trees
On 7/31/20, Andreas Rheinhardt wrote: > Signed-off-by: Andreas Rheinhardt > --- > libavcodec/smacker.c | 83 +++- > 1 file changed, 28 insertions(+), 55 deletions(-) > Probably OK ___ 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/internal: Remove wrong documentation
On 7/27/20, Andreas Rheinhardt wrote: > Has apparently been copied from ff_choose_timebase() in commit > a45cf639e6fb8c86aff91a00970060cd0be401c9. > > Signed-off-by: Andreas Rheinhardt > --- > Btw: There is exactly one user of this, namely the MXF muxer. > Should this be moved to mxfenc.c? The same issue exists for > ff_choose_timebase(), which is only used by the nut muxer. > > libavformat/internal.h | 3 --- > 1 file changed, 3 deletions(-) > > diff --git a/libavformat/internal.h b/libavformat/internal.h > index 17a6ab07d3..a2eac3250d 100644 > --- a/libavformat/internal.h > +++ b/libavformat/internal.h > @@ -538,9 +538,6 @@ enum AVCodecID ff_get_pcm_codec_id(int bps, int flt, int > be, int sflags); > */ > AVRational ff_choose_timebase(AVFormatContext *s, AVStream *st, int > min_precision); > > -/** > - * Chooses a timebase for muxing the specified stream. > - */ > enum AVChromaLocation ff_choose_chroma_location(AVFormatContext *s, > AVStream *st); > > /** > -- > 2.20.1 > LGTM too > ___ > 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] avformat/siff: Reject audio packets without audio stream
On 8/13/20, Michael Niedermayer wrote: > Fixes: Assertion failure > Fixes: > 24612/clusterfuzz-testcase-minimized-ffmpeg_DEMUXER_fuzzer-6600899842277376.fuzz > > Found-by: continuous fuzzing process > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg > Signed-off-by: Michael Niedermayer > --- > libavformat/siff.c | 2 ++ > 1 file changed, 2 insertions(+) > LGTM ___ 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/options_table: Add missing colorspace options
* chroma-derived-nc / chroma-derived-c and ictcp
Signed-off-by: Harry Mallon
---
doc/codecs.texi| 6 ++
libavcodec/options_table.h | 33 ++---
2 files changed, 24 insertions(+), 15 deletions(-)
diff --git a/doc/codecs.texi b/doc/codecs.texi
index c092aadc0e..1da2590795 100644
--- a/doc/codecs.texi
+++ b/doc/codecs.texi
@@ -1110,6 +1110,12 @@ BT.2020 NCL
BT.2020 CL
@item smpte2085
SMPTE 2085
+@item chroma-derived-nc
+Chroma-derived NCL
+@item chroma-derived-c
+Chroma-derived CL
+@item ictcp
+ICtCp
@end table
@item color_range @var{integer} (@emph{decoding/encoding,video})
diff --git a/libavcodec/options_table.h b/libavcodec/options_table.h
index 1d0db1b5a4..66bda42663 100644
--- a/libavcodec/options_table.h
+++ b/libavcodec/options_table.h
@@ -381,21 +381,24 @@ static const AVOption avcodec_options[] = {
{"bt2020_12bit", "BT.2020 - 12 bit", 0, AV_OPT_TYPE_CONST, {.i64 =
AVCOL_TRC_BT2020_12 },INT_MIN, INT_MAX, V|E|D, "color_trc_type"},
{"smpte428_1", "SMPTE 428-1", 0, AV_OPT_TYPE_CONST, {.i64 =
AVCOL_TRC_SMPTE428 }, INT_MIN, INT_MAX, V|E|D, "color_trc_type"},
{"colorspace", "color space", OFFSET(colorspace), AV_OPT_TYPE_INT,
{.i64 = AVCOL_SPC_UNSPECIFIED }, 0, INT_MAX, V|E|D,
"colorspace_type"},
-{"rgb", "RGB", 0, AV_OPT_TYPE_CONST, {.i64 =
AVCOL_SPC_RGB }, INT_MIN, INT_MAX, V|E|D, "colorspace_type"},
-{"bt709", "BT.709", 0, AV_OPT_TYPE_CONST, {.i64 =
AVCOL_SPC_BT709 }, INT_MIN, INT_MAX, V|E|D, "colorspace_type"},
-{"unknown", "Unspecified", 0, AV_OPT_TYPE_CONST, {.i64 =
AVCOL_SPC_UNSPECIFIED }, INT_MIN, INT_MAX, V|E|D, "colorspace_type"},
-{"fcc", "FCC", 0, AV_OPT_TYPE_CONST, {.i64 =
AVCOL_SPC_FCC }, INT_MIN, INT_MAX, V|E|D, "colorspace_type"},
-{"bt470bg", "BT.470 BG", 0, AV_OPT_TYPE_CONST, {.i64 =
AVCOL_SPC_BT470BG }, INT_MIN, INT_MAX, V|E|D, "colorspace_type"},
-{"smpte170m", "SMPTE 170 M", 0, AV_OPT_TYPE_CONST, {.i64 =
AVCOL_SPC_SMPTE170M }, INT_MIN, INT_MAX, V|E|D, "colorspace_type"},
-{"smpte240m", "SMPTE 240 M", 0, AV_OPT_TYPE_CONST, {.i64 =
AVCOL_SPC_SMPTE240M }, INT_MIN, INT_MAX, V|E|D, "colorspace_type"},
-{"ycgco", "YCGCO", 0, AV_OPT_TYPE_CONST, {.i64 =
AVCOL_SPC_YCGCO }, INT_MIN, INT_MAX, V|E|D, "colorspace_type"},
-{"bt2020nc","BT.2020 NCL", 0, AV_OPT_TYPE_CONST, {.i64 =
AVCOL_SPC_BT2020_NCL }, INT_MIN, INT_MAX, V|E|D, "colorspace_type"},
-{"bt2020c", "BT.2020 CL", 0, AV_OPT_TYPE_CONST, {.i64 =
AVCOL_SPC_BT2020_CL }, INT_MIN, INT_MAX, V|E|D, "colorspace_type"},
-{"smpte2085", "SMPTE 2085", 0, AV_OPT_TYPE_CONST, {.i64 =
AVCOL_SPC_SMPTE2085 }, INT_MIN, INT_MAX, V|E|D, "colorspace_type"},
-{"unspecified", "Unspecified", 0, AV_OPT_TYPE_CONST, {.i64 =
AVCOL_SPC_UNSPECIFIED }, INT_MIN, INT_MAX, V|E|D, "colorspace_type"},
-{"ycocg", "YCGCO", 0, AV_OPT_TYPE_CONST, {.i64 =
AVCOL_SPC_YCGCO }, INT_MIN, INT_MAX, V|E|D, "colorspace_type"},
-{"bt2020_ncl", "BT.2020 NCL", 0, AV_OPT_TYPE_CONST, {.i64 =
AVCOL_SPC_BT2020_NCL }, INT_MIN, INT_MAX, V|E|D, "colorspace_type"},
-{"bt2020_cl", "BT.2020 CL", 0, AV_OPT_TYPE_CONST, {.i64 =
AVCOL_SPC_BT2020_CL }, INT_MIN, INT_MAX, V|E|D, "colorspace_type"},
+{"rgb", "RGB",0, AV_OPT_TYPE_CONST,
{.i64 = AVCOL_SPC_RGB },INT_MIN, INT_MAX, V|E|D,
"colorspace_type"},
+{"bt709", "BT.709", 0, AV_OPT_TYPE_CONST,
{.i64 = AVCOL_SPC_BT709 }, INT_MIN, INT_MAX, V|E|D,
"colorspace_type"},
+{"unknown", "Unspecified",0, AV_OPT_TYPE_CONST,
{.i64 = AVCOL_SPC_UNSPECIFIED },INT_MIN, INT_MAX, V|E|D,
"colorspace_type"},
+{"fcc", "FCC",0, AV_OPT_TYPE_CONST,
{.i64 = AVCOL_SPC_FCC },INT_MIN, INT_MAX, V|E|D,
"colorspace_type"},
+{"bt470bg", "BT.470 BG", 0, AV_OPT_TYPE_CONST,
{.i64 = AVCOL_SPC_BT470BG },INT_MIN, INT_MAX, V|E|D,
"colorspace_type"},
+{"smpte170m", "SMPTE 170 M",0, AV_OPT_TYPE_CONST,
{.i64 = AVCOL_SPC_SMPTE170M }, INT_MIN, INT_MAX, V|E|D,
"colorspace_type"},
+{"smpte240m", "SMPTE 240 M",0, AV_OPT_TYPE_CONST,
{.i64 = AVCOL_SPC_SMPTE240M }, INT_MIN, INT_MAX, V|E|D,
"colorspace_type"},
+{"ycgco", "YCGCO", 0, AV_OPT_TYPE_CONST,
{.i64 = AVCOL_SPC_YCGCO }, INT_MIN, INT_MAX, V|E|D,
"colorspace_type"},
+{"bt2020nc", "BT.2020 NCL",0, AV_OPT_TYPE_CONST,
{.i64 = AVCOL_SPC_BT2020_NCL }, INT_MIN, INT_MAX, V|E|D,
"colorspace_type"},
+{"bt2020c", "BT.2020 CL", 0, AV_OPT_TYPE_CONST,
{.i64 = AVCOL_SPC_BT2020_CL }, INT_MIN, INT_MAX, V|E|D,
"colorspace_type"},
+{"smpte2085", "SMPTE 2085", 0, AV_OPT_TYPE_CONST,
{.i64 = AVCOL_SPC_SMPTE2085 }, INT_MIN, INT_MAX, V|E|D,
"colorspace_type"},
+{"chroma-derived-nc", "Chroma-derived NCL", 0, AV_OPT_TYPE_C
Re: [FFmpeg-devel] [PATCH 6/8] avcodec/smacker: Directly goto error in case of error
Paul B Mahol:
> On 7/31/20, Andreas Rheinhardt wrote:
>> Signed-off-by: Andreas Rheinhardt
>> ---
>> libavcodec/smacker.c | 7 ---
>> 1 file changed, 4 insertions(+), 3 deletions(-)
>>
>> diff --git a/libavcodec/smacker.c b/libavcodec/smacker.c
>> index 8a4d88cfed..4b1f0f1b7c 100644
>> --- a/libavcodec/smacker.c
>> +++ b/libavcodec/smacker.c
>> @@ -251,17 +251,18 @@ static int smacker_decode_header_tree(SmackVContext
>> *smk, GetBitContext *gb, int
>> err = AVERROR(ENOMEM);
>> goto error;
>> }
>> +*recodes = huff.values;
>>
>> res = smacker_decode_bigtree(gb, &huff, &ctx, 0);
>> -if (res < 0)
>> +if (res < 0) {
>> err = res;
>> +goto error;
>> +}
>> skip_bits1(gb);
>> if(ctx.last[0] == -1) ctx.last[0] = huff.current++;
>> if(ctx.last[1] == -1) ctx.last[1] = huff.current++;
>> if(ctx.last[2] == -1) ctx.last[2] = huff.current++;
>>
>> -*recodes = huff.values;
>
> Commit log does not explain this change at all.
> And it looks wrong at first look.
>
huff.values is freshly allocated and if an error happens after its
allocation, it either needs to be stored permanently to not go out of
scope or it needs to be freed in this function. The latter option would
lead to redundant code (one can just reuse the decoder's close
function), so neither the old nor my proposed new code does this. The
old code solves this problem by not jumping to error in case
smacker_decode_bigtree() fails, my new code solves this problem by
storing the array immediately after its allocation (before
smacker_decode_bigtree()). (Another option would be to store the array
after the error: label, but I think storing something as soon as
possible is better practice).
- Andreas
>> -
>> error:
>> for (int i = 0; i < 2; i++) {
>> if (vlc[i].table)
>> --
>> 2.20.1
>>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 6/8] avcodec/smacker: Directly goto error in case of error
On 8/19/20, Andreas Rheinhardt wrote:
> Paul B Mahol:
>> On 7/31/20, Andreas Rheinhardt wrote:
>>> Signed-off-by: Andreas Rheinhardt
>>> ---
>>> libavcodec/smacker.c | 7 ---
>>> 1 file changed, 4 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/libavcodec/smacker.c b/libavcodec/smacker.c
>>> index 8a4d88cfed..4b1f0f1b7c 100644
>>> --- a/libavcodec/smacker.c
>>> +++ b/libavcodec/smacker.c
>>> @@ -251,17 +251,18 @@ static int smacker_decode_header_tree(SmackVContext
>>> *smk, GetBitContext *gb, int
>>> err = AVERROR(ENOMEM);
>>> goto error;
>>> }
>>> +*recodes = huff.values;
>>>
>>> res = smacker_decode_bigtree(gb, &huff, &ctx, 0);
>>> -if (res < 0)
>>> +if (res < 0) {
>>> err = res;
>>> +goto error;
>>> +}
>>> skip_bits1(gb);
>>> if(ctx.last[0] == -1) ctx.last[0] = huff.current++;
>>> if(ctx.last[1] == -1) ctx.last[1] = huff.current++;
>>> if(ctx.last[2] == -1) ctx.last[2] = huff.current++;
>>>
>>> -*recodes = huff.values;
>>
>> Commit log does not explain this change at all.
>> And it looks wrong at first look.
>>
>
> huff.values is freshly allocated and if an error happens after its
> allocation, it either needs to be stored permanently to not go out of
> scope or it needs to be freed in this function. The latter option would
> lead to redundant code (one can just reuse the decoder's close
> function), so neither the old nor my proposed new code does this. The
> old code solves this problem by not jumping to error in case
> smacker_decode_bigtree() fails, my new code solves this problem by
> storing the array immediately after its allocation (before
> smacker_decode_bigtree()). (Another option would be to store the array
> after the error: label, but I think storing something as soon as
> possible is better practice).
Add this explanation in commit log and patch is fine.
>
> - Andreas
>
>>> -
>>> error:
>>> for (int i = 0; i < 2; i++) {
>>> if (vlc[i].table)
>>> --
>>> 2.20.1
>>>
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH V4] dnn_backend_openvino.c: parse options in openvino backend
Hi Yejun!
On 2020-08-18 23:08 +0800, Guo, Yejun wrote:
> Signed-off-by: Guo, Yejun
> ---
> v3: use AVOption
> v4: don't add new file dnn_common.h/c
>
> libavfilter/dnn/dnn_backend_openvino.c | 50
> +-
> 1 file changed, 49 insertions(+), 1 deletion(-)
>
> diff --git a/libavfilter/dnn/dnn_backend_openvino.c
> b/libavfilter/dnn/dnn_backend_openvino.c
> index d343bf2..277c313 100644
> --- a/libavfilter/dnn/dnn_backend_openvino.c
> +++ b/libavfilter/dnn/dnn_backend_openvino.c
> @@ -26,9 +26,37 @@
> #include "dnn_backend_openvino.h"
> #include "libavformat/avio.h"
> #include "libavutil/avassert.h"
> +#include "libavutil/opt.h"
> #include
>
> +typedef struct OVOptions{
> +uint32_t batch_size;
> +uint32_t req_num;
> +} OVOptions;
> +
> +typedef struct OvContext {
> +const AVClass *class;
> +OVOptions options;
> +} OvContext;
> +
> +#define OFFSET(x) offsetof(OvContext, x)
> +#define FLAGS AV_OPT_FLAG_FILTERING_PARAM
> +static const AVOption dnn_ov_options[] = {
> +{ "batch", "batch size",OFFSET(options.batch_size),
> AV_OPT_TYPE_INT, { .i64 = 1 }, INT_MIN, INT_MAX, FLAGS },
> +{ "nireq", "number of request", OFFSET(options.req_num),
> AV_OPT_TYPE_INT, { .i64 = 1 }, INT_MIN, INT_MAX, FLAGS },
> +{ NULL },
> +};
If I'm not mistaken, you must use type int when using AV_OPT_TYPE_INT .
AFAIK we have these integer types
* AV_OPT_TYPE_INT -> int
* AV_OPT_TYPE_INT64 -> int64_t
* AV_OPT_TYPE_UINT64 -> uint64_t
and you can assume int to be at least 32 bits wide.
> +
> +static const AVClass dnn_ov_class = {
> +.class_name = "dnn_ov",
> +.item_name = av_default_item_name,
> +.option = dnn_ov_options,
> +.version= LIBAVUTIL_VERSION_INT,
> +.category = AV_CLASS_CATEGORY_FILTER,
> +};
> +
> typedef struct OVModel{
> +OvContext ctx;
> ie_core_t *core;
> ie_network_t *network;
> ie_executable_network_t *exe_network;
> @@ -155,6 +183,22 @@ err:
> return DNN_ERROR;
> }
>
> +static int dnn_parse_options(void *ctx, const char *options)
> +{
> +AVDictionary *dict = NULL;
> +int err = av_dict_parse_string(&dict, options, "=", "&", 0);
> +if (err < 0) {
> +av_dict_free(&dict);
> +return err;
> +}
> +
> +av_opt_set_defaults(ctx);
> +err = av_opt_set_dict(ctx, &dict);
> +
> +av_dict_free(&dict);
> +return err;
> +}
> +
> DNNModel *ff_dnn_load_model_ov(const char *model_filename, const char
> *options)
> {
> DNNModel *model = NULL;
> @@ -171,6 +215,11 @@ DNNModel *ff_dnn_load_model_ov(const char
> *model_filename, const char *options)
> if (!ov_model)
> goto err;
>
> +ov_model->ctx.class = &dnn_ov_class;
> +model->options = options;
> +if (dnn_parse_options(&ov_model->ctx, model->options) < 0)
> +goto err;
> +
> status = ie_core_create("", &ov_model->core);
> if (status != OK)
> goto err;
> @@ -186,7 +235,6 @@ DNNModel *ff_dnn_load_model_ov(const char
> *model_filename, const char *options)
> model->model = (void *)ov_model;
> model->set_input_output = &set_input_output_ov;
> model->get_input = &get_input_ov;
> -model->options = options;
>
> return model;
>
> --
Sorry, if I missed it, are the values set from the options used anywhere?
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] avformat/movenc: write the colr atom by default
On Mon, Apr 13, 2020 at 4:14 PM Michael Bradshaw wrote: > Attached is an updated patch that passes fate. > I completely forgot about this patch. If no one objects over the next few days I plan on pushing this. FATE still passes. ___ 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/movenc: write the colr atom by default
On 8/19/20, Michael Bradshaw wrote: > On Mon, Apr 13, 2020 at 4:14 PM Michael Bradshaw wrote: > >> Attached is an updated patch that passes fate. >> > > I completely forgot about this patch. If no one objects over the next few > days I plan on pushing this. FATE still passes. Fine by me. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] libavcodec/proresdec2: Setup qmat_chroma according to RDD36
Signed-off-by: Harry Mallon
---
libavcodec/proresdec2.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/proresdec2.c b/libavcodec/proresdec2.c
index d5fbfc6711..4e1d0dd3f1 100644
--- a/libavcodec/proresdec2.c
+++ b/libavcodec/proresdec2.c
@@ -289,7 +289,7 @@ static int decode_frame_header(ProresContext *ctx, const
uint8_t *buf,
}
permute(ctx->qmat_chroma, ctx->prodsp.idct_permutation, ptr);
} else {
-memset(ctx->qmat_chroma, 4, 64);
+memcpy(ctx->qmat_chroma, ctx->qmat_luma, 64);
}
return hdr_size;
--
2.28.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] libavcodec/options_table: Add missing colorspace options
* chroma-derived-nc / chroma-derived-c and ictcp
Signed-off-by: Harry Mallon
---
doc/codecs.texi| 6 ++
libavcodec/options_table.h | 33 ++---
2 files changed, 24 insertions(+), 15 deletions(-)
diff --git a/doc/codecs.texi b/doc/codecs.texi
index c092aadc0e..1da2590795 100644
--- a/doc/codecs.texi
+++ b/doc/codecs.texi
@@ -1110,6 +1110,12 @@ BT.2020 NCL
BT.2020 CL
@item smpte2085
SMPTE 2085
+@item chroma-derived-nc
+Chroma-derived NCL
+@item chroma-derived-c
+Chroma-derived CL
+@item ictcp
+ICtCp
@end table
@item color_range @var{integer} (@emph{decoding/encoding,video})
diff --git a/libavcodec/options_table.h b/libavcodec/options_table.h
index 1d0db1b5a4..66bda42663 100644
--- a/libavcodec/options_table.h
+++ b/libavcodec/options_table.h
@@ -381,21 +381,24 @@ static const AVOption avcodec_options[] = {
{"bt2020_12bit", "BT.2020 - 12 bit", 0, AV_OPT_TYPE_CONST, {.i64 =
AVCOL_TRC_BT2020_12 },INT_MIN, INT_MAX, V|E|D, "color_trc_type"},
{"smpte428_1", "SMPTE 428-1", 0, AV_OPT_TYPE_CONST, {.i64 =
AVCOL_TRC_SMPTE428 }, INT_MIN, INT_MAX, V|E|D, "color_trc_type"},
{"colorspace", "color space", OFFSET(colorspace), AV_OPT_TYPE_INT, {.i64 =
AVCOL_SPC_UNSPECIFIED }, 0, INT_MAX, V|E|D, "colorspace_type"},
-{"rgb", "RGB", 0, AV_OPT_TYPE_CONST, {.i64 = AVCOL_SPC_RGB },
INT_MIN, INT_MAX, V|E|D, "colorspace_type"},
-{"bt709", "BT.709", 0, AV_OPT_TYPE_CONST, {.i64 = AVCOL_SPC_BT709
}, INT_MIN, INT_MAX, V|E|D, "colorspace_type"},
-{"unknown", "Unspecified", 0, AV_OPT_TYPE_CONST, {.i64 =
AVCOL_SPC_UNSPECIFIED }, INT_MIN, INT_MAX, V|E|D, "colorspace_type"},
-{"fcc", "FCC", 0, AV_OPT_TYPE_CONST, {.i64 = AVCOL_SPC_FCC },
INT_MIN, INT_MAX, V|E|D, "colorspace_type"},
-{"bt470bg", "BT.470 BG", 0, AV_OPT_TYPE_CONST, {.i64 = AVCOL_SPC_BT470BG
}, INT_MIN, INT_MAX, V|E|D, "colorspace_type"},
-{"smpte170m", "SMPTE 170 M", 0, AV_OPT_TYPE_CONST, {.i64 =
AVCOL_SPC_SMPTE170M }, INT_MIN, INT_MAX, V|E|D, "colorspace_type"},
-{"smpte240m", "SMPTE 240 M", 0, AV_OPT_TYPE_CONST, {.i64 =
AVCOL_SPC_SMPTE240M }, INT_MIN, INT_MAX, V|E|D, "colorspace_type"},
-{"ycgco", "YCGCO", 0, AV_OPT_TYPE_CONST, {.i64 = AVCOL_SPC_YCGCO
}, INT_MIN, INT_MAX, V|E|D, "colorspace_type"},
-{"bt2020nc","BT.2020 NCL", 0, AV_OPT_TYPE_CONST, {.i64 =
AVCOL_SPC_BT2020_NCL }, INT_MIN, INT_MAX, V|E|D, "colorspace_type"},
-{"bt2020c", "BT.2020 CL", 0, AV_OPT_TYPE_CONST, {.i64 =
AVCOL_SPC_BT2020_CL }, INT_MIN, INT_MAX, V|E|D, "colorspace_type"},
-{"smpte2085", "SMPTE 2085", 0, AV_OPT_TYPE_CONST, {.i64 =
AVCOL_SPC_SMPTE2085 }, INT_MIN, INT_MAX, V|E|D, "colorspace_type"},
-{"unspecified", "Unspecified", 0, AV_OPT_TYPE_CONST, {.i64 =
AVCOL_SPC_UNSPECIFIED }, INT_MIN, INT_MAX, V|E|D, "colorspace_type"},
-{"ycocg", "YCGCO", 0, AV_OPT_TYPE_CONST, {.i64 = AVCOL_SPC_YCGCO
}, INT_MIN, INT_MAX, V|E|D, "colorspace_type"},
-{"bt2020_ncl", "BT.2020 NCL", 0, AV_OPT_TYPE_CONST, {.i64 =
AVCOL_SPC_BT2020_NCL }, INT_MIN, INT_MAX, V|E|D, "colorspace_type"},
-{"bt2020_cl", "BT.2020 CL", 0, AV_OPT_TYPE_CONST, {.i64 =
AVCOL_SPC_BT2020_CL }, INT_MIN, INT_MAX, V|E|D, "colorspace_type"},
+{"rgb", "RGB",0, AV_OPT_TYPE_CONST, {.i64 =
AVCOL_SPC_RGB },INT_MIN, INT_MAX, V|E|D, "colorspace_type"},
+{"bt709", "BT.709", 0, AV_OPT_TYPE_CONST, {.i64 =
AVCOL_SPC_BT709 }, INT_MIN, INT_MAX, V|E|D, "colorspace_type"},
+{"unknown", "Unspecified",0, AV_OPT_TYPE_CONST, {.i64 =
AVCOL_SPC_UNSPECIFIED },INT_MIN, INT_MAX, V|E|D, "colorspace_type"},
+{"fcc", "FCC",0, AV_OPT_TYPE_CONST, {.i64 =
AVCOL_SPC_FCC },INT_MIN, INT_MAX, V|E|D, "colorspace_type"},
+{"bt470bg", "BT.470 BG", 0, AV_OPT_TYPE_CONST, {.i64 =
AVCOL_SPC_BT470BG },INT_MIN, INT_MAX, V|E|D, "colorspace_type"},
+{"smpte170m", "SMPTE 170 M",0, AV_OPT_TYPE_CONST, {.i64 =
AVCOL_SPC_SMPTE170M }, INT_MIN, INT_MAX, V|E|D, "colorspace_type"},
+{"smpte240m", "SMPTE 240 M",0, AV_OPT_TYPE_CONST, {.i64 =
AVCOL_SPC_SMPTE240M }, INT_MIN, INT_MAX, V|E|D, "colorspace_type"},
+{"ycgco", "YCGCO", 0, AV_OPT_TYPE_CONST, {.i64 =
AVCOL_SPC_YCGCO }, INT_MIN, INT_MAX, V|E|D, "colorspace_type"},
+{"bt2020nc", "BT.2020 NCL",0, AV_OPT_TYPE_CONST, {.i64 =
AVCOL_SPC_BT2020_NCL }, INT_MIN, INT_MAX, V|E|D, "colorspace_type"},
+{"bt2020c", "BT.2020 CL", 0, AV_OPT_TYPE_CONST, {.i64 =
AVCOL_SPC_BT2020_CL }, INT_MIN, INT_MAX, V|E|D, "colorspace_type"},
+{"smpte2085", "SMPTE 2085", 0, AV_OPT_TYPE_CONST, {.i64 =
AVCOL_SPC_SMPTE2085 }, INT_MIN, INT_MAX, V|E|D, "colorspace_type"},
+{"chroma-derived-nc", "Chroma-
[FFmpeg-devel] [PATCH] libavformat/r3d.c: Fix Use-of-uninitialized-value in filename.
While reading the filename tag, it mays return a EOF and we are still
copying the file with uninitialized value.
---
libavformat/r3d.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavformat/r3d.c b/libavformat/r3d.c
index 7aa0c5a2c3..7ba589530d 100644
--- a/libavformat/r3d.c
+++ b/libavformat/r3d.c
@@ -54,7 +54,7 @@ static int r3d_read_red1(AVFormatContext *s)
{
AVStream *st = avformat_new_stream(s, NULL);
R3DContext *r3d = s->priv_data;
-char filename[258];
+char filename[258] = {};
int tmp;
int av_unused tmp2;
AVRational framerate;
--
2.28.0.220.ged08abb693-goog
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v2] avfilter/formats: Avoid code duplication when merging samplerates
Right now, ff_merge_samplerates() contains three instances of the
MERGE_REF() macro, a macro which reallocates an array, updates some
pointers in a loop and frees several buffers. This commit makes it
possible to contain only one instance of said macro in the function,
thereby reducing codesize.
Signed-off-by: Andreas Rheinhardt
---
You're right. A macro should not contain gotos of its own.
This of course implied trivial changes for the cosmetics patch.
I don't think I need to resend it.
Will apply this tomorrow if no one objects.
libavfilter/formats.c | 31 +--
1 file changed, 17 insertions(+), 14 deletions(-)
diff --git a/libavfilter/formats.c b/libavfilter/formats.c
index 28433dcd52..2a40762897 100644
--- a/libavfilter/formats.c
+++ b/libavfilter/formats.c
@@ -56,11 +56,21 @@ do {
\
/**
* Add all formats common to a and b to a, add b's refs to a and destroy b.
+ * If empty_allowed is set and one of a,b->nb is zero, the lists are
+ * merged; otherwise, it is treated as error.
*/
-#define MERGE_FORMATS(a, b, fmts, nb, type, fail_statement)\
+#define MERGE_FORMATS(a, b, fmts, nb, type, fail_statement, empty_allowed) \
do {
\
-int i, j, k = 0; \
+int i, j, k = 0, skip = 0; \
\
+if (empty_allowed) { \
+if (!a->nb || !b->nb) {\
+if (!a->nb)\
+FFSWAP(type *, a, b); \
+skip = 1; \
+} \
+} \
+if (!skip) { \
for (i = 0; i < a->nb; i++)
\
for (j = 0; j < b->nb; j++)
\
if (a->fmts[i] == b->fmts[j]) {
\
@@ -72,7 +82,8 @@ do {
if (!k)\
{ fail_statement } \
a->nb = k; \
-
\
+} \
+ \
MERGE_REF(a, b, fmts, type, fail_statement); \
} while (0)
@@ -110,7 +121,7 @@ AVFilterFormats *ff_merge_formats(AVFilterFormats *a,
AVFilterFormats *b,
if (alpha2 > alpha1 || chroma2 > chroma1)
return NULL;
-MERGE_FORMATS(a, b, formats, nb_formats, AVFilterFormats, return NULL;);
+MERGE_FORMATS(a, b, formats, nb_formats, AVFilterFormats, return NULL;, 0);
return a;
}
@@ -120,16 +131,8 @@ AVFilterFormats *ff_merge_samplerates(AVFilterFormats *a,
{
if (a == b) return a;
-if (a->nb_formats && b->nb_formats) {
-MERGE_FORMATS(a, b, formats, nb_formats, AVFilterFormats, return
NULL;);
-return a;
-} else if (a->nb_formats) {
-MERGE_REF(a, b, formats, AVFilterFormats, return NULL;);
-return a;
-} else {
-MERGE_REF(b, a, formats, AVFilterFormats, return NULL;);
-return b;
-}
+MERGE_FORMATS(a, b, formats, nb_formats, AVFilterFormats, return NULL;, 1);
+return a;
}
AVFilterChannelLayouts *ff_merge_channel_layouts(AVFilterChannelLayouts *a,
--
2.20.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 3/7] avfilter/formats: Resize potentially oversized arrays
Nicolas George: > Andreas Rheinhardt (12020-08-15): >> Signed-off-by: Andreas Rheinhardt >> --- >> libavfilter/formats.c | 4 >> 1 file changed, 4 insertions(+) > > The patch works, but I do not think it is necessary or even useful: > these arrays are short-lived anyway, they will be freed very soon > anyway. > > (Also, we may want to make them power-of-two dynarrays at some places, > to avoid quadratic adds of formats.) > > Regards, > I was unsure about this one and actually never liked it. I only did it because the slight size increase is the only downside from patch two. But you're right. It's dropped. - 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 0/3] avcodec/aacdec_template: improvements to 22.2 layout logic
On Tue, Aug 18, 2020 at 10:25 PM Jan Ekström wrote: > > The first two commits fix both of the fuzzing samples I have on hand. > One being from #8845, and another provided privately by Michael. Changes have > been tested both with clang 10's ASAN as well as standard valgrind. > For the record I have a feeling that the actual reason for the issues is an underlying issue where a ChannelElement in a list gets allocated, but then also freed (yet not actually set to nullptr?), and my not strict enough validation based on valid samples just happened to bring it to the surface. Since I got publicly hurried and called out to "Please fix it or revert ASAP!", here is the thing that anyone sane enough will attempt to do to get people off their backs to get more breathing room: Here's more stringent checks so that 22.2 will only be probed if the configuration aligns exactly as it does for valid streams, and it seems to remove the symptoms with regards to all of the provided fuzzed samples. I hope y'all have much more fun time than I have. Jan ___ 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 6/7] avfilter/formats: Always keep longer references list when merging lists
Nicolas George: > Andreas Rheinhardt (12020-08-15): >> This means that one only needs to update the shorter list of references. >> >> Signed-off-by: Andreas Rheinhardt >> --- >> I doubt that this optimizations is worth the additional complexity. I >> have just added it for you to decide. > > I must say, I do not understand the logic, especially the preserve_fmts > bit. > The MERGE_REF() macro is asymmetric by design: The refs of the second argument are added to the refs of the first argument and the second argument is freed. The list of the first argument meanwhile is/ought to be preserved. When swapping, one therefore has to swap the non-ref-fields, too. But the MERGE_REF at the end of ff_merge_channel_layouts() is special. The list will be freed and replaced by a different list after the macro anyway, so one doesn't need to preserve the list at all. preserve_fmts exists so that the compiler can optimize this part of MERGE_REF() away for that invocation of the macro. > I think we can leave it for later. > Or it can be dropped altogether. Which I would actually prefer. > Have you given thought to the linked list option I suggested? > It is certainly interesting (e.g. if I am not mistaken, it would mean that ff_merge_formats/samplerates() can't fail at all any more). I see two obvious downsides: Traversing the list for freeing is slower (but it should only be a constant factor) and it increases the size of the AVFilterLink even after merging. But I don't consider these obstacles to have much weight. Speaking of AVFilterLink: All ff_merge_*() as well as ff_can_merge_*() always use the in- and out-fields of one and the same AVFilterLink. I wonder whether these function should not just take the AVFilterLink * as parameter. It would also mean that ff_merge_formats() would have the same signature as the other functions, which simplifies macros. - Andreas ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] ffmpeg software and patch management
Hello,
Ffmpeg is currently being used on a system that I support and I need
clarification that version 3.4 is still being maintained and patched on a
daily basis. Can you please provide me a statement indicating that this
software is still supported and a date of how long it will be supported?
Very Respectfully,
Tenisha
Tenisha Carter
NAWC WOLF, GUNSS
tenisha.cart...@navy.mil
carter_teni...@bah.com
(301) 995-8427
-Original Message-
From: ffmpeg-devel On Behalf Of Nicolas
George
Sent: Wednesday, August 19, 2020 1:16 PM
To: FFmpeg development discussions and patches
Cc: Andreas Rheinhardt
Subject: [External] Re: [FFmpeg-devel] [PATCH 4/7] avfilter/formats: Avoid
code duplication when merging samplerates
Andreas Rheinhardt (12020-08-15):
> by adapting the MERGE_FORMATS() so that only one instance of the
> MERGE_REF() macro needs to exist in ff_merge_samplerates().
Nit: the first line of the commit message should be a short summary.
>
> Signed-off-by: Andreas Rheinhardt
> ---
> libavfilter/formats.c | 26 ++
> 1 file changed, 14 insertions(+), 12 deletions(-)
>
> diff --git a/libavfilter/formats.c b/libavfilter/formats.c index
> 4efbcbebfe..e8a43a434d 100644
> --- a/libavfilter/formats.c
> +++ b/libavfilter/formats.c
> @@ -56,12 +56,21 @@ do {
\
>
> /**
> * Add all formats common to a and b to a, add b's refs to a and destroy
b.
> + * If empty_allowed is set and one of a,b->nb is zero, the lists are
> + * merged; otherwise, it is treated as error.
> */
> -#define MERGE_FORMATS(a, b, fmts, nb, type, fail_statement)
\
> +#define MERGE_FORMATS(a, b, fmts, nb, type, fail_statement,
> +empty_allowed) \
> do {
\
> int i, j, k = 0;
\
> void *tmp;
\
>
> \
> +if (empty_allowed) {
\
> +if (!a->nb || !b->nb) {
\
> +if (!a->nb)
\
> +FFSWAP(type *, a, b);
\
> +goto merge_ref;
\
> +}
\
> +}
\
I think a big if () / else would be better than a goto.
> for (i = 0; i < a->nb; i++)
\
> for (j = 0; j < b->nb; j++)
\
> if (a->fmts[i] == b->fmts[j]) {
\
> @@ -77,6 +86,7 @@ do {
> if (tmp)
\
> a->fmts = tmp;
\
>
> \
> +merge_ref:
\
> MERGE_REF(a, b, fmts, type, fail_statement);
\
> } while (0)
>
> @@ -114,7 +124,7 @@ AVFilterFormats *ff_merge_formats(AVFilterFormats *a,
AVFilterFormats *b,
> if (alpha2 > alpha1 || chroma2 > chroma1)
> return NULL;
>
> -MERGE_FORMATS(a, b, formats, nb_formats, AVFilterFormats, return
NULL;);
> +MERGE_FORMATS(a, b, formats, nb_formats, AVFilterFormats, return
> + NULL;, 0);
>
> return a;
> }
> @@ -124,16 +134,8 @@ AVFilterFormats
> *ff_merge_samplerates(AVFilterFormats *a, {
> if (a == b) return a;
>
> -if (a->nb_formats && b->nb_formats) {
> -MERGE_FORMATS(a, b, formats, nb_formats, AVFilterFormats, return
NULL;);
> -return a;
> -} else if (a->nb_formats) {
> -MERGE_REF(a, b, formats, AVFilterFormats, return NULL;);
> -return a;
> -} else {
> -MERGE_REF(b, a, formats, AVFilterFormats, return NULL;);
> -return b;
> -}
> +MERGE_FORMATS(a, b, formats, nb_formats, AVFilterFormats, return
NULL;, 1);
> +return a;
> }
>
> AVFilterChannelLayouts
> *ff_merge_channel_layouts(AVFilterChannelLayouts *a,
Overall, it does not look very beneficial, but I suppose it is ok.
Regards,
--
Nicolas George
smime.p7s
Description: S/MIME cryptographic signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] libavformat/r3d.c: Fix Use-of-uninitialized-value in filename.
On 8/19/2020 4:59 PM, Thierry Foucu wrote:
> While reading the filename tag, it mays return a EOF and we are still
> copying the file with uninitialized value.
> ---
> libavformat/r3d.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavformat/r3d.c b/libavformat/r3d.c
> index 7aa0c5a2c3..7ba589530d 100644
> --- a/libavformat/r3d.c
> +++ b/libavformat/r3d.c
> @@ -54,7 +54,7 @@ static int r3d_read_red1(AVFormatContext *s)
> {
> AVStream *st = avformat_new_stream(s, NULL);
> R3DContext *r3d = s->priv_data;
> -char filename[258];
> +char filename[258] = {};
> int tmp;
> int av_unused tmp2;
> AVRational framerate;
It may be a better idea to check instead if avio_read() actually reads
the required 257 bytes, and abort otherwise.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] libavformat/r3d.c: Fix Use-of-uninitialized-value in filename.
While reading the filename tag, it mays return a EOF and we are still copying the file with uninitialized value. --- libavformat/r3d.c | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/libavformat/r3d.c b/libavformat/r3d.c index 7aa0c5a2c3..d013b8c30e 100644 --- a/libavformat/r3d.c +++ b/libavformat/r3d.c @@ -56,6 +56,7 @@ static int r3d_read_red1(AVFormatContext *s) R3DContext *r3d = s->priv_data; char filename[258]; int tmp; +int ret; int av_unused tmp2; AVRational framerate; @@ -97,7 +98,9 @@ static int r3d_read_red1(AVFormatContext *s) r3d->audio_channels = avio_r8(s->pb); // audio channels av_log(s, AV_LOG_TRACE, "audio channels %d\n", tmp); -avio_read(s->pb, filename, 257); +ret = avio_read(s->pb, filename, 257); +if (ret < 257) +return AVERROR_EOF; filename[sizeof(filename)-1] = 0; av_dict_set(&st->metadata, "filename", filename, 0); -- 2.28.0.220.ged08abb693-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 0/3] avcodec/aacdec_template: improvements to 22.2 layout logic
On 8/19/2020 6:51 PM, Jan Ekström wrote: > On Tue, Aug 18, 2020 at 10:25 PM Jan Ekström wrote: >> >> The first two commits fix both of the fuzzing samples I have on hand. >> One being from #8845, and another provided privately by Michael. Changes have >> been tested both with clang 10's ASAN as well as standard valgrind. >> > > For the record I have a feeling that the actual reason for the issues > is an underlying issue where a ChannelElement in a list gets > allocated, but then also freed (yet not actually set to nullptr?), and > my not strict enough validation based on valid samples just happened > to bring it to the surface. > > Since I got publicly hurried and called out to "Please fix it or > revert ASAP!", here is the thing that anyone sane enough will attempt > to do to get people off their backs to get more breathing room: Here's > more stringent checks so that 22.2 will only be probed if the > configuration aligns exactly as it does for valid streams, and it > seems to remove the symptoms with regards to all of the provided > fuzzed samples. > > I hope y'all have much more fun time than I have. I think you're reading too much into what Paul said. The change introduced issues with fuzzed samples, which of course needs to be fixed. He could have simply asked for a fix before suggesting a revert (last resort when the author refuses to fix something, which is not the case here), but by no means you should feed stressed about the request or the way he made it. > > Jan > ___ > 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 4/4] ffplay: do not set redundant channel count on abuffersink.
On Fri, 14 Aug 2020, Nicolas George wrote:
Signed-off-by: Nicolas George
---
fftools/ffplay.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fftools/ffplay.c b/fftools/ffplay.c
index d673b8049a..6c9c041e9a 100644
--- a/fftools/ffplay.c
+++ b/fftools/ffplay.c
@@ -2008,7 +2008,7 @@ static int configure_audio_filters(VideoState *is, const
char *afilters, int for
if (force_output_format) {
channel_layouts[0] = is->audio_tgt.channel_layout;
-channels [0] = is->audio_tgt.channels;
+channels [0] = is->audio_tgt.channel_layout ? -1 :
is->audio_tgt.channels;
Why it is better if we don't set it?
Thanks,
Marton
___
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] qsv: remove audio error code
On Wed, 2020-08-19 at 13:53 +0200, Nicolas George wrote:
> Haihao Xiang (12020-08-19):
> > ---
> > libavcodec/qsv.c | 3 ---
> > 1 file changed, 3 deletions(-)
> >
> > diff --git a/libavcodec/qsv.c b/libavcodec/qsv.c
> > index faa424bb68..6776b745b9 100644
> > --- a/libavcodec/qsv.c
> > +++ b/libavcodec/qsv.c
> > @@ -143,8 +143,6 @@ static const struct {
> > { MFX_ERR_INVALID_VIDEO_PARAM, AVERROR(EINVAL), "invalid video
> > parameters" },
> > { MFX_ERR_UNDEFINED_BEHAVIOR, AVERROR_BUG, "undefined
> > behavior" },
> > { MFX_ERR_DEVICE_FAILED,AVERROR(EIO),"device
> > failed"},
> > -{ MFX_ERR_INCOMPATIBLE_AUDIO_PARAM, AVERROR(EINVAL), "incompatible
> > audio parameters"},
> > -{ MFX_ERR_INVALID_AUDIO_PARAM, AVERROR(EINVAL), "invalid audio
> > parameters" },
> >
> > { MFX_WRN_IN_EXECUTION, 0, "operation in
> > execution" },
> > { MFX_WRN_DEVICE_BUSY, 0, "device
> > busy" },
> > @@ -154,7 +152,6 @@ static const struct {
> > { MFX_WRN_VALUE_NOT_CHANGED,0, "value is
> > saturated" },
> > { MFX_WRN_OUT_OF_RANGE, 0, "value out of
> > range" },
> > { MFX_WRN_FILTER_SKIPPED, 0, "filter
> > skipped" },
> > -{ MFX_WRN_INCOMPATIBLE_AUDIO_PARAM, 0, "incompatible
> > audio parameters"},
> > };
> >
> > int ff_qsv_map_error(mfxStatus mfx_err, const char **desc)
>
> Why?
qsv in FFmpeg is for video only, actually the SDK is for HW accelerated video
decode, encode and filtering now, see
https://github.com/Intel-Media-SDK/MediaSDK#intel-media-sdk.
Thanks
Haihao
>
> Regards,
>
> ___
> 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 V4] dnn_backend_openvino.c: parse options in openvino backend
> -Original Message-
> From: ffmpeg-devel On Behalf Of
> Alexander Strasser
> Sent: 2020年8月20日 4:06
> To: FFmpeg development discussions and patches
> Subject: Re: [FFmpeg-devel] [PATCH V4] dnn_backend_openvino.c: parse options
> in openvino backend
>
> Hi Yejun!
>
> On 2020-08-18 23:08 +0800, Guo, Yejun wrote:
> > Signed-off-by: Guo, Yejun
> > ---
> > v3: use AVOption
> > v4: don't add new file dnn_common.h/c
> >
> > libavfilter/dnn/dnn_backend_openvino.c | 50
> > +-
> > 1 file changed, 49 insertions(+), 1 deletion(-)
> >
> > diff --git a/libavfilter/dnn/dnn_backend_openvino.c
> > b/libavfilter/dnn/dnn_backend_openvino.c
> > index d343bf2..277c313 100644
> > --- a/libavfilter/dnn/dnn_backend_openvino.c
> > +++ b/libavfilter/dnn/dnn_backend_openvino.c
> > @@ -26,9 +26,37 @@
> > #include "dnn_backend_openvino.h"
> > #include "libavformat/avio.h"
> > #include "libavutil/avassert.h"
> > +#include "libavutil/opt.h"
> > #include
> >
> > +typedef struct OVOptions{
> > +uint32_t batch_size;
> > +uint32_t req_num;
> > +} OVOptions;
> > +
> > +typedef struct OvContext {
> > +const AVClass *class;
> > +OVOptions options;
> > +} OvContext;
> > +
> > +#define OFFSET(x) offsetof(OvContext, x) #define FLAGS
> > +AV_OPT_FLAG_FILTERING_PARAM static const AVOption dnn_ov_options[] =
> > +{
> > +{ "batch", "batch size",OFFSET(options.batch_size),
> AV_OPT_TYPE_INT, { .i64 = 1 }, INT_MIN, INT_MAX, FLAGS },
> > +{ "nireq", "number of request", OFFSET(options.req_num),
> AV_OPT_TYPE_INT, { .i64 = 1 }, INT_MIN, INT_MAX, FLAGS },
> > +{ NULL },
> > +};
>
> If I'm not mistaken, you must use type int when using AV_OPT_TYPE_INT .
>
> AFAIK we have these integer types
>
> * AV_OPT_TYPE_INT -> int
> * AV_OPT_TYPE_INT64 -> int64_t
> * AV_OPT_TYPE_UINT64 -> uint64_t
>
> and you can assume int to be at least 32 bits wide.
>
thanks, I'll change from uint32_t to int.
> > @@ -186,7 +235,6 @@ DNNModel *ff_dnn_load_model_ov(const char
> *model_filename, const char *options)
> > model->model = (void *)ov_model;
> > model->set_input_output = &set_input_output_ov;
> > model->get_input = &get_input_ov;
> > -model->options = options;
> >
> > return model;
> >
> > --
>
> Sorry, if I missed it, are the values set from the options used anywhere?
You are right, the options are not used.
My teammates and I are working on the dnn backend performance
improvement, we have done locally many quick dirty code to verify our ideas and
found it requires some changes in the DNN module including these options.
(In our quick code, we are using fixed magic number for these options)
So, as a collaboration, my idea is to separate the changes one patch by one
patch,
and we can keep rebase locally, the final purpose is to upstream all our local
code with refinement.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] avcodec/proresenc: add support for PQ and HLG
Signed-off-by: Michael Bradshaw
---
libavcodec/proresenc_anatoliy.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/libavcodec/proresenc_anatoliy.c b/libavcodec/proresenc_anatoliy.c
index 1128978330..3aa18a3ca4 100644
--- a/libavcodec/proresenc_anatoliy.c
+++ b/libavcodec/proresenc_anatoliy.c
@@ -55,7 +55,8 @@ static const int bitrate_table[6] = { 1000, 2100, 3500,
5400, 7000, 1};
static const int valid_primaries[9] = { AVCOL_PRI_RESERVED0, AVCOL_PRI_BT709,
AVCOL_PRI_UNSPECIFIED, AVCOL_PRI_BT470BG,
AVCOL_PRI_SMPTE170M,
AVCOL_PRI_BT2020, AVCOL_PRI_SMPTE431, AVCOL_PRI_SMPTE432,INT_MAX };
-static const int valid_trc[4]= { AVCOL_TRC_RESERVED0, AVCOL_TRC_BT709,
AVCOL_TRC_UNSPECIFIED, INT_MAX };
+static const int valid_trc[4]= { AVCOL_TRC_RESERVED0, AVCOL_TRC_BT709,
AVCOL_TRC_UNSPECIFIED, AVCOL_TRC_SMPTE2084,
+ AVCOL_TRC_ARIB_STD_B67, INT_MAX };
static const int valid_colorspace[5] = { AVCOL_SPC_BT709,
AVCOL_SPC_UNSPECIFIED, AVCOL_SPC_SMPTE170M,
AVCOL_SPC_BT2020_NCL, INT_MAX };
--
2.28.0.220.ged08abb693-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/proresenc: add support for PQ and HLG
On Wed, Aug 19, 2020 at 8:24 PM Michael Bradshaw wrote:
> Signed-off-by: Michael Bradshaw
> ---
> libavcodec/proresenc_anatoliy.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/libavcodec/proresenc_anatoliy.c
> b/libavcodec/proresenc_anatoliy.c
> index 1128978330..3aa18a3ca4 100644
> --- a/libavcodec/proresenc_anatoliy.c
> +++ b/libavcodec/proresenc_anatoliy.c
> @@ -55,7 +55,8 @@ static const int bitrate_table[6] = { 1000, 2100, 3500,
> 5400, 7000, 1};
>
> static const int valid_primaries[9] = { AVCOL_PRI_RESERVED0,
> AVCOL_PRI_BT709, AVCOL_PRI_UNSPECIFIED, AVCOL_PRI_BT470BG,
> AVCOL_PRI_SMPTE170M,
> AVCOL_PRI_BT2020, AVCOL_PRI_SMPTE431, AVCOL_PRI_SMPTE432,INT_MAX };
> -static const int valid_trc[4]= { AVCOL_TRC_RESERVED0,
> AVCOL_TRC_BT709, AVCOL_TRC_UNSPECIFIED, INT_MAX };
> +static const int valid_trc[4]= { AVCOL_TRC_RESERVED0,
> AVCOL_TRC_BT709, AVCOL_TRC_UNSPECIFIED, AVCOL_TRC_SMPTE2084,
>
Should be [6], not [4]. Will send an updated patch.
+ AVCOL_TRC_ARIB_STD_B67, INT_MAX };
> static const int valid_colorspace[5] = { AVCOL_SPC_BT709,
> AVCOL_SPC_UNSPECIFIED, AVCOL_SPC_SMPTE170M,
> AVCOL_SPC_BT2020_NCL, INT_MAX };
>
> --
> 2.28.0.220.ged08abb693-goog
>
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] avcodec/proresenc: add support for PQ and HLG
Signed-off-by: Michael Bradshaw
---
libavcodec/proresenc_anatoliy.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/libavcodec/proresenc_anatoliy.c b/libavcodec/proresenc_anatoliy.c
index 1128978330..3005db0bb4 100644
--- a/libavcodec/proresenc_anatoliy.c
+++ b/libavcodec/proresenc_anatoliy.c
@@ -55,7 +55,8 @@ static const int bitrate_table[6] = { 1000, 2100, 3500,
5400, 7000, 1};
static const int valid_primaries[9] = { AVCOL_PRI_RESERVED0, AVCOL_PRI_BT709,
AVCOL_PRI_UNSPECIFIED, AVCOL_PRI_BT470BG,
AVCOL_PRI_SMPTE170M,
AVCOL_PRI_BT2020, AVCOL_PRI_SMPTE431, AVCOL_PRI_SMPTE432,INT_MAX };
-static const int valid_trc[4]= { AVCOL_TRC_RESERVED0, AVCOL_TRC_BT709,
AVCOL_TRC_UNSPECIFIED, INT_MAX };
+static const int valid_trc[6]= { AVCOL_TRC_RESERVED0, AVCOL_TRC_BT709,
AVCOL_TRC_UNSPECIFIED, AVCOL_TRC_SMPTE2084,
+ AVCOL_TRC_ARIB_STD_B67, INT_MAX };
static const int valid_colorspace[5] = { AVCOL_SPC_BT709,
AVCOL_SPC_UNSPECIFIED, AVCOL_SPC_SMPTE170M,
AVCOL_SPC_BT2020_NCL, INT_MAX };
--
2.28.0.220.ged08abb693-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] dnn/native: rename struct ConvolutionalNetwork to NativeModel
> -Original Message- > From: ffmpeg-devel On Behalf Of Ting Fu > Sent: 2020年8月19日 21:43 > To: ffmpeg-devel@ffmpeg.org > Subject: [FFmpeg-devel] [PATCH] dnn/native: rename struct > ConvolutionalNetwork to NativeModel > > Signed-off-by: Ting Fu > --- > libavfilter/dnn/dnn_backend_native.c | 112 +-- > libavfilter/dnn/dnn_backend_native.h | 4 +- > libavfilter/dnn/dnn_backend_tf.c | 24 +++--- > 3 files changed, 70 insertions(+), 70 deletions(-) > > diff --git a/libavfilter/dnn/dnn_backend_native.c > b/libavfilter/dnn/dnn_backend_native.c > index adc652a2c4..0be9c0b53c 100644 > --- a/libavfilter/dnn/dnn_backend_native.c > +++ b/libavfilter/dnn/dnn_backend_native.c > @@ -30,10 +30,10 @@ LGTM, so the struct name of TFModel, OVModel and NativeModel are unified. Will push tomorrow if no other comments. ___ 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: move output name from DNNModel.set_input_output to DNNModule.execute_model
currently, output is set both at DNNModel.set_input_output and
DNNModule.execute_model, it makes sense that the output name is
provided at model inference time so all the output info is set
at a single place.
and so DNNModel.set_input_output is renamed to DNNModel.set_input
Signed-off-by: Guo, Yejun
---
libavfilter/dnn/dnn_backend_native.c | 44 +++--
libavfilter/dnn/dnn_backend_native.h | 4 +-
libavfilter/dnn/dnn_backend_openvino.c | 50 +--
libavfilter/dnn/dnn_backend_openvino.h | 2 +-
libavfilter/dnn/dnn_backend_tf.c | 87 ++
libavfilter/dnn/dnn_backend_tf.h | 2 +-
libavfilter/dnn_interface.h| 4 +-
libavfilter/vf_derain.c| 6 +--
libavfilter/vf_dnn_processing.c| 9 ++--
libavfilter/vf_sr.c| 11 +++--
10 files changed, 82 insertions(+), 137 deletions(-)
diff --git a/libavfilter/dnn/dnn_backend_native.c
b/libavfilter/dnn/dnn_backend_native.c
index adc652a..efd77d0 100644
--- a/libavfilter/dnn/dnn_backend_native.c
+++ b/libavfilter/dnn/dnn_backend_native.c
@@ -50,7 +50,7 @@ static DNNReturnType get_input_native(void *model, DNNData
*input, const char *i
return DNN_ERROR;
}
-static DNNReturnType set_input_output_native(void *model, DNNData *input,
const char *input_name, const char **output_names, uint32_t nb_output)
+static DNNReturnType set_input_native(void *model, DNNData *input, const char
*input_name)
{
ConvolutionalNetwork *network = (ConvolutionalNetwork *)model;
DnnOperand *oprd = NULL;
@@ -87,27 +87,6 @@ static DNNReturnType set_input_output_native(void *model,
DNNData *input, const
input->data = oprd->data;
-/* outputs */
-network->nb_output = 0;
-av_freep(&network->output_indexes);
-network->output_indexes = av_mallocz_array(nb_output,
sizeof(*network->output_indexes));
-if (!network->output_indexes)
-return DNN_ERROR;
-
-for (uint32_t i = 0; i < nb_output; ++i) {
-const char *output_name = output_names[i];
-for (int j = 0; j < network->operands_num; ++j) {
-oprd = &network->operands[j];
-if (strcmp(oprd->name, output_name) == 0) {
-network->output_indexes[network->nb_output++] = j;
-break;
-}
-}
-}
-
-if (network->nb_output != nb_output)
-return DNN_ERROR;
-
return DNN_SUCCESS;
}
@@ -243,7 +222,7 @@ DNNModel *ff_dnn_load_model_native(const char
*model_filename, const char *optio
return NULL;
}
-model->set_input_output = &set_input_output_native;
+model->set_input = &set_input_native;
model->get_input = &get_input_native;
model->options = options;
@@ -255,11 +234,10 @@ fail:
return NULL;
}
-DNNReturnType ff_dnn_execute_model_native(const DNNModel *model, DNNData
*outputs, uint32_t nb_output)
+DNNReturnType ff_dnn_execute_model_native(const DNNModel *model, DNNData
*outputs, const char **output_names, uint32_t nb_output)
{
ConvolutionalNetwork *network = (ConvolutionalNetwork *)model->model;
int32_t layer;
-uint32_t nb = FFMIN(nb_output, network->nb_output);
if (network->layers_num <= 0 || network->operands_num <= 0)
return DNN_ERROR;
@@ -274,8 +252,19 @@ DNNReturnType ff_dnn_execute_model_native(const DNNModel
*model, DNNData *output
network->layers[layer].params);
}
-for (uint32_t i = 0; i < nb; ++i) {
-DnnOperand *oprd = &network->operands[network->output_indexes[i]];
+for (uint32_t i = 0; i < nb_output; ++i) {
+DnnOperand *oprd = NULL;
+const char *output_name = output_names[i];
+for (int j = 0; j < network->operands_num; ++j) {
+if (strcmp(network->operands[j].name, output_name) == 0) {
+oprd = &network->operands[j];
+break;
+}
+}
+
+if (oprd == NULL)
+return DNN_ERROR;
+
outputs[i].data = oprd->data;
outputs[i].height = oprd->dims[1];
outputs[i].width = oprd->dims[2];
@@ -335,7 +324,6 @@ void ff_dnn_free_model_native(DNNModel **model)
av_freep(&network->operands);
}
-av_freep(&network->output_indexes);
av_freep(&network);
}
av_freep(model);
diff --git a/libavfilter/dnn/dnn_backend_native.h
b/libavfilter/dnn/dnn_backend_native.h
index b455e44..4adfcd7 100644
--- a/libavfilter/dnn/dnn_backend_native.h
+++ b/libavfilter/dnn/dnn_backend_native.h
@@ -112,13 +112,11 @@ typedef struct ConvolutionalNetwork{
int32_t layers_num;
DnnOperand *operands;
int32_t operands_num;
-int32_t *output_indexes;
-uint32_t nb_output;
} ConvolutionalNetwork;
DNNModel *ff_dnn_load_model_native(const char *model_filename, const char
*options);
-DNNReturnType ff_dnn_execute_model_native(const DNNModel *model, DNNData
*outputs
Re: [FFmpeg-devel] [PATCH] avcodec/proresenc: add support for PQ and HLG
> On Aug 20, 2020, at 10:36 AM, Michael Bradshaw
> wrote:
>
> Signed-off-by: Michael Bradshaw
> ---
> libavcodec/proresenc_anatoliy.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/libavcodec/proresenc_anatoliy.c b/libavcodec/proresenc_anatoliy.c
> index 1128978330..3005db0bb4 100644
> --- a/libavcodec/proresenc_anatoliy.c
> +++ b/libavcodec/proresenc_anatoliy.c
> @@ -55,7 +55,8 @@ static const int bitrate_table[6] = { 1000, 2100, 3500,
> 5400, 7000, 1};
>
> static const int valid_primaries[9] = { AVCOL_PRI_RESERVED0,
> AVCOL_PRI_BT709, AVCOL_PRI_UNSPECIFIED, AVCOL_PRI_BT470BG,
> AVCOL_PRI_SMPTE170M,
> AVCOL_PRI_BT2020, AVCOL_PRI_SMPTE431, AVCOL_PRI_SMPTE432,INT_MAX };
> -static const int valid_trc[4]= { AVCOL_TRC_RESERVED0,
> AVCOL_TRC_BT709, AVCOL_TRC_UNSPECIFIED, INT_MAX };
> +static const int valid_trc[6]= { AVCOL_TRC_RESERVED0,
> AVCOL_TRC_BT709, AVCOL_TRC_UNSPECIFIED, AVCOL_TRC_SMPTE2084,
> + AVCOL_TRC_ARIB_STD_B67, INT_MAX };
For future-proof, how about remove the array size?
> static const int valid_colorspace[5] = { AVCOL_SPC_BT709,
> AVCOL_SPC_UNSPECIFIED, AVCOL_SPC_SMPTE170M,
> AVCOL_SPC_BT2020_NCL, INT_MAX };
>
> --
> 2.28.0.220.ged08abb693-goog
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel 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 5/5] lavc, doc: add libuavs3d video decoder wrapper
At 2020-08-19 22:23:07, "Moritz Barsnick" wrote: >On Wed, Aug 19, 2020 at 14:25:56 +0800, hwr...@126.com wrote: >> - AV1 Low overhead bitstream format demuxer >> +- AVS3 video decoder via libuavs3d > >I wonder whether the raw demuxer should have been mentioned in its >respective patch. Yes, I missed it. The demuxer will be mentioned in Changlog in the next version. Thanks. Huiwen Ren > >Moritz >___ >ffmpeg-devel mailing list >ffmpeg-devel@ffmpeg.org >https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > >To unsubscribe, visit link above, or email >ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v5 2/5] lavc/avs3: add AVS3 related definitions
At 2020-08-19 20:56:27, "Nicolas George" wrote: >hwr...@126.com (12020-08-19): >> From: hwren >> >> Signed-off-by: hwren >> --- >> libavcodec/Makefile | 2 + >> libavcodec/avs3.c | 95 + >> libavcodec/avs3.h | 52 + >> 3 files changed, 149 insertions(+) >> create mode 100644 libavcodec/avs3.c >> create mode 100644 libavcodec/avs3.h > >Except ff_avs3_frame_rate_tab, all these tables are only used in the >decoder. Is there a reason you want them in a separate header? Considering that the other tables are also declared in AVS3, and they may get reused by other coming encoders or decoders, so I put them together with the ff_avs3_frame_rate_tab in avs3.h. Thanks. Huiwen Ren > >Regards, > >-- > Nicolas George ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v5 2/5] lavc/avs3: add AVS3 related definitions
At 2020-08-19 22:18:52, "Moritz Barsnick" wrote: >On Wed, Aug 19, 2020 at 14:25:53 +0800, hwr...@126.com wrote: >> + * AVS3 related definition > >definitions? >> +}; >> \ No newline at end of file > >Please amend a carriage return to the last line. > >> + * AVS3 related definition > >definitions? > >Moritz Will be corrected. Thanks for pointing out. Regards, Huiwen Ren >___ >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 v5 3/5] lavc/avs3_parser: add avs3 parser
At 2020-08-19 22:14:04, "Moritz Barsnick" wrote:
>On Wed, Aug 19, 2020 at 14:25:54 +0800, hwr...@126.com wrote:
>> +for (; cur < buf_size; ++cur) {
>> +state = (state << 8) | buf[cur];
>> +if (ISPIC(buf[cur])){
>> +++cur;
>
>ffmpeg prefers the "cur++" style (twice in this block, and elsewhere).
Will be corrected. Thanks.
>
>> +// Skip bits: resv(1)
>> +//bitrate_low(18)
>> +//resv(1)
>> +//bitrate_high(12)
>> +//low_delay
>> +skip_bits(&gb, 32);
>
>Is "low_delay" part of the skipped bits? The rest already adds up to
>32.
No it's not...The low_delay is added by mistake. I will remove it in the next
version.
>
>> +av_log(avctx, AV_LOG_DEBUG,
>> + "avs3 parse seq hdr: profile %d; coded wxh: %dx%d; "
>> + "frame_rate_code %d\n", profile, avctx->width,
>> avctx->height, ratecode);
>
>Incorrect indentation.
Will be corrected. Thanks.
Cheers,
Huiwen Ren
>
>Cheers,
>Moritz
>___
>ffmpeg-devel mailing list
>ffmpeg-devel@ffmpeg.org
>https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
>To unsubscribe, visit link above, or email
>ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avutil/video_enc_params: fix code comment
zhilizhao 于2020年8月13日周四 下午12:55写道：
>
>
>
> > On Aug 13, 2020, at 11:57 AM, leozhang wrote:
> >
> > Signed-off-by: leozhang
> > ---
> > libavutil/video_enc_params.h | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/libavutil/video_enc_params.h b/libavutil/video_enc_params.h
> > index 43fa443..e3b422d 100644
> > --- a/libavutil/video_enc_params.h
> > +++ b/libavutil/video_enc_params.h
> > @@ -153,7 +153,7 @@ AVVideoEncParams *av_video_enc_params_alloc(enum
> > AVVideoEncParamsType type,
> > /**
> > * Allocates memory for AVEncodeInfoFrame plus an array of
> > * {@code nb_blocks} AVEncodeInfoBlock in the given AVFrame {@code frame}
> > - * as AVFrameSideData of type AV_FRAME_DATA_ENCODE_INFO
> > + * as AVFrameSideData of type AV_FRAME_DATA_VIDEO_ENC_PARAMS
> > * and initializes the variables.
> > */
> > AVVideoEncParams*
>
> LGTM.
Thanks for the review. So could someone help to push it?
>
> > --
> > 1.8.3.1
> >
> > ___
> > ffmpeg-devel mailing list
> > ffmpeg-devel@ffmpeg.org
> > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> >
> > To unsubscribe, visit link above, or email
> > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
>
> ___
> 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 v4]libavfilter/asrc_atone.c : generate algorithmic music
On Wed, Aug 19, 2020 at 6:12 PM Nicolas George wrote: > Ashutosh Pradhan (12020-08-18): > > Generate algorithmic music using riffs, lindenmayer systems, cellular > automaton and rhythm algorithms. > > Fixed the error that was causing segmentation fault in the previous > patch. > > Thanks. (But this last sentence should be below the --- in the mail, not > in the commit message.) > > I also notice that the output with the options given in example is much > more interesting than the default, and can justify the usefulness of the > filter. Good job! > > Two points: > > - Since it uses fluidsynth, the filter would probably better be called > like that, especially since it does not produces tones but almost-real > instrument sounds. Let us keep "atone" for a 100% internal > implementation. > > - I would really appreciate an answer to this question: > > >> Since you know the API best, could you say in a few words how hard it > >> would be to get rid of fluidsynth and use an internal synthesizer > >> instead? > I think it would be a bit difficult considering we have to read SoundFont files, read and write midi events, code for the sequencer, synth, etc. > > Regards, > > -- > Nicolas George > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v5 2/5] lavc/avs3: add AVS3 related definitions
At 2020-08-19 21:15:32, "Andreas Rheinhardt"
wrote:
>hwr...@126.com:
>> From: hwren
>>
>> Signed-off-by: hwren
>> ---
>> libavcodec/Makefile | 2 +
>> libavcodec/avs3.c | 95 +
>> libavcodec/avs3.h | 52 +
>> 3 files changed, 149 insertions(+)
>> create mode 100644 libavcodec/avs3.c
>> create mode 100644 libavcodec/avs3.h
>>
>> diff --git a/libavcodec/Makefile b/libavcodec/Makefile
>> index 3431ba2dca..e1e0c4629d 100644
>> --- a/libavcodec/Makefile
>> +++ b/libavcodec/Makefile
>> @@ -6,6 +6,7 @@ HEADERS = ac3_parser.h
>>\
>>avcodec.h \
>>avdct.h \
>>avfft.h \
>> + avs3.h\
>>bsf.h \
>>codec.h \
>>codec_desc.h \
>> @@ -32,6 +33,7 @@ OBJS = ac3_parser.o
>> \
>> avdct.o \
>> avpacket.o \
>> avpicture.o \
>> + avs3.o \
>> bitstream.o \
>> bitstream_filter.o \
>> bitstream_filters.o \
>> diff --git a/libavcodec/avs3.c b/libavcodec/avs3.c
>> new file mode 100644
>> index 00..8587e36def
>> --- /dev/null
>> +++ b/libavcodec/avs3.c
>> @@ -0,0 +1,95 @@
>> +/*
>> + * AVS3 related definition
>> + *
>> + * Copyright (C) 2020 Huiwen Ren,
>> + *
>> + * 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 "avs3.h"
>> +
>> +const AVRational ff_avs3_frame_rate_tab[16] = {
>> +{ 0, 0 }, // forbid
>> +{ 24000, 1001},
>> +{ 24 , 1 },
>> +{ 25 , 1 },
>> +{ 3, 1001},
>> +{ 30 , 1 },
>> +{ 50 , 1 },
>> +{ 6, 1001},
>> +{ 60 , 1 },
>> +{ 100 , 1 },
>> +{ 120 , 1 },
>> +{ 200 , 1 },
>> +{ 240 , 1 },
>> +{ 300 , 1 },
>> +{ 0, 0 }, // reserved
>> +{ 0, 0 } // reserved
>> +};
>> +
>> +const int ff_avs3_color_primaries_tab[10] = {
>> +AVCOL_PRI_RESERVED0 ,// 0
>> +AVCOL_PRI_BT709 ,// 1
>> +AVCOL_PRI_UNSPECIFIED ,// 2
>> +AVCOL_PRI_RESERVED,// 3
>> +AVCOL_PRI_BT470M ,// 4
>> +AVCOL_PRI_BT470BG ,// 5
>> +AVCOL_PRI_SMPTE170M ,// 6
>> +AVCOL_PRI_SMPTE240M ,// 7
>> +AVCOL_PRI_FILM,// 8
>> +AVCOL_PRI_BT2020 // 9
>> +};
>> +
>> +const enum AVPictureType ff_avs3_image_type[4] = {
>> +AV_PICTURE_TYPE_NONE,
>> +AV_PICTURE_TYPE_I,
>> +AV_PICTURE_TYPE_P,
>> +AV_PICTURE_TYPE_B
>> +};
>
>These two coincide with the values of the constants, so they could be
>removed.
Indeed. But I prefer to keep these mappings in case any side changes their
related tables,
and ensure the completeness of the group of definitions. These table may also
help to
check the validity of the type value and describe supported range in AVS3.
Thanks.
>
>> \ No newline at end of file
>
>This should be fixed.
Will be fixed. Thanks.
Regards,
Huiwen Ren
>
>- Andreas
>___
>ffmpeg-devel mailing list
>ffmpeg-devel@ffmpeg.org
>https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
>To unsubscribe, visit link above, or email
>ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe
[FFmpeg-devel] [PATCH v6 4/5] lavf/avs3dec: add raw avs3 demuxer
From: hwren
Signed-off-by: hbj
Signed-off-by: hwren
---
Changelog| 1 +
libavformat/Makefile | 1 +
libavformat/allformats.c | 1 +
libavformat/avs3dec.c| 68
libavformat/version.h| 2 +-
5 files changed, 72 insertions(+), 1 deletion(-)
create mode 100644 libavformat/avs3dec.c
diff --git a/Changelog b/Changelog
index 1efc768387..f70ed4927a 100644
--- a/Changelog
+++ b/Changelog
@@ -14,6 +14,7 @@ version :
- ADPCM Argonaut Games encoder
- Argonaut Games ASF muxer
- AV1 Low overhead bitstream format demuxer
+- AVS3 bitstream format demuxer
version 4.3:
diff --git a/libavformat/Makefile b/libavformat/Makefile
index cbb33fe37c..8ddab3aee5 100644
--- a/libavformat/Makefile
+++ b/libavformat/Makefile
@@ -122,6 +122,7 @@ OBJS-$(CONFIG_AVR_DEMUXER) += avr.o pcm.o
OBJS-$(CONFIG_AVS_DEMUXER) += avs.o voc_packet.o vocdec.o voc.o
OBJS-$(CONFIG_AVS2_DEMUXER) += davs2.o rawdec.o
OBJS-$(CONFIG_AVS2_MUXER)+= rawenc.o
+OBJS-$(CONFIG_AVS3_DEMUXER) += avs3dec.o rawdec.o
OBJS-$(CONFIG_BETHSOFTVID_DEMUXER) += bethsoftvid.o
OBJS-$(CONFIG_BFI_DEMUXER) += bfi.o
OBJS-$(CONFIG_BINK_DEMUXER) += bink.o
diff --git a/libavformat/allformats.c b/libavformat/allformats.c
index 0aa9dd7198..7f41c12d7c 100644
--- a/libavformat/allformats.c
+++ b/libavformat/allformats.c
@@ -84,6 +84,7 @@ extern AVInputFormat ff_avr_demuxer;
extern AVInputFormat ff_avs_demuxer;
extern AVInputFormat ff_avs2_demuxer;
extern AVOutputFormat ff_avs2_muxer;
+extern AVInputFormat ff_avs3_demuxer;
extern AVInputFormat ff_bethsoftvid_demuxer;
extern AVInputFormat ff_bfi_demuxer;
extern AVInputFormat ff_bintext_demuxer;
diff --git a/libavformat/avs3dec.c b/libavformat/avs3dec.c
new file mode 100644
index 00..a85f6f6c0b
--- /dev/null
+++ b/libavformat/avs3dec.c
@@ -0,0 +1,68 @@
+/*
+ * RAW AVS3-P2/IEEE1857.10 video demuxer
+ * Copyright (c) 2020 Zhenyu Wang
+ *Bingjie Han
+ *Huiwen Ren
+ *
+ * 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 "libavcodec/avs3.h"
+#include "libavcodec/internal.h"
+#include "avformat.h"
+#include "rawdec.h"
+
+static int avs3video_probe(const AVProbeData *p)
+{
+const uint8_t *ptr = p->buf, *end = p->buf + p->buf_size;
+uint32_t code = -1;
+uint8_t state = 0;
+int pic = 0, seq = 0, slice_pos = 0;
+int ret = 0;
+
+while (ptr < end) {
+ptr = avpriv_find_start_code(ptr, end, &code);
+state = code & 0xFF;
+if ((code & 0xFF00) == 0x100) {
+if (state < AVS3_SEQ_START_CODE) {
+if (code < slice_pos)
+return 0;
+slice_pos = code;
+} else {
+slice_pos = 0;
+}
+if (state == AVS3_SEQ_START_CODE) {
+seq++;
+if (*ptr != AVS3_PROFILE_BASELINE_MAIN && *ptr !=
AVS3_PROFILE_BASELINE_MAIN10)
+return 0;
+} else if (AVS3_ISPIC(state)) {
+pic++;
+} else if ((state == AVS3_UNDEF_START_CODE) ||
+ (state > AVS3_VIDEO_EDIT_CODE)) {
+return 0;
+}
+}
+}
+
+if (seq && pic && av_match_ext(p->filename, "avs3")) {
+ret = AVPROBE_SCORE_MAX;
+}
+
+return ret;
+}
+
+FF_DEF_RAWVIDEO_DEMUXER(avs3, "raw AVS3-P2/IEEE1857.10", avs3video_probe,
"avs3", AV_CODEC_ID_AVS3)
\ No newline at end of file
diff --git a/libavformat/version.h b/libavformat/version.h
index aa309ecc77..146db09d1b 100644
--- a/libavformat/version.h
+++ b/libavformat/version.h
@@ -32,7 +32,7 @@
// Major bumping may affect Ticket5467, 5421, 5451(compatibility with Chromium)
// Also please add any ticket numbers that you believe might be affected here
#define LIBAVFORMAT_VERSION_MAJOR 58
-#define LIBAVFORMAT_VERSION_MINOR 51
+#define LIBAVFORMAT_VERSION_MINOR 52
#define LIBAVFORMAT_VERSION_MICRO 100
#define LIBAVFORMAT_VERSION_INT AV_VERSION_INT(LIBAVFORMAT_VERSION_MAJOR, \
--
2.23.0.windows.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.
