[FFmpeg-devel] [PATCH] Add atsc_a53 dependency to h264/hevc decoders
As per ticket #8901 there is a compilation issue where there is an undefined reference when compiled with a minimal set of filters. This commit remedies that by ensuring decoders which have SEI parsers import the relevent caption object and hence functionality. --- libavcodec/Makefile | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/libavcodec/Makefile b/libavcodec/Makefile index 421aec984a..d255876d5e 100644 --- a/libavcodec/Makefile +++ b/libavcodec/Makefile @@ -96,7 +96,7 @@ OBJS-$(CONFIG_H264DSP) += h264dsp.o h264idct.o OBJS-$(CONFIG_H264PARSE) += h264_parse.o h2645_parse.o h264_ps.o OBJS-$(CONFIG_H264PRED)+= h264pred.o OBJS-$(CONFIG_H264QPEL)+= h264qpel.o -OBJS-$(CONFIG_HEVCPARSE) += hevc_parse.o h2645_parse.o hevc_ps.o hevc_sei.o hevc_data.o +OBJS-$(CONFIG_HEVCPARSE) += hevc_parse.o h2645_parse.o hevc_ps.o hevc_sei.o hevc_data.o atsc_a53.o OBJS-$(CONFIG_HPELDSP) += hpeldsp.o OBJS-$(CONFIG_HUFFMAN) += huffman.o OBJS-$(CONFIG_HUFFYUVDSP) += huffyuvdsp.o @@ -361,7 +361,7 @@ OBJS-$(CONFIG_H263_V4L2M2M_ENCODER)+= v4l2_m2m_enc.o OBJS-$(CONFIG_H264_DECODER)+= h264dec.o h264_cabac.o h264_cavlc.o \ h264_direct.o h264_loopfilter.o \ h264_mb.o h264_picture.o \ - h264_refs.o h264_sei.o \ + h264_refs.o h264_sei.o atsc_a53.o \ h264_slice.o h264data.o OBJS-$(CONFIG_H264_AMF_ENCODER)+= amfenc_h264.o OBJS-$(CONFIG_H264_CUVID_DECODER) += cuviddec.o @@ -1087,7 +1087,7 @@ OBJS-$(CONFIG_GIF_PARSER) += gif_parser.o OBJS-$(CONFIG_GSM_PARSER) += gsm_parser.o OBJS-$(CONFIG_H261_PARSER) += h261_parser.o OBJS-$(CONFIG_H263_PARSER) += h263_parser.o -OBJS-$(CONFIG_H264_PARSER) += h264_parser.o h264_sei.o h264data.o +OBJS-$(CONFIG_H264_PARSER) += h264_parser.o h264_sei.o h264data.o atsc_a53.o OBJS-$(CONFIG_HEVC_PARSER) += hevc_parser.o hevc_data.o OBJS-$(CONFIG_IPU_PARSER) += ipu_parser.o OBJS-$(CONFIG_JPEG2000_PARSER) += jpeg2000_parser.o -- 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".
Re: [FFmpeg-devel] [PATCH] Document community process
Hi there, The vote.ffmpeg.org URL appears to be down, happy to help however I can but just wanted to let you know. Some recommendations for changes might be: - "arbitrate" instead of "arbitrage" - potentially rename Technical Committee to Technical Conflicts Committee to avoid the confusion you documented around it's position describing technical direction - "make decisions" rather than "take decisions" - "re-elected" rather than "reelected" - "Decisions are made" rather than "Decisions are taken" - "They will consider the merits of all the positions, judge them and take a decision." might be phrased as "Decisions will be made on meritorious grounds". I would also consider stating whether those merits will be available for review by the public (if they are in the form of a mailing list or similar). Thank you for this work, I think that it will help this ffmpeg community thrive. *Chris Miceli* On Tue, Oct 6, 2020 at 8:12 AM Jean-Baptiste Kempf wrote: > General Assembly + Main Elections > --- > doc/dev_community/community.md | 60 ++ > 1 file changed, 60 insertions(+) > create mode 100644 doc/dev_community/community.md > > diff --git a/doc/dev_community/community.md > b/doc/dev_community/community.md > new file mode 100644 > index 00..4e17ce4d4f > --- /dev/null > +++ b/doc/dev_community/community.md > @@ -0,0 +1,60 @@ > +# FFmpeg project > + > +## Organisation > + > +The FFmpeg project is organized through a community working on global > consensus. > + > +Decisions are taken by the ensemble of active members, through voting and > are aided by two committees. > + > +## General Assembly > + > +The ensemble of active members is called the General Assembly (GA). > + > +The General Assembly is sovereign and legitimate for all its decisions > regarding the FFmpeg project. > + > +The General Assembly is made up of active contributors. > + > +Contributors are considered "active contributors" if they have pushed > more than 20 patches in the last 36 months in the main FFmpeg repository, > or if they have been voted in by the GA. > + > +Additional members are added to the General Assembly through a vote after > proposal by a member of the General Assembly. > + > +## Voting > + > +Voting is done using a ranked voting system, currently running on > https://vote.ffmpeg.org/ . > + > +Majority vote means more than 50% of the expressed ballots. > + > +## Technical Committee > + > +The Technical Committee (TC) is here to arbitrage and take decisions when > technical conflicts occur in the project. They will consider the merits of > all the positions, judge them and take a decision. > + > +The TC resolves technical conflicts but is not a technical steering > committee. > + > +Decisions by the TC are binding for all the contributors. > + > +Decisions taken by the TC can be re-opened after 1 year or by a majority > vote of the General Assembly, requested by one of the member of the GA. > + > +The TC is elected by the General Assembly for a duration of 1 year, and > is composed of 5 members. > +Members can be reelected if they wish. A majority vote in the General > Assembly can trigger a new election of the TC. > + > +The members of the TC can be elected from outside of the GA. > +Candidates for election can either be suggested or self-nominated. > + > +The conflict resolution process is detailed in the [resolution process] > document. > + > +## Community committee > + > +The Community Committee (CC) is here to arbitrage and take decisions when > inter-personal conflicts occur in the project. It will decide quickly and > take actions, for the sake of the project. > + > +The CC can remove privileges of offending members, including removal of > commit access and temporary ban from the community. > + > +Decisions taken by the CC can be re-opened after 1 year or by a majority > vote of the General Assembly. Indefinite bans from the community must be > confirmed by the General Assembly, in a majority vote. > + > +The CC is elected by the General Assembly for a duration of 1 year, and > is composed of 5 members. > +Members can be reelected if they wish. A majority vote in the General > Assembly can trigger a new election of the CC. > + > +The members of the CC can be elected from outside of the GA. > +Candidates for election can either be suggested or self-nominated. > + > +The CC is governed by and responsible for enforcing the Code of Conduct. > + > -- > 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".
[FFmpeg-devel] autofate system
Hi all, I have written a small system called autofate ( https://github.com/cmiceli/autofate) which is designed to basically run fate on every commit in master, ideally capturing and then reporting broken builds. It's written in rust so that it can run on a wide variety of platforms (I am currently testing on multiple architectures and multiple operating systems). Ideally, I'd love to get this reporting to the fate server and get other's running on various flavours of hardware where ffmpeg support is used widely. Right now I have it on 64bit and 32 bit rpi for example. What I was wondering is: 1. Do people think this is a step in the right direction? 2. How would we like to integrate with FATE server? 3. How would we like this to report failures? Email? 4. Any other features desired, I'm happy to add or accept pull requests. I look forward to hearing thoughts from the community, have a great day. Thanks, Chris Miceli ___ ffmpeg-devel mailing list ffmpeg-devel@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 8/8] RFC: editing HDR properties in H.265 metadata BSF
Hi, Was any additional progress made on this? Forgive me if I’m not finding it. Thanks, Kenny > On Aug 24, 2020, at 5:42 AM, Harry Mallon wrote: > > > > >> On 23 Aug 2020, at 23:33, Mark Thompson wrote: >> >> --- >> Setting HDR properties is a useful feature, but it's very unclear what we >> want it to actually look like to the user. Not all encoders and decoders >> support it, so it's essentially required that the implementation happen at >> the bitstream filter level so that we can support all codecs in the same >> way. This is several patches mashed together to invite comments on a >> bitstream filter approach. > > Mastering display data behaves similarly to color_range, color_primaries, > color_trc and colorspace in that some formats allow use to set it on frame, > some on the stream, some on the container but it is a property of the > contained pictures. I notice that color data can be set per frame and per > stream already and I don’t fully understand how these interact if converting > between data in frame (e.g HEVC SEI in stream in hev1) or data in header > (e.g. MOV mdcv tag or HEVC SEI in hvc1 format). > > Content light level data is a little different as it describes the stream in > which the image is contained and ffmpeg image filters would affect it. It it > however still a property of the whole stream. > > I guess my question is how to provide a good experience converting between > hvc1, hev1, prores in movs, av1 etc etc when the data has to be moved between > frame and stream. > >> >> […] >> >> Thoughts invited on any of this. > > As you point out MDCV and CLLI are relevant to so many codecs and container > formats that anything with hevc_ etc would be confusing as adapting configs > for different formats would require extra work (e.g. read from av1, write to > hevc bitstream filters). > > I an pretty new to FFMPEG to please ignore any of this that makes no sense :) > > Harry > > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 2/4] avcodec/apedec: properly calculate and store absolute value
Signed-off-by: Paul B Mahol
---
libavcodec/apedec.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavcodec/apedec.c b/libavcodec/apedec.c
index 273abe2490..aa4d8fa524 100644
--- a/libavcodec/apedec.c
+++ b/libavcodec/apedec.c
@@ -1311,7 +1311,7 @@ static void do_apply_filter(APEContext *ctx, int version,
APEFilter *f,
int32_t *data, int count, int order, int fracbits)
{
int res;
-int absres;
+unsigned absres;
while (count--) {
/* round fixedpoint scalar product */
@@ -1335,7 +1335,7 @@ static void do_apply_filter(APEContext *ctx, int version,
APEFilter *f,
/* Version 3.98 and later files */
/* Update the adaption coefficients */
-absres = res < 0 ? -(unsigned)res : res;
+absres = FFABS(res);
if (absres)
*f->adaptcoeffs = APESIGN(res) *
(8 << ((absres > f->avg * 3) + (absres >
f->avg * 4 / 3)));
--
2.17.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 4/4] avcodec/apedec: use ff_clz() instead of while loop
Signed-off-by: Paul B Mahol
---
libavcodec/apedec.c | 10 +++---
1 file changed, 3 insertions(+), 7 deletions(-)
diff --git a/libavcodec/apedec.c b/libavcodec/apedec.c
index 8fe7b5ee86..ea36247eb9 100644
--- a/libavcodec/apedec.c
+++ b/libavcodec/apedec.c
@@ -575,14 +575,10 @@ static inline int ape_decode_value_3990(APEContext *ctx,
APERice *rice)
base = range_decode_culfreq(ctx, pivot);
range_decode_update(ctx, 1, base);
} else {
-int base_hi = pivot, base_lo;
-int bbits = 0;
+int base_hi, base_lo;
+int bbits = 16 - ff_clz(pivot);
-while (base_hi & ~0x) {
-base_hi >>= 1;
-bbits++;
-}
-base_hi = range_decode_culfreq(ctx, base_hi + 1);
+base_hi = range_decode_culfreq(ctx, (pivot >> bbits) + 1);
range_decode_update(ctx, 1, base_hi);
base_lo = range_decode_culfreq(ctx, 1 << bbits);
range_decode_update(ctx, 1, base_lo);
--
2.17.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 1/4] avcodec/apedec: fix decoding insane files with recent versions
Signed-off-by: Paul B Mahol
---
libavcodec/apedec.c | 59 +++--
1 file changed, 46 insertions(+), 13 deletions(-)
diff --git a/libavcodec/apedec.c b/libavcodec/apedec.c
index c76c0509df..273abe2490 100644
--- a/libavcodec/apedec.c
+++ b/libavcodec/apedec.c
@@ -133,6 +133,21 @@ typedef struct APEPredictor {
unsigned int sample_pos;
} APEPredictor;
+typedef struct APEPredictor64 {
+int64_t *buf;
+
+int64_t lastA[2];
+
+int64_t filterA[2];
+int64_t filterB[2];
+
+uint64_t coeffsA[2][4]; ///< adaption coefficients
+uint64_t coeffsB[2][5]; ///< adaption coefficients
+int64_t historybuffer[HISTORY_SIZE + PREDICTOR_SIZE];
+
+unsigned int sample_pos;
+} APEPredictor64;
+
/** Decoder context */
typedef struct APEContext {
AVClass *class; ///< class for AVOptions
@@ -152,6 +167,7 @@ typedef struct APEContext {
uint32_t CRC_state; ///< accumulated CRC
int frameflags; ///< frame flags
APEPredictor predictor; ///< predictor used for final
reconstruction
+APEPredictor64 predictor64; ///< 64bit predictor used for
final reconstruction
int32_t *decoded_buffer;
int decoded_size;
@@ -789,13 +805,20 @@ static const int32_t initial_coeffs_3930[4] = {
360, 317, -109, 98
};
+static const int64_t initial_coeffs_3930_64bit[4] = {
+360, 317, -109, 98
+};
+
static void init_predictor_decoder(APEContext *ctx)
{
APEPredictor *p = >predictor;
+APEPredictor64 *p64 = >predictor64;
/* Zero the history buffers */
memset(p->historybuffer, 0, PREDICTOR_SIZE * sizeof(*p->historybuffer));
+memset(p64->historybuffer, 0, PREDICTOR_SIZE *
sizeof(*p64->historybuffer));
p->buf = p->historybuffer;
+p64->buf = p64->historybuffer;
/* Initialize and zero the coefficients */
if (ctx->fileversion < 3930) {
@@ -813,8 +836,11 @@ static void init_predictor_decoder(APEContext *ctx)
} else {
memcpy(p->coeffsA[0], initial_coeffs_3930,
sizeof(initial_coeffs_3930));
memcpy(p->coeffsA[1], initial_coeffs_3930,
sizeof(initial_coeffs_3930));
+memcpy(p64->coeffsA[0], initial_coeffs_3930_64bit,
sizeof(initial_coeffs_3930_64bit));
+memcpy(p64->coeffsA[1], initial_coeffs_3930_64bit,
sizeof(initial_coeffs_3930_64bit));
}
memset(p->coeffsB, 0, sizeof(p->coeffsB));
+memset(p64->coeffsB, 0, sizeof(p64->coeffsB));
if (ctx->fileversion < 3930) {
memcpy(p->coeffsB[0], initial_coeffs_b_3800,
sizeof(initial_coeffs_b_3800));
@@ -826,7 +852,13 @@ static void init_predictor_decoder(APEContext *ctx)
p->filterB[0] = p->filterB[1] = 0;
p->lastA[0] = p->lastA[1] = 0;
+p64->filterA[0] = p64->filterA[1] = 0;
+p64->filterB[0] = p64->filterB[1] = 0;
+p64->lastA[0] = p64->lastA[1] = 0;
+
p->sample_pos = 0;
+
+p64->sample_pos = 0;
}
/** Get inverse sign of integer (-1 for positive, 1 for negative and 0 for
zero) */
@@ -1132,16 +1164,17 @@ static void predictor_decode_mono_3930(APEContext *ctx,
int count)
}
}
-static av_always_inline int predictor_update_filter(APEPredictor *p,
+static av_always_inline int predictor_update_filter(APEPredictor64 *p,
const int decoded, const
int filter,
const int delayA, const
int delayB,
const int adaptA, const
int adaptB)
{
-int32_t predictionA, predictionB, sign;
+int64_t predictionA, predictionB;
+int32_t sign;
p->buf[delayA] = p->lastA[filter];
p->buf[adaptA] = APESIGN(p->buf[delayA]);
-p->buf[delayA - 1] = p->buf[delayA] - (unsigned)p->buf[delayA - 1];
+p->buf[delayA - 1] = p->buf[delayA] - (uint64_t)p->buf[delayA - 1];
p->buf[adaptA - 1] = APESIGN(p->buf[delayA - 1]);
predictionA = p->buf[delayA] * p->coeffsA[filter][0] +
@@ -1150,9 +1183,9 @@ static av_always_inline int
predictor_update_filter(APEPredictor *p,
p->buf[delayA - 3] * p->coeffsA[filter][3];
/* Apply a scaled first-order filter compression */
-p->buf[delayB] = p->filterA[filter ^ 1] - ((int)(p->filterB[filter] *
31U) >> 5);
+p->buf[delayB] = p->filterA[filter ^ 1] -
((int64_t)(p->filterB[filter] * 31ULL) >> 5);
p->buf[adaptB] = APESIGN(p->buf[delayB]);
-p->buf[delayB - 1] = p->buf[delayB] - (unsigned)p->buf[delayB - 1];
+p->buf[delayB - 1] = p->buf[delayB] - (uint64_t)p->buf[delayB - 1];
p->buf[adaptB - 1] = APESIGN(p->buf[delayB - 1]);
p->filterB[filter] = p->filterA[filter ^ 1];
@@ -1162,8 +1195,8 @@ static av_always_inline int
predictor_update_filter(APEPredictor *p,
p->buf[delayB - 3] * p->coeffsB[filter][3] +
p->buf[delayB - 4] *
[FFmpeg-devel] [PATCH 3/4] avcodec/apedec: use proper macro and type for pivot variable
Signed-off-by: Paul B Mahol
---
libavcodec/apedec.c | 8 +++-
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/libavcodec/apedec.c b/libavcodec/apedec.c
index aa4d8fa524..8fe7b5ee86 100644
--- a/libavcodec/apedec.c
+++ b/libavcodec/apedec.c
@@ -559,12 +559,10 @@ static inline int ape_decode_value_3900(APEContext *ctx,
APERice *rice)
static inline int ape_decode_value_3990(APEContext *ctx, APERice *rice)
{
-unsigned int x, overflow;
-int base, pivot;
+unsigned int x, overflow, pivot;
+int base;
-pivot = rice->ksum >> 5;
-if (pivot == 0)
-pivot = 1;
+pivot = FFMAX(rice->ksum >> 5, 1);
overflow = range_get_symbol(ctx, counts_3980, counts_diff_3980);
--
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/7] mpegvideo: use the AVVideoEncParams API for exporting QP tables
On Mon, Oct 05, 2020 at 10:40:59AM +0200, Anton Khirnov wrote: > Quoting Michael Niedermayer (2020-10-03 20:26:20) > > On Fri, Oct 02, 2020 at 08:03:25PM +0200, Anton Khirnov wrote: > > > Do it only when requested with the AV_CODEC_EXPORT_DATA_VIDEO_ENC_PARAMS > > > flag. > > > > > > Drop previous code using the long-deprecated AV_FRAME_DATA_QP_TABLE* > > > API. Temporarily disable fate-filter-pp, fate-filter-pp7, > > > fate-filter-spp. They will be reenabled once these filters are converted > > > in following commits. > > > > This patchset updates pp, pp7, spp, fspp, qp, codecview > > it seems uspp is missed (as it lacks a fate test i guess) > > No, I skipped uspp because it uses more deprecated APIs than just the QP > table one. Specifically, the old encoding API and > AVCodecContext.coded_frame. right, i had forgotten about that consider my uspp review comment to be withdrawn for now. [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Dictatorship naturally arises out of democracy, and the most aggravated form of tyranny and slavery out of the most extreme liberty. -- Plato signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 1/3] avcodec/h2645_parse: Limit initial skipped_bytes_pos_size to nal size / 16
On 10/5/2020 6:43 PM, Michael Niedermayer wrote: > On Mon, Oct 05, 2020 at 01:30:07AM -0300, James Almer wrote: >> On 10/4/2020 6:02 PM, James Almer wrote: >>> On 10/4/2020 5:57 PM, Michael Niedermayer wrote: On Sun, Oct 04, 2020 at 05:04:05PM -0300, James Almer wrote: > On 10/4/2020 4:41 PM, Michael Niedermayer wrote: >> Fixes: OOM >> Fixes: >> 23817/clusterfuzz-testcase-minimized-ffmpeg_BSF_H264_METADATA_fuzzer-6300869057576960 >> >> Found-by: continuous fuzzing process >> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg >> Signed-off-by: Michael Niedermayer >> --- >> libavcodec/h2645_parse.c | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/libavcodec/h2645_parse.c b/libavcodec/h2645_parse.c >> index 0f98b49fbe..61105a6eb5 100644 >> --- a/libavcodec/h2645_parse.c >> +++ b/libavcodec/h2645_parse.c >> @@ -467,7 +467,7 @@ int ff_h2645_packet_split(H2645Packet *pkt, const >> uint8_t *buf, int length, >> memset(pkt->nals + pkt->nals_allocated, 0, >> sizeof(*pkt->nals)); >> >> nal = >nals[pkt->nb_nals]; >> -nal->skipped_bytes_pos_size = 1024; // initial buffer size >> +nal->skipped_bytes_pos_size = FFMIN(1024, >> 1+(extract_length>>4)); // initial buffer size > > Why is there even an initial buffer? Why not just let > ff_h2645_extract_rbsp() allocate it when needed? i wondered that too and assumed it was done that way to avoid spending cpu cycles on reallocations later >>> >>> Many streams don't need to escape bytes, so for those, allocating >>> anything at all is a waste. And IMO by using av_fast_realloc() in >>> ff_h2645_extract_rbsp() there's no need for a big enough initial buffer >>> either. >> >> On second thought, even if most av_fast_realloc() calls will be no-ops, >> they may end up being way too many to the point the current behavior >> would be more efficient. >> >> Does moving the allocation of the initial buffer to >> ff_h2645_extract_rbsp() also help with this sample? I assume it's one >> where it generates an absurd amount of NAL units in the packet, but most >> would probably be small enough that they will not really contain bytes >> that need to be escaped, and as such not require a skipped_bytes_pos buffer. > > your variant below works too, yes What do you think about setting instead nal->skipped_bytes_pos_size to length / 3 when it needs to be resized? The max possible amount of bytes it will skip/strip per NAL is one third of the total NAL size. It's probably better than my previous suggestion, as it still removes the initial buffer outside of ff_h2645_extract_rbsp() and also avoids the unconditional check for nal->skipped_bytes_pos_size == 0 and does not duplicate the buffer's size on each realloc. > the fuzzer testcase is a gazzilion of 1byte NAL units IIRC > > thx > > [...] > > > ___ > ffmpeg-devel mailing list > ffmpeg-devel@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/7] lavfi/vf_spp: convert to the video_enc_params API
On Mon, Oct 05, 2020 at 10:26:24AM +0200, Anton Khirnov wrote:
> Quoting Michael Niedermayer (2020-10-03 20:23:02)
> > On Fri, Oct 02, 2020 at 08:03:28PM +0200, Anton Khirnov wrote:
> > > ---
> > > libavfilter/Makefile| 2 +-
> > > libavfilter/vf_spp.c| 57 -
> > > libavfilter/vf_spp.h| 3 +-
> > > tests/fate/filter-video.mak | 4 +--
> > > 4 files changed, 29 insertions(+), 37 deletions(-)
> > >
> > > diff --git a/libavfilter/Makefile b/libavfilter/Makefile
> > > index d20f2937b6..2669d7b84b 100644
> > > --- a/libavfilter/Makefile
> > > +++ b/libavfilter/Makefile
> > > @@ -404,7 +404,7 @@ OBJS-$(CONFIG_SOBEL_FILTER) +=
> > > vf_convolution.o
> > > OBJS-$(CONFIG_SOBEL_OPENCL_FILTER) += vf_convolution_opencl.o
> > > opencl.o \
> > > opencl/convolution.o
> > > OBJS-$(CONFIG_SPLIT_FILTER) += split.o
> > > -OBJS-$(CONFIG_SPP_FILTER)+= vf_spp.o
> > > +OBJS-$(CONFIG_SPP_FILTER)+= vf_spp.o qp_table.o
> > > OBJS-$(CONFIG_SR_FILTER) += vf_sr.o
> > > OBJS-$(CONFIG_SSIM_FILTER) += vf_ssim.o framesync.o
> > > OBJS-$(CONFIG_STEREO3D_FILTER) += vf_stereo3d.o
> > > diff --git a/libavfilter/vf_spp.c b/libavfilter/vf_spp.c
> > > index 4bcc6429e0..2eb383be03 100644
> > > --- a/libavfilter/vf_spp.c
> > > +++ b/libavfilter/vf_spp.c
> > > @@ -36,6 +36,7 @@
> > > #include "libavutil/opt.h"
> > > #include "libavutil/pixdesc.h"
> > > #include "internal.h"
> > > +#include "qp_table.h"
> > > #include "vf_spp.h"
> > >
> > > enum mode {
> > > @@ -289,7 +290,7 @@ static void filter(SPPContext *p, uint8_t *dst,
> > > uint8_t *src,
> > > } else{
> > > const int qps = 3 + is_luma;
> > > qp = qp_table[(FFMIN(x, width - 1) >> qps) + (FFMIN(y,
> > > height - 1) >> qps) * qp_stride];
> > > -qp = FFMAX(1, ff_norm_qscale(qp, p->qscale_type));
> > > +qp = FFMAX(1, ff_norm_qscale(qp, FF_QSCALE_TYPE_MPEG2));
> >
> > wouldnt this break the cases where qscale_type is not FF_QSCALE_TYPE_MPEG2 ?
>
> There should be no such cases - in the new API, only TYPE_MPEG2 exists
> (disregarding newer codecs that were not supported by this filter
> anyway).
before the patch the code was intended to convert the quantization step size
used in the codec to the same scale as the filter used. disregarding if the
codec was 8x8 dct based. In fact spp should not require the input to be 8x8 dct
based at all, why should it? It uses the DCT as a means to favor real images
and remove "noise" that is not part of real images. It should for example also
work if a image has blocking artifacts that look like hexagons or triangles
I never tried but H264 with disabled loop filter should benefit from spp in
terms of subjective quality as long as the filter strength is set appropriately
That is for streams where the bitrate is low enough to see artifacts
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
The real ebay dictionary, page 1
"Used only once"- "Some unspecified defect prevented a second use"
"In good condition" - "Can be repaird by experienced expert"
"As is" - "You wouldnt want it even if you were payed for it, if you knew ..."
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/3] avcodec/h2645_parse: Limit initial skipped_bytes_pos_size to nal size / 16
On Mon, Oct 05, 2020 at 01:30:07AM -0300, James Almer wrote: > On 10/4/2020 6:02 PM, James Almer wrote: > > On 10/4/2020 5:57 PM, Michael Niedermayer wrote: > >> On Sun, Oct 04, 2020 at 05:04:05PM -0300, James Almer wrote: > >>> On 10/4/2020 4:41 PM, Michael Niedermayer wrote: > Fixes: OOM > Fixes: > 23817/clusterfuzz-testcase-minimized-ffmpeg_BSF_H264_METADATA_fuzzer-6300869057576960 > > Found-by: continuous fuzzing process > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg > Signed-off-by: Michael Niedermayer > --- > libavcodec/h2645_parse.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/libavcodec/h2645_parse.c b/libavcodec/h2645_parse.c > index 0f98b49fbe..61105a6eb5 100644 > --- a/libavcodec/h2645_parse.c > +++ b/libavcodec/h2645_parse.c > @@ -467,7 +467,7 @@ int ff_h2645_packet_split(H2645Packet *pkt, const > uint8_t *buf, int length, > memset(pkt->nals + pkt->nals_allocated, 0, > sizeof(*pkt->nals)); > > nal = >nals[pkt->nb_nals]; > -nal->skipped_bytes_pos_size = 1024; // initial buffer size > +nal->skipped_bytes_pos_size = FFMIN(1024, > 1+(extract_length>>4)); // initial buffer size > >>> > >>> Why is there even an initial buffer? Why not just let > >>> ff_h2645_extract_rbsp() allocate it when needed? > >> > >> i wondered that too and assumed it was done that way to avoid spending > >> cpu cycles on reallocations later > > > > Many streams don't need to escape bytes, so for those, allocating > > anything at all is a waste. And IMO by using av_fast_realloc() in > > ff_h2645_extract_rbsp() there's no need for a big enough initial buffer > > either. > > On second thought, even if most av_fast_realloc() calls will be no-ops, > they may end up being way too many to the point the current behavior > would be more efficient. > > Does moving the allocation of the initial buffer to > ff_h2645_extract_rbsp() also help with this sample? I assume it's one > where it generates an absurd amount of NAL units in the packet, but most > would probably be small enough that they will not really contain bytes > that need to be escaped, and as such not require a skipped_bytes_pos buffer. your variant below works too, yes the fuzzer testcase is a gazzilion of 1byte NAL units IIRC thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB No great genius has ever existed without some touch of madness. -- Aristotle signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] Document community process
General Assembly + Main Elections --- doc/dev_community/community.md | 60 ++ 1 file changed, 60 insertions(+) create mode 100644 doc/dev_community/community.md diff --git a/doc/dev_community/community.md b/doc/dev_community/community.md new file mode 100644 index 00..4e17ce4d4f --- /dev/null +++ b/doc/dev_community/community.md @@ -0,0 +1,60 @@ +# FFmpeg project + +## Organisation + +The FFmpeg project is organized through a community working on global consensus. + +Decisions are taken by the ensemble of active members, through voting and are aided by two committees. + +## General Assembly + +The ensemble of active members is called the General Assembly (GA). + +The General Assembly is sovereign and legitimate for all its decisions regarding the FFmpeg project. + +The General Assembly is made up of active contributors. + +Contributors are considered "active contributors" if they have pushed more than 20 patches in the last 36 months in the main FFmpeg repository, or if they have been voted in by the GA. + +Additional members are added to the General Assembly through a vote after proposal by a member of the General Assembly. + +## Voting + +Voting is done using a ranked voting system, currently running on https://vote.ffmpeg.org/ . + +Majority vote means more than 50% of the expressed ballots. + +## Technical Committee + +The Technical Committee (TC) is here to arbitrage and take decisions when technical conflicts occur in the project. They will consider the merits of all the positions, judge them and take a decision. + +The TC resolves technical conflicts but is not a technical steering committee. + +Decisions by the TC are binding for all the contributors. + +Decisions taken by the TC can be re-opened after 1 year or by a majority vote of the General Assembly, requested by one of the member of the GA. + +The TC is elected by the General Assembly for a duration of 1 year, and is composed of 5 members. +Members can be reelected if they wish. A majority vote in the General Assembly can trigger a new election of the TC. + +The members of the TC can be elected from outside of the GA. +Candidates for election can either be suggested or self-nominated. + +The conflict resolution process is detailed in the [resolution process] document. + +## Community committee + +The Community Committee (CC) is here to arbitrage and take decisions when inter-personal conflicts occur in the project. It will decide quickly and take actions, for the sake of the project. + +The CC can remove privileges of offending members, including removal of commit access and temporary ban from the community. + +Decisions taken by the CC can be re-opened after 1 year or by a majority vote of the General Assembly. Indefinite bans from the community must be confirmed by the General Assembly, in a majority vote. + +The CC is elected by the General Assembly for a duration of 1 year, and is composed of 5 members. +Members can be reelected if they wish. A majority vote in the General Assembly can trigger a new election of the CC. + +The members of the CC can be elected from outside of the GA. +Candidates for election can either be suggested or self-nominated. + +The CC is governed by and responsible for enforcing the Code of Conduct. + -- 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".
Re: [FFmpeg-devel] [PATCH 2/3] tools/target_dec_fuzzer: Adjust threshold for opus
On Sun, Oct 04, 2020 at 05:09:28PM -0300, James Almer wrote: > On 10/4/2020 4:41 PM, Michael Niedermayer wrote: > > Fixes: Timeout (12sec -> 3sec) > > Fixes: > > 24549/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_LIBOPUS_fuzzer-6211170349088768 > > codec id, or decoder? The testcase used libopus > And if the latter, why is an external library > based decoder being fuzzed? iam not sure but then why not ? we have found issues in external libs that way previously and we might find issues in our lib wrapper. thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB "You are 36 times more likely to die in a bathtub than at the hands of a terrorist. Also, you are 2.5 times more likely to become a president and 2 times more likely to become an astronaut, than to die in a terrorist attack." -- Thoughty2 signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avcodec/h264_slice: use av_buffer_replace() to simplify code
On 10/5/2020 5:49 AM, Anton Khirnov wrote: > Quoting James Almer (2020-09-28 17:02:00) >> Based on eff289ce9f030f023e218ee7ce354d4f0e035b6d. >> >> Signed-off-by: James Almer >> --- >> libavcodec/h264_slice.c | 34 -- >> 1 file changed, 12 insertions(+), 22 deletions(-) > > Looks good Applied, thanks. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v4 0/9] avformat: wav-s337m support + new probe_stream option
On Mon, Oct 5, 2020 at 6:23 AM Nicolas Gaullier wrote: > dolby_e is a "professional" codec, it is not used for distribution and not > supported by end user chips, so the most common formats are : > - contribution: mpegts (or dvb for satt etc.) with s302m data -> s337m (this > could be interesting for ffmpeg to support it) FYI: I've got patches to output AC-3 as S337 over the decklink SDI output. However doing Dolby-E is harder because the start of the frames are expected to be aligned with the start of the video frame (i.e. typically against a VREF signal). I haven't figured out how to do this reliably with the decklink APIs, but it might be possible. Capture of S337 using decklink is a bit easier, although it means reproducing a bunch of the probing/detection logic found in the other avformat demuxes. Passing the data through to the s337m avformat module might also be an option but it's harder since the s337m module expects AVIOBufs which is more difficult to provide. Devin -- Devin Heitmueller, Senior Software Engineer LTN Global Communications o: +1 (301) 363-1001 w: https://ltnglobal.com e: devin.heitmuel...@ltnglobal.com ___ ffmpeg-devel mailing list ffmpeg-devel@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] libavcodec/ac3tab: rename ff_ac3_sample_rate_tab to avpriv_ac3_sample_rate_tab so that it can be used in libavformat
On 10/5/2020 7:48 AM, Nachiket Tarate wrote: > > > > From: ffmpeg-devel on behalf of Anton > Khirnov > Sent: Monday, October 5, 2020 1:50 PM > To: FFmpeg development discussions and patches > Subject: Re: [FFmpeg-devel] [PATCH 2/2] libavcodec/ac3tab: rename > ff_ac3_sample_rate_tab to avpriv_ac3_sample_rate_tab so that it can be used > in libavformat > > Quoting Nachiket Tarate (2020-10-04 16:35:09) >> This will be used by HLS demuxer to parse EC3SpecificBox (dec3) during >> SAMPLE-AES decryption. >> >> Signed-off-by: Nachiket Tarate > > Since the table is so small, it seems preferable to duplicate it in > libavformat than add eat another private symbol. > > Private symbols are evil and should not exist. > > -- > Anton Khirnov > > @Anton Khirnov > In the first version of the patch, I had implemented avpriv_eac3_parse_dec3() > function in ac3_parser.c to avoid sharing or duplication of table across the > libraries. I changed that implementation based on James Almer > 's review comments. > > @James Almer > What is your opinion about Anton Khirnov 's review > comments ? I'm fine with duplicating it. It's true it's small enough for it. I had not looked at the table in question when i suggested to share it. In general, if you can avoid exposing functions and tables using the avpriv_ prefix then that's always preferable, but sometimes it can't be done. > > -- > Nachiket Tarate > ___ > ffmpeg-devel mailing list > ffmpeg-devel@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 2/2] libavcodec/ac3tab: rename ff_ac3_sample_rate_tab to avpriv_ac3_sample_rate_tab so that it can be used in libavformat
Nachiket Tarate (12020-10-05): > What is your opinion about Anton Khirnov 's review > comments ? The only way forward is to merge the libraries. The split of shared objects brings all kinds of issues, including the problem of avpriv symbols, and no practical benefit. 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/2] libavcodec/ac3tab: rename ff_ac3_sample_rate_tab to avpriv_ac3_sample_rate_tab so that it can be used in libavformat
From: ffmpeg-devel on behalf of Anton Khirnov Sent: Monday, October 5, 2020 1:50 PM To: FFmpeg development discussions and patches Subject: Re: [FFmpeg-devel] [PATCH 2/2] libavcodec/ac3tab: rename ff_ac3_sample_rate_tab to avpriv_ac3_sample_rate_tab so that it can be used in libavformat Quoting Nachiket Tarate (2020-10-04 16:35:09) > This will be used by HLS demuxer to parse EC3SpecificBox (dec3) during > SAMPLE-AES decryption. > > Signed-off-by: Nachiket Tarate Since the table is so small, it seems preferable to duplicate it in libavformat than add eat another private symbol. Private symbols are evil and should not exist. -- Anton Khirnov @Anton Khirnov In the first version of the patch, I had implemented avpriv_eac3_parse_dec3() function in ac3_parser.c to avoid sharing or duplication of table across the libraries. I changed that implementation based on James Almer 's review comments. @James Almer What is your opinion about Anton Khirnov 's review comments ? -- Nachiket Tarate ___ ffmpeg-devel mailing list ffmpeg-devel@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 4/9] avformat/s337m: New ff_s337m_probe()
>> Similar to ff_spdif_probe() with just an additional checking of the >> bit resolution of the container as it may be 16 or 24 for s337m. > >Sorry if I miss something: >Why is the new function part of s337m.c? There is a call to static s337m_get_offset_and_codec() which is in s337m.c. The muxer wavdec.c is the first to support it, but other muxers may come in the future, so the code must be shared. And at the end, I don't see the point to possibly create a new s337mdec.c or so ? Nicolas ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v4 0/9] avformat: wav-s337m support + new probe_stream option
>> Because of the dependencies, I had to group all the patches in a serie, but >> they are 3 functional parts : >> * patch 1 is necessary to fix dolby_e pts that will be part of the >> test in patch 8 >> * patch 2,3,4,5,6,7,8 : s337m support in wav >> this is a rework of a precedent serie >> (https://patchwork.ffmpeg.org/project/ffmpeg/list/?series=106) > >Sorry if this is not related at all but isn't dolby-e mostly found in some dvb >streams? dolby_e is a "professional" codec, it is not used for distribution and not supported by end user chips, so the most common formats are : - contribution: mpegts (or dvb for satt etc.) with s302m data -> s337m (this could be interesting for ffmpeg to support it) - broadcast muxers: mxf, mov, gxf, lxf : in s337m, within stereo tracks or most commonly sadly split into mono tracks (limited support for a simple case such as mxf stereo would still be welcome). There is also a newer form with AMWA-AS 11 with audio samples not encoded, but with single separated audio metadata bistream in VANC : this is not strictly "dolby E", just the metadata part of it (dialnorm et.), and currently dolby_e.c does not support parsing these metadata. - wav >> * patch 9 : AVOption to disable codec auto-detect : it seems it is a >> general request from many users, and it is also critical here for dolby_e as >> many broadcasters will still need to just pass-through dolby_e data as they >> already do. >> Thus, the patchset 2,3,4,5,6,7 should not be applied without the last patch >> 9 applied quickly behind... > >As said, this surprises me, please elaborate. > >Carl Eugen Most of the time, broadcast users just want to pass-through dolby E: typically they mux m2v/wav essence files to an mxf file. Downstream broadcast hardwares or applications can probe the stream and transcode the detected dolby_e stream to an ac-3 stream which can be distributed. Without an option to disable dolby_e stream probing, it would be strictly impossible to do this. In the future, one can imagine that broadcast muxers mxf/wav/.. would be able to support dolby_e by automatically submuxing to s337m with correct guard-band/phase, and that could be interesting to repair a bad s337m submux, but this is a long way... Apart from that, it seems some users would like to be able to disable stream probing, so it seems it is an opportunity to add this AVOption right now. Nicolas ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avcodec/h264_slice: use av_buffer_replace() to simplify code
Quoting James Almer (2020-09-28 17:02:00) > Based on eff289ce9f030f023e218ee7ce354d4f0e035b6d. > > Signed-off-by: James Almer > --- > libavcodec/h264_slice.c | 34 -- > 1 file changed, 12 insertions(+), 22 deletions(-) Looks good -- Anton Khirnov ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 1/7] mpegvideo: use the AVVideoEncParams API for exporting QP tables
Quoting Michael Niedermayer (2020-10-03 20:26:20) > On Fri, Oct 02, 2020 at 08:03:25PM +0200, Anton Khirnov wrote: > > Do it only when requested with the AV_CODEC_EXPORT_DATA_VIDEO_ENC_PARAMS > > flag. > > > > Drop previous code using the long-deprecated AV_FRAME_DATA_QP_TABLE* > > API. Temporarily disable fate-filter-pp, fate-filter-pp7, > > fate-filter-spp. They will be reenabled once these filters are converted > > in following commits. > > This patchset updates pp, pp7, spp, fspp, qp, codecview > it seems uspp is missed (as it lacks a fate test i guess) No, I skipped uspp because it uses more deprecated APIs than just the QP table one. Specifically, the old encoding API and AVCodecContext.coded_frame. Given that: - coded_frame is dropped without replacement - uspp is EXTREMELY slow - we have several other very similar filters I have to wonder whether continued maintenance of uspp makes sense. So I suggest that either - someone cares enough about this filter to maintain it (i.e. convert it to non-deprecated APIs) - we drop it -- Anton Khirnov ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v4 3/9] avformat/s337m: Consider container bit resolution
lör 2020-10-03 klockan 00:23 +0200 skrev Nicolas Gaullier:
> +if (container_word_bits && !(container_word_bits == 16 && word_bits ==
> 16) && !(container_word_bits == 24 && word_bits == 20) &&
> !(container_word_bits == 24 && word_bits == 24))
> +return AVERROR_INVALIDDATA;
>
That if line is overly long. Maybe reformat it a bit like
if (container_word_bits &&
!(container_word_bits == 16 && word_bits == 16) &&
!(container_word_bits == 24 && word_bits == 20) &&
!(container_word_bits == 24 && word_bits == 24)) {
return AVERROR_INVALIDDATA;
}
The rest of the patch looks OK
/Tomas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avformat/mpegts: ensure seekback for small probesize
On Sun, 4 Oct 2020, Andriy Gelman wrote: From: Andriy Gelman get_packet_size() may read upto PROBE_PACKET_MAX_BUF bytes, which may be larger than probesize. Signed-off-by: Andriy Gelman --- An alternative could be to make sure we don't read more than s->probesize bytes in get_packet_size(), but because this function is also called during resync (midstream) limiting the read bytes may not be the best option. libavformat/mpegts.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libavformat/mpegts.c b/libavformat/mpegts.c index 50d4d5e9bc..019b627d51 100644 --- a/libavformat/mpegts.c +++ b/libavformat/mpegts.c @@ -3054,7 +3054,7 @@ static int mpegts_read_header(AVFormatContext *s) s->internal->prefer_codec_framerate = 1; -if (ffio_ensure_seekback(pb, probesize) < 0) +if (ffio_ensure_seekback(pb, FFMAX(probesize, PROBE_PACKET_MAX_BUF)) < 0) av_log(s, AV_LOG_WARNING, "Failed to allocate buffers for seekback\n"); I posted a similar patch not long ago which is I think better because it also takes into account ts->resync_size. https://patchwork.ffmpeg.org/project/ffmpeg/patch/20200929211021.25030-4-...@passwd.hu/ Regards, 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/9] avformat/aviobuf: check if requested seekback buffer is already read
On Sun, 4 Oct 2020, Andriy Gelman wrote:
Hi Marton,
On Tue, 29. Sep 23:10, Marton Balint wrote:
Existing code did not check if the requested seekback buffer is
already read entirely. In this case, nothing has to be done to guarantee
seekback.
Signed-off-by: Marton Balint
---
libavformat/aviobuf.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/libavformat/aviobuf.c b/libavformat/aviobuf.c
index 9675425349..d94be478ac 100644
--- a/libavformat/aviobuf.c
+++ b/libavformat/aviobuf.c
@@ -999,6 +999,9 @@ int ffio_ensure_seekback(AVIOContext *s, int64_t buf_size)
int filled = s->buf_end - s->buffer;
ptrdiff_t checksum_ptr_offset = s->checksum_ptr ? s->checksum_ptr -
s->buffer : -1;
+if (buf_size <= s->buf_end - s->buf_ptr)
+return 0;
+
buf_size += s->buf_ptr - s->buffer + max_buffer_size;
if (buf_size < filled || s->seekable || !s->read_packet)
I was testing this set, and saw commit 53c25ee0736. It discards buffered data by
resetting s->{buf_ptr,buf_end} when we need to read more data.
Maybe I missed something, but wouldn't this mean that seekback no longer works
if
fill_buffer() is called in avio_read_partial().. so defeating the purpose of
ffio_ensure_seekback()?
I think you are right. It looks like that commit is not needed after
2ca48e466675a8a3630061cd2c15325eab8eda97, so probably it should be
reverted now to unbreak ffio_ensure_seekback().
Regards,
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 4/7] lavfi/vf_spp: convert to the video_enc_params API
Quoting Michael Niedermayer (2020-10-03 20:23:02)
> On Fri, Oct 02, 2020 at 08:03:28PM +0200, Anton Khirnov wrote:
> > ---
> > libavfilter/Makefile| 2 +-
> > libavfilter/vf_spp.c| 57 -
> > libavfilter/vf_spp.h| 3 +-
> > tests/fate/filter-video.mak | 4 +--
> > 4 files changed, 29 insertions(+), 37 deletions(-)
> >
> > diff --git a/libavfilter/Makefile b/libavfilter/Makefile
> > index d20f2937b6..2669d7b84b 100644
> > --- a/libavfilter/Makefile
> > +++ b/libavfilter/Makefile
> > @@ -404,7 +404,7 @@ OBJS-$(CONFIG_SOBEL_FILTER) +=
> > vf_convolution.o
> > OBJS-$(CONFIG_SOBEL_OPENCL_FILTER) += vf_convolution_opencl.o
> > opencl.o \
> > opencl/convolution.o
> > OBJS-$(CONFIG_SPLIT_FILTER) += split.o
> > -OBJS-$(CONFIG_SPP_FILTER)+= vf_spp.o
> > +OBJS-$(CONFIG_SPP_FILTER)+= vf_spp.o qp_table.o
> > OBJS-$(CONFIG_SR_FILTER) += vf_sr.o
> > OBJS-$(CONFIG_SSIM_FILTER) += vf_ssim.o framesync.o
> > OBJS-$(CONFIG_STEREO3D_FILTER) += vf_stereo3d.o
> > diff --git a/libavfilter/vf_spp.c b/libavfilter/vf_spp.c
> > index 4bcc6429e0..2eb383be03 100644
> > --- a/libavfilter/vf_spp.c
> > +++ b/libavfilter/vf_spp.c
> > @@ -36,6 +36,7 @@
> > #include "libavutil/opt.h"
> > #include "libavutil/pixdesc.h"
> > #include "internal.h"
> > +#include "qp_table.h"
> > #include "vf_spp.h"
> >
> > enum mode {
> > @@ -289,7 +290,7 @@ static void filter(SPPContext *p, uint8_t *dst, uint8_t
> > *src,
> > } else{
> > const int qps = 3 + is_luma;
> > qp = qp_table[(FFMIN(x, width - 1) >> qps) + (FFMIN(y,
> > height - 1) >> qps) * qp_stride];
> > -qp = FFMAX(1, ff_norm_qscale(qp, p->qscale_type));
> > +qp = FFMAX(1, ff_norm_qscale(qp, FF_QSCALE_TYPE_MPEG2));
>
> wouldnt this break the cases where qscale_type is not FF_QSCALE_TYPE_MPEG2 ?
There should be no such cases - in the new API, only TYPE_MPEG2 exists
(disregarding newer codecs that were not supported by this filter
anyway).
--
Anton Khirnov
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 2/2] libavcodec/ac3tab: rename ff_ac3_sample_rate_tab to avpriv_ac3_sample_rate_tab so that it can be used in libavformat
Quoting Nachiket Tarate (2020-10-04 16:35:09) > This will be used by HLS demuxer to parse EC3SpecificBox (dec3) during > SAMPLE-AES decryption. > > Signed-off-by: Nachiket Tarate Since the table is so small, it seems preferable to duplicate it in libavformat than add eat another private symbol. Private symbols are evil and should not exist. -- Anton Khirnov ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2 3/3] avformat/mxfdec: Read Apple private Content Light Level from MXF
tor 2020-10-01 klockan 22:13 +0200 skrev Michael Niedermayer: > On Thu, Oct 01, 2020 at 03:29:19PM +0100, Harry Mallon wrote: > > > On 30 Sep 2020, at 08:32, Michael Niedermayer > > > wrote: > > > > > > fails on big endian > > > > > > --- src/tests/ref/fate/mxf-probe-applehdr10 2020-09-28 > > > 23:21:12.291897976 +0200 > > > +++ tests/data/fate/mxf-probe-applehdr10 2020-09-30 09:31:38.614653806 > > > +0200 > > > @@ -14,7 +14,7 @@ > > > has_b_frames=0 > > > sample_aspect_ratio=1:1 > > > display_aspect_ratio=16:9 > > > -pix_fmt=yuv422p10le > > > +pix_fmt=yuv422p10be > > > level=-99 > > > color_range=tv > > > color_space=bt2020nc > > > Test mxf-probe-applehdr10 failed. Look at > > > tests/data/fate/mxf-probe-applehdr10.err for details. > > > src/tests/Makefile:255: recipe for target 'fate-mxf-probe-applehdr10' > > > failed > > > make: *** [fate-mxf-probe-applehdr10] Error 1 > > > > It seems fair that the pixel type is in native endian. > > maybe but the endianness of the decoder output doesnt belong in the > comparission > > > > I'm not really familiar enough with FATE to provide a patch to fix this > > though. Do any other FATE tests have wildcards or two versions for big and > > little endian? > > i dont see another probe reference file that contains a le/be format > > we had le/be issues in other places though where they where fixed by forcing > a format with specific endianness in the test IIRC How about something like this? /Tomas From 2b98d97f21420f9db90f0bff3f5ae5d88fcac976 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Tomas=20H=C3=A4rdin?= Date: Mon, 5 Oct 2020 10:17:13 +0200 Subject: [PATCH] fate-mxf-probe-applehdr10: Ignore endianness --- tests/fate/mxf.mak | 2 +- tests/ref/fate/mxf-probe-applehdr10 | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/tests/fate/mxf.mak b/tests/fate/mxf.mak index 3adef939dc..ca119fa677 100644 --- a/tests/fate/mxf.mak +++ b/tests/fate/mxf.mak @@ -35,7 +35,7 @@ fate-mxf-probe-dv25: CMD = run $(PROBE_FORMAT_STREAMS_COMMAND) -i "$(SRC)" FATE_MXF_PROBE-$(call ENCDEC2, PRORES, PCM_S24LE, MXF) += fate-mxf-probe-applehdr10 fate-mxf-probe-applehdr10: SRC = $(TARGET_SAMPLES)/mxf/Meridian-Apple_ProResProxy-HDR10.mxf -fate-mxf-probe-applehdr10: CMD = run $(PROBE_FORMAT_STREAMS_COMMAND) -i "$(SRC)" +fate-mxf-probe-applehdr10: CMD = run $(PROBE_FORMAT_STREAMS_COMMAND) -i "$(SRC)" | sed -e "s/yuv422p10../yuv422p10/" FATE_MXF_REEL_NAME-$(call ENCDEC2, MPEG2VIDEO, PCM_S16LE, MXF) += fate-mxf-reel_name fate-mxf-reel_name: $(SAMPLES)/mxf/Sony-1.mxf diff --git a/tests/ref/fate/mxf-probe-applehdr10 b/tests/ref/fate/mxf-probe-applehdr10 index 3430670c52..53a767c1cd 100644 --- a/tests/ref/fate/mxf-probe-applehdr10 +++ b/tests/ref/fate/mxf-probe-applehdr10 @@ -14,7 +14,7 @@ closed_captions=0 has_b_frames=0 sample_aspect_ratio=1:1 display_aspect_ratio=16:9 -pix_fmt=yuv422p10le +pix_fmt=yuv422p10 level=-99 color_range=tv color_space=bt2020nc -- 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".
