Re: [FFmpeg-devel] [PATCH v2 7/8] avfilter/sleet: Add sleet filter

2021-09-07 Thread Soft Works 



> -Original Message-
> From: ffmpeg-devel  On Behalf Of
> Moritz Barsnick
> Sent: Friday, 3 September 2021 10:24
> To: FFmpeg development discussions and patches  de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH v2 7/8] avfilter/sleet: Add sleet
> filter
> 
> On Tue, Aug 31, 2021 at 22:49:12 +, Soft Works wrote:

[..]

> 
> Well, at least it demonstrates the boilerplate required for a simple
> S->S filter, which touches only text (no timings or positioning or
> so).
> A review of this boilerplate would be great.
> 
> For the sake of review:
> - You need to add documentation to doc/filters.texi.
> - You need to bump MINOR in libavfilter/version.h.
> 
> > Maybe an "sallcaps" filter makes slightly more sense than "sleet"?
> 
> For the sake of usability, I would rather have suggested something
> like
> "tr" (https://linux.die.net/man/1/tr,
> https://www.geeksforgeeks.org/perl-tr-operator/), where you can
> specify
> the replacement list. That said, tr has some funky shortcuts ("[a-z]
> [A-Z]" for uppercase, which may be harder to implement). Or actual
> regular expression support.
> 
> What I suggest is still not really useful for a user, though. Or is
> it?

Hi Moritz,

I have changed the filter to a multi-purpose text modification filter
and renamed it to 'textmod'.

It has the following options:

"mode", "set operation mode",
  "leet",   "convert text to 'leet speak'",  
  "to_upper",   "change to upper case",  
  "to_lower",   "change to lower case",  
  "replace_chars",  "replace characters",
  "remove_chars",   "remove characters", 
  "replace_words",  "replace words", 
  "remove_words",   "remove words",  
"find", "chars/words to find or remove", 
"replace",  "chars/words to replace",
"separator","word separator (default: ',')",

I think that makes it sufficiently useful.

Some plausible use case examples:

replace_words

Some movies (like Disney's Moana) are using different character 
names depending on country (Moana aka Vaiana aka Oceania, ..).
The character naming in subtitles might not always match what you're
expecting - you can use replace_words to fix it

remove_chars

Certain characters might be visually annoying for some (like the 
flipped exclamation and question marks in Spanish). With remove_chars,
these can be removed

to_upper

For improved readability

leet

Still highly useless (except for testing) ;-)


softworkz

___
ffmpeg-devel mailing list
ffmpeg-devel@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] Introduction

2021-09-07 Thread Piyush Badkul 
Hello
I am a working professional and want to introduce myself to the FFmpeg
devel mailing list. I wish to contribute to FFmpeg by solving its issues
listed on the bug tracker.

However, I can't get a hold of which bug to fix. Can you point me in the
right direction?
Can you point me to some beginner to intermediate level bugs that I can fix
and submit?

As of now, I have fetched the code from GitHub and successfully compiled it.

Regards

*Piyush Badkul* [Personal Website ]

*+91 8989412425  |* *+91 7987549194*

Designer | Developer (App Developer & Software Developer) | Blogger.

*Research Engineer at* *C-DOT * *| Co-Founder*
*(**YoCount*

*)** |* *Curator (*CodesMyth *) *

Bachelor of Technology, Maulana Azad National Institute Of Technology,
Bhopal, India [An Institute of National Importance].

■ Android ■ Designer ■ Blogger ■ Developer

Note: This email and its attachments are confidential and are protected by
copyright. When addressed to our clients it is subject to our terms and
conditions of business. Unless specifically specified, the contents are for
information and discussion only
___
ffmpeg-devel mailing list
ffmpeg-devel@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] avcodec/nvenc: Add constrainedFrame encoding support

2021-09-07 Thread Timo Rothenpieler 

On 07.09.2021 03:26, lance.lmw...@gmail.com wrote:

On Mon, Sep 06, 2021 at 02:49:47PM +0200, Timo Rothenpieler wrote:

Series applied.

While testing, I found that constrained encoding for HEVC was not a thing
until SDK 10.0, so I added the necessary check and compile time guards for
that.

Also done some other minor style and logic changes, and renamed the options
to use "-" instead of "_", so the options match their libx264 counterpart.

Thanks, I notice libx264 use "-" style, but it's not consistent with other 
options
of nvenc. So I use "_" instead. I'm not sure what's style is more preferable.



The style of nvenc options is already all over the place, and staying in 
line with libx264 seems a bit more important here.


Maybe at some future major bump the options can be cleaned up a bit.


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

[FFmpeg-devel] [PATCH 1/4] avcodec/siren: replace magic numbers with macro value

2021-09-07 Thread Peter Ross 
---
 libavcodec/siren.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/libavcodec/siren.c b/libavcodec/siren.c
index 5b172c5ab7..93a2d14d25 100644
--- a/libavcodec/siren.c
+++ b/libavcodec/siren.c
@@ -698,7 +698,7 @@ static int siren_decode(AVCodecContext *avctx, void *data,
 SirenContext *s = avctx->priv_data;
 GetBitContext *gb = &s->gb;
 AVFrame *frame = data;
-int ret, number_of_valid_coefs = 20 * s->number_of_regions;
+int ret, number_of_valid_coefs = REGION_SIZE * s->number_of_regions;
 int frame_error = 0, rate_control = 0;
 int bits_per_frame;
 
@@ -765,7 +765,7 @@ static int siren_decode(AVCodecContext *avctx, void *data,
 if ((ret = ff_get_buffer(avctx, frame, 0)) < 0)
 return ret;
 
-for (int i = 0; i < 320; i += 2)
+for (int i = 0; i < FRAME_SIZE; i += 2)
 s->imdct_in[i] *= -1;
 
 s->tx_fn(s->tx_ctx, s->imdct_out, s->imdct_in, sizeof(float));
-- 
2.33.0

-- Peter
(A907 E02F A6E5 0CD2 34CD 20D2 6760 79C5 AC40 DD6B)


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

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

[FFmpeg-devel] [PATCH 2/4] avcodec/siren: decode_vector: remove unused parameter

2021-09-07 Thread Peter Ross 
---
Looks to me like a cut and paste error.

 libavcodec/siren.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/libavcodec/siren.c b/libavcodec/siren.c
index 93a2d14d25..ccc69aaf40 100644
--- a/libavcodec/siren.c
+++ b/libavcodec/siren.c
@@ -568,7 +568,7 @@ static int get_dw(SirenContext *s)
 }
 
 static int decode_vector(SirenContext *s, int number_of_regions,
- int number_of_available_bits, float 
*decoder_standard_deviation,
+ float *decoder_standard_deviation,
  int *power_categories, float *coefs, int scale_factor)
 {
 GetBitContext *gb = &s->gb;
@@ -731,7 +731,7 @@ static int siren_decode(AVCodecContext *avctx, void *data,
 for (int i = 0; i < rate_control; i++)
 s->power_categories[s->category_balance[i]]++;
 
-ret = decode_vector(s, s->number_of_regions, get_bits_left(gb),
+ret = decode_vector(s, s->number_of_regions,
 s->decoder_standard_deviation, s->power_categories,
 s->imdct_in, s->scale_factor);
 if (ret < 0 && !s->microsoft)
-- 
2.33.0

-- Peter
(A907 E02F A6E5 0CD2 34CD 20D2 6760 79C5 AC40 DD6B)


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 3/4] avcodec/siren: add checksum calculation

2021-09-07 Thread Peter Ross 
---
 libavcodec/siren.c | 29 -
 1 file changed, 28 insertions(+), 1 deletion(-)

diff --git a/libavcodec/siren.c b/libavcodec/siren.c
index ccc69aaf40..31fb9346da 100644
--- a/libavcodec/siren.c
+++ b/libavcodec/siren.c
@@ -752,7 +752,34 @@ static int siren_decode(AVCodecContext *avctx, void *data,
 frame_error = 1;
 }
 
-skip_bits(gb, s->checksum_bits);
+if (s->checksum_bits) {
+static const uint16_t ChecksumTable[4] = {0x7F80, 0x7878, 0x, 
0x};
+int wpf, checksum, sum, calculated_checksum, temp1, temp2;
+
+wpf = bits_per_frame / 16;
+
+checksum = AV_RB16(avpkt->data + (wpf - 1) * 2) & ((1 << 
s->checksum_bits) - 1);
+
+sum = 0;
+for (int i = 0; i < wpf - 1; i++)
+sum ^= AV_RB16(avpkt->data + i * 2) << (i % 15);
+sum ^= (AV_RB16(avpkt->data + (wpf - 1) * 2) & ~checksum) << ((wpf - 
1) % 15);
+sum = (sum >> 15) ^ (sum & 0x7FFF);
+
+calculated_checksum = 0;
+for (int i = 0; i < 4; i++) {
+temp1 = ChecksumTable[i] & sum;
+for (int j = 8; j > 0; j >>= 1) {
+temp2 = temp1 >> j;
+temp1 ^= temp2;
+}
+calculated_checksum <<= 1;
+calculated_checksum |= temp1 & 1;
+}
+
+if (checksum != calculated_checksum)
+frame_error = 1;
+}
 
 if (frame_error) {
 memcpy(s->imdct_in, s->backup_frame, number_of_valid_coefs * 
sizeof(float));
-- 
2.33.0

-- Peter
(A907 E02F A6E5 0CD2 34CD 20D2 6760 79C5 AC40 DD6B)


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

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

Re: [FFmpeg-devel] [PATCH 1/4] avcodec/siren: replace magic numbers with macro value

2021-09-07 Thread Paul B Mahol 
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/4] avcodec/siren: decode_vector: remove unused parameter

2021-09-07 Thread Paul B Mahol 
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] [FFmpeg-cvslog] lavfi/vf_scale: pass the thread count to the scaler

2021-09-07 Thread Michael Niedermayer 
On Mon, Sep 06, 2021 at 07:23:13AM +, Anton Khirnov wrote:
> ffmpeg | branch: master | Anton Khirnov  | Wed Jul  7 
> 18:42:15 2021 +0200| [60515a6d610491f030aaa4cf230d0367a85e2d4b] | committer: 
> Anton Khirnov
> 
> lavfi/vf_scale: pass the thread count to the scaler
> 
> > http://git.videolan.org/gitweb.cgi/ffmpeg.git/?a=commit;h=60515a6d610491f030aaa4cf230d0367a85e2d4b
> ---

This breaks a few things:
I appologize for not noticing this earlier


./ffmpeg -i ~/tickets/4746/proresalphablock-small.avi -vf 
format=rgba64be,scale=alphablend=checkerboard,format=rgb48 -qscale 2 
rgba64BEcheck.avi

This no longer shows a checkerboard, input file should not matter as
long as it has some transpareancy


./ffmpeg -y -bitexact -i ~/videos/mm-short.mpg -vframes 30 -bitexact -vcodec 
zmbv -pix_fmt pal8 -an file-zmbv.avi
-rw-r- 1 michael michael 1189614 Sep  7 11:02 file-zmbv.avi
-rw-r- 1 michael michael 1166552 Sep  7 11:02 file-zmbv-old.avi

The file changes even though bitexact is used


Heres another unexplained difference (no pal8/bgr8/yuv410 here)
./ffmpeg -i ~/tickets/4301/untitled.split.2_new.split.1.cut.avi -bitexact -vf 
hqdn3d=5:4:7:6 -qscale 1 hqdn.avi
-rw-r- 1 michael michael 69374 Sep  7 11:05 hqdn.avi
-rw-r- 1 michael michael 69346 Sep  7 11:06 hqdn-oldscale.avi
If i look at the framecrc of this, it differs too:
0,  0,  0,1,55543, 0xd89e9187
0,  1,  1,1, 8053, 0xcd4c9008, F=0x0ate=  
40.5kbits/s speed=N/A
vs.
0,  0,  0,1,55501, 0xba057084
0,  1,  1,1, 8068, 0xc2e79f6e, F=0x0ate=  
40.5kbits/s speed=N/A


Heres another thread number output difference with bitexact (yuv410 here)
./ffmpeg -y -i ~/tickets/1012/IV50_random_points.avi -bitexact -threads 5 
file1012-5.avi
./ffmpeg -y -i ~/tickets/1012/IV50_random_points.avi -bitexact -threads 3 
file1012-3.avi
-rw-r- 1 michael michael 209766 Sep  7 11:13 file1012-3.avi
-rw-r- 1 michael michael 208906 Sep  7 11:13 file1012-5.avi


This seems bgr24  / yuv420 producing differences
./ffmpeg -i ~/tickets/3757/testinput_small.avi -vcodec mpeg1video -bf 8 
-b_strategy 2 -q:v 3 -an -y -bitexact -vframes 30 bstrategy2.mpg
-rw-r- 1 michael michael 225280 Sep  7 11:17 bstrategy2.mpg
-rw-r- 1 michael michael 221184 Sep  7 11:17 bstrategy2-old.mpg


yuv422p10le / yuv422p
./ffmpeg -i ~/tickets/3434/ProRes_FromHaali.mkv -vframes 27 -bitexact 
file-3434.mkv
-rw-r- 1 michael michael 13786 Sep  7 11:20 file-3434.mkv
-rw-r- 1 michael michael 13815 Sep  7 11:20 file-3434-oldscale.mkv


./ffmpeg -i ~/tickets/3516/YCbCrK.jpg -bitexact file-3516.jpg
-rw-r- 1 michael michael 98747 Sep  7 11:23 file-3516.jpg
-rw-r- 1 michael michael 87045 Sep  7 11:23 file-3516-old.jpg
This also replicates the "deprecated pixel format used, make sure you did set 
range correctly" warning on each context
its probably better to only show it for the first context or something
The 2nd slice and later look more spicy color wise, maybe something has not
been set in them the same as in the first

I have 7 more testcases which are different, but i guess alot if not all will
be duplicates. Ill retest once these are fixes or if you prefer i can also
write reports like above for all i found.

I suggest to temporary revert 60515a6d610491f030aaa4cf230d0367a85e2d4b so its
easier to test the fixes

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 v1 1/1] libavformat/amr.c: remove mode range check

2021-09-07 Thread Sun Zhenliang 
在 2021年9月7日 +0800 14:16，Paul B Mahol ，写道：
> On Tue, Sep 7, 2021 at 7:34 AM Sun Zhenliang 
> wrote:
>
> > 在 2021年9月7日 +0800 00:55，Paul B Mahol ，写道：
> > > On Sat, Sep 4, 2021 at 1:52 PM Sun Zhenliang  > >
> > > wrote:
> > >
> > > >
> > > > >
> > > > > On Sep 4, 2021, at 16:01, Hendrik Leppkes 
> > wrote:
> > > > >
> > > > > On Sat, Sep 4, 2021 at 9:10 AM sunzhenliang <
> > hisunzhenli...@outlook.com>
> > > > wrote:
> > > > > >
> > > > > > Those comfort noise frames and empty frames should be
> > > > > > considered the correct frame. And amr.c/amr_read_packet()
> > > > > > also takes them as correct frames too.
> > > > > >
> > > > > > Signed-off-by: sunzhenliang 
> > > > > > ---
> > > > > > libavformat/amr.c | 4 ++--
> > > > > > 1 file changed, 2 insertions(+), 2 deletions(-)
> > > > > >
> > > > > > diff --git a/libavformat/amr.c b/libavformat/amr.c
> > > > > > index 836b276fd5..540d8033d8 100644
> > > > > > --- a/libavformat/amr.c
> > > > > > +++ b/libavformat/amr.c
> > > > > > @@ -178,7 +178,7 @@ static int amrnb_probe(const AVProbeData *p)
> > > > > >
> > > > > > while (i < p->buf_size) {
> > > > > > mode = b[i] >> 3 & 0x0F;
> > > > > > - if (mode < 9 && (b[i] & 0x4) == 0x4) {
> > > > > > + if ((b[i] & 0x4) == 0x4) {
> > > > > > int last = b[i];
> > > > > > int size = amrnb_packed_size[mode];
> > > > > > while (size--) {
> > > > > > @@ -234,7 +234,7 @@ static int amrwb_probe(const AVProbeData *p)
> > > > > >
> > > > > > while (i < p->buf_size) {
> > > > > > mode = b[i] >> 3 & 0x0F;
> > > > > > - if (mode < 10 && (b[i] & 0x4) == 0x4) {
> > > > > > + if ((b[i] & 0x4) == 0x4) {
> > > > > > int last = b[i];
> > > > > > int size = amrwb_packed_size[mode];
> > > > > > while (size--) {
> > > > >
> > > > > This is just probing, and expecting to find a significant amount of
> > > > > non-empty/non-noise frames seems like something you would want in
> > > > > probing.
> > > > > Does this actually fix detection of any samples?
> > > > >
> > > > > It seems like this has the potential of quite substantially reducing
> > > > > the number of checked bits and thus invalid detections.
> > > > >
> > > > > - Hendrik
> > > > > 
> > > >
> > > > Thanks for reviewing.
> > > >
> > > > Probing is expecting to find “correct” frames, which includes those
> > kinds
> > > > of comfort noise and NO_DATA frames mentioned in 3GPP Specifications.
> > > >
> > > > Besides, those frames are considered as normal frames while reading
> > > > packets. It seems better to take the same standard of frames in both
> > > > reading and probing.
> > > >
> > > >
> > > Yes, but in past IIRC it caused misdetection when probing.
> > But it may cause misdetection when probing audios with many
> > comfort noise and NO_DATA frames. Maybe we should stick to
> > 3GPP Specifications.
> >
>
> And at same time not broke probing for more more important formats.
> Have you checked that your patch does not cause regressions?
>
I have done fate-test, but can not submit the results with fate_recv.
I have sent the public ssh key to fate-ad...@ffmpeg.org, maybe it
needs some time?
>
> >
> > - sunzhenliang
> > > > - sunzhenliang
> > > >
> > > >
> > > >
> > > > ___
> > > > ffmpeg-devel mailing list
> > > > ffmpeg-devel@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".
> >
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@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] avcodec/siren: add checksum calculation

2021-09-07 Thread Lynne 
7 Sept 2021, 11:28 by pr...@xvid.org:

> ---
>  libavcodec/siren.c | 29 -
>  1 file changed, 28 insertions(+), 1 deletion(-)
>
> diff --git a/libavcodec/siren.c b/libavcodec/siren.c
> index ccc69aaf40..31fb9346da 100644
> --- a/libavcodec/siren.c
> +++ b/libavcodec/siren.c
> @@ -752,7 +752,34 @@ static int siren_decode(AVCodecContext *avctx, void 
> *data,
>  frame_error = 1;
>  }
>  
> -skip_bits(gb, s->checksum_bits);
> +if (s->checksum_bits) {
> +static const uint16_t ChecksumTable[4] = {0x7F80, 0x7878, 0x, 
> 0x};
> +int wpf, checksum, sum, calculated_checksum, temp1, temp2;
> +
> +wpf = bits_per_frame / 16;
> +
> +checksum = AV_RB16(avpkt->data + (wpf - 1) * 2) & ((1 << 
> s->checksum_bits) - 1);
> +
> +sum = 0;
> +for (int i = 0; i < wpf - 1; i++)
> +sum ^= AV_RB16(avpkt->data + i * 2) << (i % 15);
> +sum ^= (AV_RB16(avpkt->data + (wpf - 1) * 2) & ~checksum) << ((wpf - 
> 1) % 15);
> +sum = (sum >> 15) ^ (sum & 0x7FFF);
> +
> +calculated_checksum = 0;
> +for (int i = 0; i < 4; i++) {
> +temp1 = ChecksumTable[i] & sum;
> +for (int j = 8; j > 0; j >>= 1) {
> +temp2 = temp1 >> j;
> +temp1 ^= temp2;
> +}
> +calculated_checksum <<= 1;
> +calculated_checksum |= temp1 & 1;
> +}
> +
> +if (checksum != calculated_checksum)
> +frame_error = 1;
> +}
>  
>  if (frame_error) {
>  memcpy(s->imdct_in, s->backup_frame, number_of_valid_coefs * sizeof(float));
>

Good idea, but only check it if AV_EF_CRCCHECK is set in avctx->err_recognition
and only error on mismatches if AV_EF_EXPLODE is set in the same field.
___
ffmpeg-devel mailing list
ffmpeg-devel@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 v1 1/1] libavformat/amr.c: remove mode range check

2021-09-07 Thread Paul B Mahol 
On Tue, Sep 7, 2021 at 11:36 AM Sun Zhenliang 
wrote:

> 在 2021年9月7日 +0800 14:16，Paul B Mahol ，写道：
> > On Tue, Sep 7, 2021 at 7:34 AM Sun Zhenliang  >
> > wrote:
> >
> > > 在 2021年9月7日 +0800 00:55，Paul B Mahol ，写道：
> > > > On Sat, Sep 4, 2021 at 1:52 PM Sun Zhenliang <
> hisunzhenli...@outlook.com
> > > >
> > > > wrote:
> > > >
> > > > >
> > > > > >
> > > > > > On Sep 4, 2021, at 16:01, Hendrik Leppkes 
> > > wrote:
> > > > > >
> > > > > > On Sat, Sep 4, 2021 at 9:10 AM sunzhenliang <
> > > hisunzhenli...@outlook.com>
> > > > > wrote:
> > > > > > >
> > > > > > > Those comfort noise frames and empty frames should be
> > > > > > > considered the correct frame. And amr.c/amr_read_packet()
> > > > > > > also takes them as correct frames too.
> > > > > > >
> > > > > > > Signed-off-by: sunzhenliang 
> > > > > > > ---
> > > > > > > libavformat/amr.c | 4 ++--
> > > > > > > 1 file changed, 2 insertions(+), 2 deletions(-)
> > > > > > >
> > > > > > > diff --git a/libavformat/amr.c b/libavformat/amr.c
> > > > > > > index 836b276fd5..540d8033d8 100644
> > > > > > > --- a/libavformat/amr.c
> > > > > > > +++ b/libavformat/amr.c
> > > > > > > @@ -178,7 +178,7 @@ static int amrnb_probe(const AVProbeData
> *p)
> > > > > > >
> > > > > > > while (i < p->buf_size) {
> > > > > > > mode = b[i] >> 3 & 0x0F;
> > > > > > > - if (mode < 9 && (b[i] & 0x4) == 0x4) {
> > > > > > > + if ((b[i] & 0x4) == 0x4) {
> > > > > > > int last = b[i];
> > > > > > > int size = amrnb_packed_size[mode];
> > > > > > > while (size--) {
> > > > > > > @@ -234,7 +234,7 @@ static int amrwb_probe(const AVProbeData
> *p)
> > > > > > >
> > > > > > > while (i < p->buf_size) {
> > > > > > > mode = b[i] >> 3 & 0x0F;
> > > > > > > - if (mode < 10 && (b[i] & 0x4) == 0x4) {
> > > > > > > + if ((b[i] & 0x4) == 0x4) {
> > > > > > > int last = b[i];
> > > > > > > int size = amrwb_packed_size[mode];
> > > > > > > while (size--) {
> > > > > >
> > > > > > This is just probing, and expecting to find a significant amount
> of
> > > > > > non-empty/non-noise frames seems like something you would want in
> > > > > > probing.
> > > > > > Does this actually fix detection of any samples?
> > > > > >
> > > > > > It seems like this has the potential of quite substantially
> reducing
> > > > > > the number of checked bits and thus invalid detections.
> > > > > >
> > > > > > - Hendrik
> > > > > > 
> > > > >
> > > > > Thanks for reviewing.
> > > > >
> > > > > Probing is expecting to find “correct” frames, which includes those
> > > kinds
> > > > > of comfort noise and NO_DATA frames mentioned in 3GPP
> Specifications.
> > > > >
> > > > > Besides, those frames are considered as normal frames while reading
> > > > > packets. It seems better to take the same standard of frames in
> both
> > > > > reading and probing.
> > > > >
> > > > >
> > > > Yes, but in past IIRC it caused misdetection when probing.
> > > But it may cause misdetection when probing audios with many
> > > comfort noise and NO_DATA frames. Maybe we should stick to
> > > 3GPP Specifications.
> > >
> >
> > And at same time not broke probing for more more important formats.
> > Have you checked that your patch does not cause regressions?
> >
> I have done fate-test, but can not submit the results with fate_recv.
> I have sent the public ssh key to fate-ad...@ffmpeg.org, maybe it
> needs some time?
>

I mean regressions not covered by FATE.

Also you misunderstood fate-test, this patch have nothing to do with
sending your fate testing reports to FFmpeg.


> >
> > >
> > > - sunzhenliang
> > > > > - sunzhenliang
> > > > >
> > > > >
> > > > >
> > > > > ___
> > > > > ffmpeg-devel mailing list
> > > > > ffmpeg-devel@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".
> > >
> > ___
> > ffmpeg-devel mailing list
> > ffmpeg-devel@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

[FFmpeg-devel] [fateserver PATCH 1/2] Add a missed taint check in report.cgi

2021-09-07 Thread Martin Storsjö 
This was missed in 505f620a5d22ffef86ad5ffa1328e87ba6dc191b.
---
 report.cgi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/report.cgi b/report.cgi
index 2b388e4..fb00fee 100755
--- a/report.cgi
+++ b/report.cgi
@@ -1,4 +1,4 @@
-#! /usr/bin/perl
+#! /usr/bin/perl -T
 #
 # Copyright (c) 2011 Mans Rullgard 
 #
-- 
2.25.1

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

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

[FFmpeg-devel] [fateserver PATCH 2/2] Add missing validation of out of process data

2021-09-07 Thread Martin Storsjö 
When invoking unxz, the variables making up the path
passed to unxz need to be validated.

load_summary normally only reads the "summary" file, but
if missing, it tries to use unxz to unpack report.xz. In
this case the slot value needs to be validated, which can
be done in the main loop in index.cgi.

load_report uses unxz, with a slot and date read from
the summary file, when the report contained failures.
In this case, the slot and date values can either be
validated as they're read from the summary in load_summary
or split_header, or before they're used in load_report.

This unbreaks the main results listings for slots with one or
more test failures.
---
 FATE.pm   | 2 ++
 index.cgi | 1 +
 2 files changed, 3 insertions(+)

diff --git a/FATE.pm b/FATE.pm
index b7d7260..ccb8958 100644
--- a/FATE.pm
+++ b/FATE.pm
@@ -147,6 +147,8 @@ sub load_summary {
 
 sub load_report {
 my ($slot, $date) = @_;
+($slot) = $slot =~ /^([A-Za-z0-9_\-.]{1,80})\z/ or exit 1;
+($date) = $date =~ /^([0-9]{1,80})\z/ or exit 1;
 my $report = "$fatedir/$slot/$date/report.xz";
 my @recs;
 
diff --git a/index.cgi b/index.cgi
index 8fe92db..c053d0e 100755
--- a/index.cgi
+++ b/index.cgi
@@ -47,6 +47,7 @@ my $allpass = 0;
 my $allfail = 0;
 
 for my $slot (@slots) {
+($slot) = $slot =~ /^([A-Za-z0-9_\-.]{1,80})\z/ or next;
 next if -e "$fatedir/$slot/hidden";
 my $rep = load_summary $slot, 'latest' or next;
 next if time - parse_date($$rep{date}) > $hidden_age;
-- 
2.25.1

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

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

Re: [FFmpeg-devel] [PATCH] libswscale/swscale: initialize all dst plane pointers in sws_receive_slice()

2021-09-07 Thread James Almer 

On 9/6/2021 12:01 PM, James Almer wrote:

Fixes valgrind warnings about use of uninitialised values.

Signed-off-by: James Almer 
---
  libswscale/swscale.c | 6 +++---
  1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/libswscale/swscale.c b/libswscale/swscale.c
index c233818dcf..b9c9647fcb 100644
--- a/libswscale/swscale.c
+++ b/libswscale/swscale.c
@@ -1160,9 +1160,9 @@ int sws_receive_slice(struct SwsContext *c, unsigned int 
slice_start,
  return ret;
  }
  
-for (int i = 0; i < FF_ARRAY_ELEMS(dst) && c->frame_dst->data[i]; i++) {

-dst[i] = c->frame_dst->data[i] +
- c->frame_dst->linesize[i] * (slice_start >> 
c->chrDstVSubSample);
+for (int i = 0; i < FF_ARRAY_ELEMS(dst); i++) {
+ptrdiff_t offset = c->frame_dst->linesize[i] * (slice_start >> 
c->chrDstVSubSample);
+dst[i] = FF_PTR_ADD(c->frame_dst->data[i], offset);
  }
  
  return scale_internal(c, (const uint8_t * const *)c->frame_src->data,


Applied.
___
ffmpeg-devel mailing list
ffmpeg-devel@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] [fateserver PATCH 1/2] Add a missed taint check in report.cgi

2021-09-07 Thread Nicolas George 
Martin Storsjo (12021-09-07):
> This was missed in 505f620a5d22ffef86ad5ffa1328e87ba6dc191b.
> ---
>  report.cgi | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Thanks, both patches pushed and deployed.

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 v1 1/1] libavformat/amr.c: remove mode range check

2021-09-07 Thread Sun Zhenliang 
在 2021年9月7日 +0800 19:13，Paul B Mahol ，写道：
> On Tue, Sep 7, 2021 at 11:36 AM Sun Zhenliang 
> wrote:
>
> > 在 2021年9月7日 +0800 14:16，Paul B Mahol ，写道：
> > > On Tue, Sep 7, 2021 at 7:34 AM Sun Zhenliang  > >
> > > wrote:
> > >
> > > > 在 2021年9月7日 +0800 00:55，Paul B Mahol ，写道：
> > > > > On Sat, Sep 4, 2021 at 1:52 PM Sun Zhenliang <
> > hisunzhenli...@outlook.com
> > > > >
> > > > > wrote:
> > > > >
> > > > > >
> > > > > > >
> > > > > > > On Sep 4, 2021, at 16:01, Hendrik Leppkes 
> > > > wrote:
> > > > > > >
> > > > > > > On Sat, Sep 4, 2021 at 9:10 AM sunzhenliang <
> > > > hisunzhenli...@outlook.com>
> > > > > > wrote:
> > > > > > > >
> > > > > > > > Those comfort noise frames and empty frames should be
> > > > > > > > considered the correct frame. And amr.c/amr_read_packet()
> > > > > > > > also takes them as correct frames too.
> > > > > > > >
> > > > > > > > Signed-off-by: sunzhenliang 
> > > > > > > > ---
> > > > > > > > libavformat/amr.c | 4 ++--
> > > > > > > > 1 file changed, 2 insertions(+), 2 deletions(-)
> > > > > > > >
> > > > > > > > diff --git a/libavformat/amr.c b/libavformat/amr.c
> > > > > > > > index 836b276fd5..540d8033d8 100644
> > > > > > > > --- a/libavformat/amr.c
> > > > > > > > +++ b/libavformat/amr.c
> > > > > > > > @@ -178,7 +178,7 @@ static int amrnb_probe(const AVProbeData
> > *p)
> > > > > > > >
> > > > > > > > while (i < p->buf_size) {
> > > > > > > > mode = b[i] >> 3 & 0x0F;
> > > > > > > > - if (mode < 9 && (b[i] & 0x4) == 0x4) {
> > > > > > > > + if ((b[i] & 0x4) == 0x4) {
> > > > > > > > int last = b[i];
> > > > > > > > int size = amrnb_packed_size[mode];
> > > > > > > > while (size--) {
> > > > > > > > @@ -234,7 +234,7 @@ static int amrwb_probe(const AVProbeData
> > *p)
> > > > > > > >
> > > > > > > > while (i < p->buf_size) {
> > > > > > > > mode = b[i] >> 3 & 0x0F;
> > > > > > > > - if (mode < 10 && (b[i] & 0x4) == 0x4) {
> > > > > > > > + if ((b[i] & 0x4) == 0x4) {
> > > > > > > > int last = b[i];
> > > > > > > > int size = amrwb_packed_size[mode];
> > > > > > > > while (size--) {
> > > > > > >
> > > > > > > This is just probing, and expecting to find a significant amount
> > of
> > > > > > > non-empty/non-noise frames seems like something you would want in
> > > > > > > probing.
> > > > > > > Does this actually fix detection of any samples?
> > > > > > >
> > > > > > > It seems like this has the potential of quite substantially
> > reducing
> > > > > > > the number of checked bits and thus invalid detections.
> > > > > > >
> > > > > > > - Hendrik
> > > > > > > 
> > > > > >
> > > > > > Thanks for reviewing.
> > > > > >
> > > > > > Probing is expecting to find “correct” frames, which includes those
> > > > kinds
> > > > > > of comfort noise and NO_DATA frames mentioned in 3GPP
> > Specifications.
> > > > > >
> > > > > > Besides, those frames are considered as normal frames while reading
> > > > > > packets. It seems better to take the same standard of frames in
> > both
> > > > > > reading and probing.
> > > > > >
> > > > > >
> > > > > Yes, but in past IIRC it caused misdetection when probing.
> > > > But it may cause misdetection when probing audios with many
> > > > comfort noise and NO_DATA frames. Maybe we should stick to
> > > > 3GPP Specifications.
> > > >
> > >
> > > And at same time not broke probing for more more important formats.
> > > Have you checked that your patch does not cause regressions?
> > >
> > I have done fate-test, but can not submit the results with fate_recv.
> > I have sent the public ssh key to fate-ad...@ffmpeg.org, maybe it
> > needs some time?
> >
>
> I mean regressions not covered by FATE.
>
> Also you misunderstood fate-test, this patch have nothing to do with
> sending your fate testing reports to FFmpeg.
>
Sorry, could you explain more in details? I am confused.

I have checked this patch, which works fine with those amr files.
> > >
> > > >
> > > > - sunzhenliang
> > > > > > - sunzhenliang
> > > > > >
> > > > > >
> > > > > >
> > > > > > ___
> > > > > > ffmpeg-devel mailing list
> > > > > > ffmpeg-devel@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".
> > > >
> > > __

[FFmpeg-devel] [fateserver PATCH] Move validation of parsed slot/date into split_header from load_report

2021-09-07 Thread Martin Storsjö 
This avoids using tainted data in the call to zcat in the main loop
in index.cgi.

This fixes the report listing for cases with a compile error.
---
 FATE.pm | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/FATE.pm b/FATE.pm
index ccb8958..0d4603f 100644
--- a/FATE.pm
+++ b/FATE.pm
@@ -52,6 +52,8 @@ our $gitweb = "http://git.videolan.org/?p=ffmpeg.git";;
 sub split_header {
 my @hdr = split /:/, $_[0];
 $hdr[0] eq 'fate' or return undef;
+($hdr[2]) = $hdr[2] =~ /^([0-9]{1,80})\z/ or return undef;
+($hdr[3]) = $hdr[3] =~ /^([A-Za-z0-9_\-.]{1,80})\z/ or return undef;
 my $parsed = {
 version => $hdr[1],
 date=> $hdr[2],
@@ -147,8 +149,6 @@ sub load_summary {
 
 sub load_report {
 my ($slot, $date) = @_;
-($slot) = $slot =~ /^([A-Za-z0-9_\-.]{1,80})\z/ or exit 1;
-($date) = $date =~ /^([0-9]{1,80})\z/ or exit 1;
 my $report = "$fatedir/$slot/$date/report.xz";
 my @recs;
 
-- 
2.25.1

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

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

Re: [FFmpeg-devel] [fateserver PATCH] Move validation of parsed slot/date into split_header from load_report

2021-09-07 Thread Nicolas George 
Martin Storsjo (12021-09-07):
> This avoids using tainted data in the call to zcat in the main loop
> in index.cgi.
> 
> This fixes the report listing for cases with a compile error.
> ---
>  FATE.pm | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)

That is even better, thanks. Applied and deployed.

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] [fateserver PATCH] Move validation of parsed slot/date into split_header from load_report

2021-09-07 Thread Andreas Rheinhardt 
Nicolas George:
> Martin Storsjo (12021-09-07):
>> This avoids using tainted data in the call to zcat in the main loop
>> in index.cgi.
>>
>> This fixes the report listing for cases with a compile error.
>> ---
>>  FATE.pm | 4 ++--
>>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> That is even better, thanks. Applied and deployed.
> 
> Regards,
> 
It works! Thanks to you and Martin for your efforts in bringing the
fateserver back.

- 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] avformat/webvttdec: skip STYLE blocks

2021-09-07 Thread Stephan Hohe 
Parsing STYLE blocks as normal subtitle data doesn't work, so
instead skip those blocks completely.

Fixes #9064
---
 libavformat/webvttdec.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/libavformat/webvttdec.c b/libavformat/webvttdec.c
index 52320ba7d1..40763b082d 100644
--- a/libavformat/webvttdec.c
+++ b/libavformat/webvttdec.c
@@ -114,6 +114,11 @@ static int webvtt_read_header(AVFormatContext *s)
 p++;
 }
 
+/* skip STYLE blocks */
+if (identifier_len == 5 && !strncmp(identifier, "STYLE", 5)) {
+continue;
+}
+
 /* cue timestamps */
 if ((ts_start = read_ts(p)) == AV_NOPTS_VALUE)
 break;
-- 
2.30.2

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

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

Re: [FFmpeg-devel] [PATCH v1 1/1] libavformat/amr.c: remove mode range check

2021-09-07 Thread Paul B Mahol 
On Tue, Sep 7, 2021 at 4:48 PM Sun Zhenliang 
wrote:

> 在 2021年9月7日 +0800 19:13，Paul B Mahol ，写道：
> > On Tue, Sep 7, 2021 at 11:36 AM Sun Zhenliang <
> hisunzhenli...@outlook.com>
> > wrote:
> >
> > > 在 2021年9月7日 +0800 14:16，Paul B Mahol ，写道：
> > > > On Tue, Sep 7, 2021 at 7:34 AM Sun Zhenliang <
> hisunzhenli...@outlook.com
> > > >
> > > > wrote:
> > > >
> > > > > 在 2021年9月7日 +0800 00:55，Paul B Mahol ，写道：
> > > > > > On Sat, Sep 4, 2021 at 1:52 PM Sun Zhenliang <
> > > hisunzhenli...@outlook.com
> > > > > >
> > > > > > wrote:
> > > > > >
> > > > > > >
> > > > > > > >
> > > > > > > > On Sep 4, 2021, at 16:01, Hendrik Leppkes <
> h.lepp...@gmail.com>
> > > > > wrote:
> > > > > > > >
> > > > > > > > On Sat, Sep 4, 2021 at 9:10 AM sunzhenliang <
> > > > > hisunzhenli...@outlook.com>
> > > > > > > wrote:
> > > > > > > > >
> > > > > > > > > Those comfort noise frames and empty frames should be
> > > > > > > > > considered the correct frame. And amr.c/amr_read_packet()
> > > > > > > > > also takes them as correct frames too.
> > > > > > > > >
> > > > > > > > > Signed-off-by: sunzhenliang 
> > > > > > > > > ---
> > > > > > > > > libavformat/amr.c | 4 ++--
> > > > > > > > > 1 file changed, 2 insertions(+), 2 deletions(-)
> > > > > > > > >
> > > > > > > > > diff --git a/libavformat/amr.c b/libavformat/amr.c
> > > > > > > > > index 836b276fd5..540d8033d8 100644
> > > > > > > > > --- a/libavformat/amr.c
> > > > > > > > > +++ b/libavformat/amr.c
> > > > > > > > > @@ -178,7 +178,7 @@ static int amrnb_probe(const
> AVProbeData
> > > *p)
> > > > > > > > >
> > > > > > > > > while (i < p->buf_size) {
> > > > > > > > > mode = b[i] >> 3 & 0x0F;
> > > > > > > > > - if (mode < 9 && (b[i] & 0x4) == 0x4) {
> > > > > > > > > + if ((b[i] & 0x4) == 0x4) {
> > > > > > > > > int last = b[i];
> > > > > > > > > int size = amrnb_packed_size[mode];
> > > > > > > > > while (size--) {
> > > > > > > > > @@ -234,7 +234,7 @@ static int amrwb_probe(const
> AVProbeData
> > > *p)
> > > > > > > > >
> > > > > > > > > while (i < p->buf_size) {
> > > > > > > > > mode = b[i] >> 3 & 0x0F;
> > > > > > > > > - if (mode < 10 && (b[i] & 0x4) == 0x4) {
> > > > > > > > > + if ((b[i] & 0x4) == 0x4) {
> > > > > > > > > int last = b[i];
> > > > > > > > > int size = amrwb_packed_size[mode];
> > > > > > > > > while (size--) {
> > > > > > > >
> > > > > > > > This is just probing, and expecting to find a significant
> amount
> > > of
> > > > > > > > non-empty/non-noise frames seems like something you would
> want in
> > > > > > > > probing.
> > > > > > > > Does this actually fix detection of any samples?
> > > > > > > >
> > > > > > > > It seems like this has the potential of quite substantially
> > > reducing
> > > > > > > > the number of checked bits and thus invalid detections.
> > > > > > > >
> > > > > > > > - Hendrik
> > > > > > > > 
> > > > > > >
> > > > > > > Thanks for reviewing.
> > > > > > >
> > > > > > > Probing is expecting to find “correct” frames, which includes
> those
> > > > > kinds
> > > > > > > of comfort noise and NO_DATA frames mentioned in 3GPP
> > > Specifications.
> > > > > > >
> > > > > > > Besides, those frames are considered as normal frames while
> reading
> > > > > > > packets. It seems better to take the same standard of frames in
> > > both
> > > > > > > reading and probing.
> > > > > > >
> > > > > > >
> > > > > > Yes, but in past IIRC it caused misdetection when probing.
> > > > > But it may cause misdetection when probing audios with many
> > > > > comfort noise and NO_DATA frames. Maybe we should stick to
> > > > > 3GPP Specifications.
> > > > >
> > > >
> > > > And at same time not broke probing for more more important formats.
> > > > Have you checked that your patch does not cause regressions?
> > > >
> > > I have done fate-test, but can not submit the results with fate_recv.
> > > I have sent the public ssh key to fate-ad...@ffmpeg.org, maybe it
> > > needs some time?
> > >
> >
> > I mean regressions not covered by FATE.
> >
> > Also you misunderstood fate-test, this patch have nothing to do with
> > sending your fate testing reports to FFmpeg.
> >
> Sorry, could you explain more in details? I am confused.
>
> I have checked this patch, which works fine with those amr files.
>

What about non-amr files mentioned in tickets in git log history of this
demuxer.


> > > >
> > > > >
> > > > > - sunzhenliang
> > > > > > > - sunzhenliang
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > ___
> > > > > > > ffmpeg-devel mailing list
> > > > > > > ffmpeg-devel@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.

Re: [FFmpeg-devel] [PATCH 1/4] libavfilter/x86/vf_hflip: add ff_flip_byte/short_avx512()

2021-09-07 Thread Paul B Mahol 
will apply soon if nobody objects
___
ffmpeg-devel mailing list
ffmpeg-devel@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] frame: add a time_base field

2021-09-07 Thread Lynne 
This adds a time_base field (currently unused), analogue to the 
AVPacket.time_base field.

Patch attached. doc/APIchanges and version bump to be done at push time.

>From c87391f77b8c4479ebea80e5bd06905c974c8e5b Mon Sep 17 00:00:00 2001
From: Lynne 
Date: Tue, 7 Sep 2021 19:24:24 +0200
Subject: [PATCH] frame: add a time_base field

This adds a time_base field (currently unused), analogue to the
AVPacket.time_base field.
---
 libavutil/frame.c | 2 ++
 libavutil/frame.h | 6 ++
 2 files changed, 8 insertions(+)

diff --git a/libavutil/frame.c b/libavutil/frame.c
index b0ceaf7145..1922e4e5c2 100644
--- a/libavutil/frame.c
+++ b/libavutil/frame.c
@@ -63,6 +63,7 @@ static void get_frame_defaults(AVFrame *frame)
 frame->pkt_duration= 0;
 frame->pkt_pos = -1;
 frame->pkt_size= -1;
+frame->time_base   = (AVRational){ 0, 1 };
 frame->key_frame   = 1;
 frame->sample_aspect_ratio = (AVRational){ 0, 1 };
 frame->format  = -1; /* unknown */
@@ -278,6 +279,7 @@ static int frame_copy_props(AVFrame *dst, const AVFrame *src, int force_copy)
 dst->pkt_pos= src->pkt_pos;
 dst->pkt_size   = src->pkt_size;
 dst->pkt_duration   = src->pkt_duration;
+dst->time_base  = src->time_base;
 dst->reordered_opaque   = src->reordered_opaque;
 dst->quality= src->quality;
 dst->best_effort_timestamp  = src->best_effort_timestamp;
diff --git a/libavutil/frame.h b/libavutil/frame.h
index ff2540a20f..93740ee0f7 100644
--- a/libavutil/frame.h
+++ b/libavutil/frame.h
@@ -402,6 +402,12 @@ typedef struct AVFrame {
  */
 int64_t pkt_dts;
 
+/**
+ * Time base for the timestamps in this frame. May be 0, in which case the
+ * time_base from the frame source should be used.
+ */
+AVRational time_base;
+
 /**
  * picture number in bitstream order
  */
-- 
2.33.0.252.g9b09ab0cd71

___
ffmpeg-devel mailing list
ffmpeg-devel@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] frame: add a time_base field

2021-09-07 Thread Andreas Rheinhardt 
Lynne:
> This adds a time_base field (currently unused), analogue to the 
> AVPacket.time_base field.
> 
> Patch attached. doc/APIchanges and version bump to be done at push time.
> 

> +/**

> + * Time base for the timestamps in this frame. May be 0, in which case 
> the

> + * time_base from the frame source should be used.

> + */

> +AVRational time_base;

> +

Does the pkt_duration count as timestamp or not?

- 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] frame: add a time_base field

2021-09-07 Thread Paul B Mahol 
On Tue, Sep 7, 2021 at 7:37 PM Andreas Rheinhardt <
andreas.rheinha...@outlook.com> wrote:

> Lynne:
> > This adds a time_base field (currently unused), analogue to the
> > AVPacket.time_base field.
> >
> > Patch attached. doc/APIchanges and version bump to be done at push time.
> >
>
> > +/**
>
> > + * Time base for the timestamps in this frame. May be 0, in which
> case the
>
> > + * time_base from the frame source should be used.
>
> > + */
>
> > +AVRational time_base;
>
> > +
>
> Does the pkt_duration count as timestamp or not?
>

While here please add frame duration too.


>
> - 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, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] frame: add a time_base field

2021-09-07 Thread Lynne 
7 Sept 2021, 19:36 by andreas.rheinha...@outlook.com:

> Lynne:
>
>> This adds a time_base field (currently unused), analogue to the 
>> AVPacket.time_base field.
>>
>> Patch attached. doc/APIchanges and version bump to be done at push time.
>>
>> +/**
>>
>> + * Time base for the timestamps in this frame. May be 0, in which case 
>> the
>>
>> + * time_base from the frame source should be used.
>>
>> + */
>>
>> +AVRational time_base;
>>
>> +
>>
>
> Does the pkt_duration count as timestamp or not?
>

Good point, it does if you think of it starting from 0 for every frame :)
Reworded to:
>    /** 
> * Time base for the timestamps and durations in this frame.
> * May be 0, in which case the time_base from the frame source should be 
>used.
> */
___
ffmpeg-devel mailing list
ffmpeg-devel@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] configure: account for openssl3 license change

2021-09-07 Thread Timo Rothenpieler 
---
 configure | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/configure b/configure
index af410a9d11..d595655325 100755
--- a/configure
+++ b/configure
@@ -1765,7 +1765,6 @@ EXTERNAL_LIBRARY_GPL_LIST="
 EXTERNAL_LIBRARY_NONFREE_LIST="
 decklink
 libfdk_aac
-openssl
 libtls
 "
 
@@ -1857,6 +1856,7 @@ EXTERNAL_LIBRARY_LIST="
 mediacodec
 openal
 opengl
+openssl
 pocketsphinx
 vapoursynth
 "
@@ -6574,7 +6574,10 @@ enabled omx_rpi   && { test_code cc OMX_Core.h 
OMX_IndexConfigBrcmVideoR
die "ERROR: OpenMAX IL headers from 
raspberrypi/firmware not found"; } &&
  enable omx
 enabled omx   && require_headers OMX_Core.h
-enabled openssl   && { check_pkg_config openssl openssl openssl/ssl.h 
OPENSSL_init_ssl ||
+enabled openssl   && { { check_pkg_config openssl "openssl >= 3.0.0" 
openssl/ssl.h OPENSSL_init_ssl &&
+ { enabled gplv3 || ! enabled gpl || enabled 
nonfree || die "ERROR: OpenSSL >=3.0.0 requires --enable-version3"; }; } ||
+   { enabled gpl && ! enabled nonfree && die 
"ERROR: OpenSSL <3.0.0 is incompatible with the gpl"; } ||
+   check_pkg_config openssl openssl openssl/ssl.h 
OPENSSL_init_ssl ||
check_pkg_config openssl openssl openssl/ssl.h 
SSL_library_init ||
check_lib openssl openssl/ssl.h 
OPENSSL_init_ssl -lssl -lcrypto ||
check_lib openssl openssl/ssl.h 
SSL_library_init -lssl -lcrypto ||
-- 
2.25.1

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

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

Re: [FFmpeg-devel] [PATCH] frame: add a time_base field

2021-09-07 Thread Marton Balint 




On Tue, 7 Sep 2021, Lynne wrote:


7 Sept 2021, 19:36 by andreas.rheinha...@outlook.com:


Lynne:

This adds a time_base field (currently unused), analogue to the 
AVPacket.time_base field.


Patch attached. doc/APIchanges and version bump to be done at push time.

+/**
+ * Time base for the timestamps in this frame. May be 0, in which case the
+ * time_base from the frame source should be used.
+ */
+AVRational time_base;


So how this is going to work? Will e.g. avcodec_send_frame check 
the time base of the frame and recalculate pts/duration to the encoder 
time base? Same goes for every function which is receiving frames?


Also I would like to point out that until the actual support for this is 
added to the libraries I don't see why we should add this, because 
sizeof(AVFrame) is not part of the ABI, so this can be added anytime.


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] frame: add a time_base field

2021-09-07 Thread Lynne 
8 Sept 2021, 01:25 by c...@passwd.hu:

>
>
> On Tue, 7 Sep 2021, Lynne wrote:
>
>> 7 Sept 2021, 19:36 by andreas.rheinha...@outlook.com:
>>
>>> Lynne:
>>>
 This adds a time_base field (currently unused), analogue to the 
 AVPacket.time_base field.

 Patch attached. doc/APIchanges and version bump to be done at push time.

 +/**
 + * Time base for the timestamps in this frame. May be 0, in which 
 case the
 + * time_base from the frame source should be used.
 + */
 +AVRational time_base;

>
> So how this is going to work? Will e.g. avcodec_send_frame check the time 
> base of the frame and recalculate pts/duration to the encoder time base? Same 
> goes for every function which is receiving frames?
>

If it's zero, it'll use the initial avctx timebase. If it's non-zero and 
different, IMO it should
warn the user that the timebase has changed and carry on as we currently do, 
with the
output packets still using the initial timebase, and the input timestamps 
unchanged.
A new AV_CODEC_CAP_DYNAMIC_TIMEBASE and
AV_CODEC_FLAG2_DYNAMIC_TIMEBASE flags may be introduced, which if supplied,
will either adapt the timestamps to the initial timebase if the encoder does 
not indicate
support via the new codec cap flag (most wrappers) or proceed to generate 
packets
with a new timebase if the encoder supports it (most native encoders).


> Also I would like to point out that until the actual support for this is 
> added to the libraries I don't see why we should add this, because 
> sizeof(AVFrame) is not part of the ABI, so this can be added anytime.
>

Right, fair enough. Consider it an RFC then.
___
ffmpeg-devel mailing list
ffmpeg-devel@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 v1 1/1] libavformat/amr.c: remove mode range check

2021-09-07 Thread Sun Zhenliang 
在 2021年9月8日 +0800 00:14，Paul B Mahol ，写道：
> On Tue, Sep 7, 2021 at 4:48 PM Sun Zhenliang 
> wrote:
>
> > 在 2021年9月7日 +0800 19:13，Paul B Mahol ，写道：
> > > On Tue, Sep 7, 2021 at 11:36 AM Sun Zhenliang <
> > hisunzhenli...@outlook.com>
> > > wrote:
> > >
> > > > 在 2021年9月7日 +0800 14:16，Paul B Mahol ，写道：
> > > > > On Tue, Sep 7, 2021 at 7:34 AM Sun Zhenliang <
> > hisunzhenli...@outlook.com
> > > > >
> > > > > wrote:
> > > > >
> > > > > > 在 2021年9月7日 +0800 00:55，Paul B Mahol ，写道：
> > > > > > > On Sat, Sep 4, 2021 at 1:52 PM Sun Zhenliang <
> > > > hisunzhenli...@outlook.com
> > > > > > >
> > > > > > > wrote:
> > > > > > >
> > > > > > > >
> > > > > > > > >
> > > > > > > > > On Sep 4, 2021, at 16:01, Hendrik Leppkes <
> > h.lepp...@gmail.com>
> > > > > > wrote:
> > > > > > > > >
> > > > > > > > > On Sat, Sep 4, 2021 at 9:10 AM sunzhenliang <
> > > > > > hisunzhenli...@outlook.com>
> > > > > > > > wrote:
> > > > > > > > > >
> > > > > > > > > > Those comfort noise frames and empty frames should be
> > > > > > > > > > considered the correct frame. And amr.c/amr_read_packet()
> > > > > > > > > > also takes them as correct frames too.
> > > > > > > > > >
> > > > > > > > > > Signed-off-by: sunzhenliang 
> > > > > > > > > > ---
> > > > > > > > > > libavformat/amr.c | 4 ++--
> > > > > > > > > > 1 file changed, 2 insertions(+), 2 deletions(-)
> > > > > > > > > >
> > > > > > > > > > diff --git a/libavformat/amr.c b/libavformat/amr.c
> > > > > > > > > > index 836b276fd5..540d8033d8 100644
> > > > > > > > > > --- a/libavformat/amr.c
> > > > > > > > > > +++ b/libavformat/amr.c
> > > > > > > > > > @@ -178,7 +178,7 @@ static int amrnb_probe(const
> > AVProbeData
> > > > *p)
> > > > > > > > > >
> > > > > > > > > > while (i < p->buf_size) {
> > > > > > > > > > mode = b[i] >> 3 & 0x0F;
> > > > > > > > > > - if (mode < 9 && (b[i] & 0x4) == 0x4) {
> > > > > > > > > > + if ((b[i] & 0x4) == 0x4) {
> > > > > > > > > > int last = b[i];
> > > > > > > > > > int size = amrnb_packed_size[mode];
> > > > > > > > > > while (size--) {
> > > > > > > > > > @@ -234,7 +234,7 @@ static int amrwb_probe(const
> > AVProbeData
> > > > *p)
> > > > > > > > > >
> > > > > > > > > > while (i < p->buf_size) {
> > > > > > > > > > mode = b[i] >> 3 & 0x0F;
> > > > > > > > > > - if (mode < 10 && (b[i] & 0x4) == 0x4) {
> > > > > > > > > > + if ((b[i] & 0x4) == 0x4) {
> > > > > > > > > > int last = b[i];
> > > > > > > > > > int size = amrwb_packed_size[mode];
> > > > > > > > > > while (size--) {
> > > > > > > > >
> > > > > > > > > This is just probing, and expecting to find a significant
> > amount
> > > > of
> > > > > > > > > non-empty/non-noise frames seems like something you would
> > want in
> > > > > > > > > probing.
> > > > > > > > > Does this actually fix detection of any samples?
> > > > > > > > >
> > > > > > > > > It seems like this has the potential of quite substantially
> > > > reducing
> > > > > > > > > the number of checked bits and thus invalid detections.
> > > > > > > > >
> > > > > > > > > - Hendrik
> > > > > > > > > 
> > > > > > > >
> > > > > > > > Thanks for reviewing.
> > > > > > > >
> > > > > > > > Probing is expecting to find “correct” frames, which includes
> > those
> > > > > > kinds
> > > > > > > > of comfort noise and NO_DATA frames mentioned in 3GPP
> > > > Specifications.
> > > > > > > >
> > > > > > > > Besides, those frames are considered as normal frames while
> > reading
> > > > > > > > packets. It seems better to take the same standard of frames in
> > > > both
> > > > > > > > reading and probing.
> > > > > > > >
> > > > > > > >
> > > > > > > Yes, but in past IIRC it caused misdetection when probing.
> > > > > > But it may cause misdetection when probing audios with many
> > > > > > comfort noise and NO_DATA frames. Maybe we should stick to
> > > > > > 3GPP Specifications.
> > > > > >
> > > > >
> > > > > And at same time not broke probing for more more important formats.
> > > > > Have you checked that your patch does not cause regressions?
> > > > >
> > > > I have done fate-test, but can not submit the results with fate_recv.
> > > > I have sent the public ssh key to fate-ad...@ffmpeg.org, maybe it
> > > > needs some time?
> > > >
> > >
> > > I mean regressions not covered by FATE.
> > >
> > > Also you misunderstood fate-test, this patch have nothing to do with
> > > sending your fate testing reports to FFmpeg.
> > >
> > Sorry, could you explain more in details? I am confused.
> >
> > I have checked this patch, which works fine with those amr files.
> >
>
> What about non-amr files mentioned in tickets in git log history of this
> demuxer.
>
Thanks for explaining, I understand now.
I have checked those tickets in git history of this demuxer
(tickets #7270, #7125, #6208, #3541).
It works fine.
> > > > >
> > > > > >
> > > > > > - sunzhenliang
> > > > > > > > - sunzhenliang
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > ___
> > > >

[FFmpeg-devel] [PATCH] avcodec/dxva2_av1: fix superres_denom parameter

2021-09-07 Thread Tong Wu 
Defined in spec 5.9.8. When superres is enabled, SuperresDenom equals
"coded_denom + SUPERRES_DENOM_MIN" instead of coded_denom.

Signed-off-by: Tong Wu 
---
 libavcodec/dxva2_av1.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavcodec/dxva2_av1.c b/libavcodec/dxva2_av1.c
index aa14e473df..c30b57799c 100644
--- a/libavcodec/dxva2_av1.c
+++ b/libavcodec/dxva2_av1.c
@@ -73,7 +73,7 @@ static int fill_picture_parameters(const AVCodecContext 
*avctx, AVDXVAContext *c
 pp->max_height = seq->max_frame_height_minus_1 + 1;
 
 pp->CurrPicTextureIndex = ff_dxva2_get_surface_index(avctx, ctx, 
h->cur_frame.tf.f);
-pp->superres_denom  = frame_header->use_superres ? 
frame_header->coded_denom : AV1_SUPERRES_NUM;
+pp->superres_denom  = frame_header->use_superres ? 
frame_header->coded_denom + AV1_SUPERRES_DENOM_MIN : AV1_SUPERRES_NUM;
 pp->bitdepth= get_bit_depth_from_seq(seq);
 pp->seq_profile = seq->seq_profile;
 
-- 
2.16.1.windows.4

___
ffmpeg-devel mailing list
ffmpeg-devel@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/dxva2_av1: fix superres_denom parameter

2021-09-07 Thread Xiang, Haihao 
On Wed, 2021-09-08 at 13:19 +0800, Tong Wu wrote:
> Defined in spec 5.9.8. When superres is enabled, SuperresDenom equals
> "coded_denom + SUPERRES_DENOM_MIN" instead of coded_denom.
> 
> Signed-off-by: Tong Wu 
> ---
>  libavcodec/dxva2_av1.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/libavcodec/dxva2_av1.c b/libavcodec/dxva2_av1.c
> index aa14e473df..c30b57799c 100644
> --- a/libavcodec/dxva2_av1.c
> +++ b/libavcodec/dxva2_av1.c
> @@ -73,7 +73,7 @@ static int fill_picture_parameters(const AVCodecContext
> *avctx, AVDXVAContext *c
>  pp->max_height = seq->max_frame_height_minus_1 + 1;
>  
>  pp->CurrPicTextureIndex = ff_dxva2_get_surface_index(avctx, ctx, h-
> >cur_frame.tf.f);
> -pp->superres_denom  = frame_header->use_superres ? frame_header-
> >coded_denom : AV1_SUPERRES_NUM;
> +pp->superres_denom  = frame_header->use_superres ? frame_header-
> >coded_denom + AV1_SUPERRES_DENOM_MIN : AV1_SUPERRES_NUM;
>  pp->bitdepth= get_bit_depth_from_seq(seq);
>  pp->seq_profile = seq->seq_profile;
>  

LGTM

-Haihao
___
ffmpeg-devel mailing list
ffmpeg-devel@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] avutils/hwcontext: When deriving a hwdevice, search for existing device in both directions

2021-09-07 Thread Chen, Wenbin 
Hi softworkz:

Any updates on this patch?
I want to submit pathes to qsv, but they depends on this patch

Thanks
Wenbin
> -Original Message-
> From: ffmpeg-devel  On Behalf Of Soft
> Works
> Sent: Thursday, August 19, 2021 3:52 PM
> To: FFmpeg development discussions and patches  de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH v2] avutils/hwcontext: When deriving a
> hwdevice, search for existing device in both directions
> 
> 
> 
> > -Original Message-
> > From: ffmpeg-devel  On Behalf Of
> Xiang,
> > Haihao
> > Sent: Thursday, 19 August 2021 09:37
> > To: ffmpeg-devel@ffmpeg.org
> > Subject: Re: [FFmpeg-devel] [PATCH v2] avutils/hwcontext: When deriving a
> > hwdevice, search for existing device in both directions
> >
> > On Fri, 2021-08-13 at 06:29 +, Xiang, Haihao wrote:
> > > On Tue, 2021-08-10 at 09:52 +, Soft Works wrote:
> > > > The test /libavutil/tests/hwdevice checks that when deriving a device
> > > > from a source device and then deriving back to the type of the source
> > > > device, the result is matching the original source device, i.e. the
> > > > derivation mechanism doesn't create a new device in this case.
> > > >
> 
> [..]
> 
> > >
> > > video:143kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB
> > muxing
> > > overhead: unknown
> > > corrupted size vs. prev_size in fastbins
> > > Aborted
> > >
> >
> > Hi Softworks,
> >
> > +child_device->internal->derived_devices[ctx->type] =
> > av_buffer_create((uint8_t*)ctx, sizeof(*ctx), 0, ctx, 0);
> >
> > The above change introduces a new AVBufferRef for ctx. The first
> AVBufferRef
> > for
> > ctx is created when function av_hwdevice_ctx_alloc is called. So there are
> > two
> > different AVBufferRefs referring to the same ctx, then ctx will be double-
> > freed
> >
> > The change below is a bit ugly, but it may fix this double-free issue.
> >
> > +static void qsv_ctx_free(void *opaque, uint8_t *ctx)
> > +{
> > +// Do nothing here
> > +// ctx is freed in hwdevice_ctx_free
> > +}
> > +
> >  static int qsv_device_create(AVHWDeviceContext *ctx, const char *device,
> >   AVDictionary *opts, int flags)
> >  {
> > @@ -1271,7 +1277,7 @@ static int qsv_device_create(AVHWDeviceContext
> *ctx,
> > const
> > char *device,
> >  ret = qsv_device_derive_from_child(ctx, impl, child_device, 0);
> >  if (ret >= 0) {
> >  ctx->internal->source_device = av_buffer_ref(priv-
> > >child_device_ctx);
> > -child_device->internal->derived_devices[ctx->type] =
> > av_buffer_create((uint8_t*)ctx, sizeof(*ctx), 0, ctx, 0);
> > +child_device->internal->derived_devices[ctx->type] =
> > av_buffer_create((uint8_t*)ctx, sizeof(*ctx), qsv_ctx_free, ctx, 0);
> >  if (!child_device->internal->derived_devices[ctx->type]) {
> >  return AVERROR(ENOMEM);
> >  }
> 
> Hi Haihao,
> 
> sorry for getting back late and thanks for your suggested fix.
> I'll apply it and submit a new patch version.
> 
> Best regards,
> softworkz
> 
> 
> 
> 
> 
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@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] libavfilter: add a gblur_vulkan filter

2021-09-07 Thread Wu Jianhua 
This commit adds a powerful and customizable gblur Vulkan filter,
which provides a maximum 127x127 kernel size of Gaussian Filter.
The size could be adjusted by requirements on quality or performance.

The following command is on how to apply gblur_vulkan filter:

ffmpeg -init_hw_device vulkan=vul:0 -filter_hw_device vul -i input.264
-vf hwupload=extra_hw_frames=16,gblur_vulkan,hwdownload,format=yuv420p
output.264

Signed-off-by: Wu Jianhua 
---
 Changelog |   2 +-
 configure |   1 +
 libavfilter/Makefile  |   1 +
 libavfilter/allfilters.c  |   1 +
 libavfilter/vf_gblur_vulkan.c | 509 ++
 5 files changed, 513 insertions(+), 1 deletion(-)
 create mode 100644 libavfilter/vf_gblur_vulkan.c

diff --git a/Changelog b/Changelog
index 5b58401183..bc36fa09e4 100644
--- a/Changelog
+++ b/Changelog
@@ -148,7 +148,7 @@ version 4.3:
 - LEGO Racers ALP (.tun & .pcm) demuxer
 - AMQP 0-9-1 protocol (RabbitMQ)
 - Vulkan support
-- avgblur_vulkan, overlay_vulkan, scale_vulkan and chromaber_vulkan filters
+- avgblur_vulkan, overlay_vulkan, scale_vulkan, chromaber_vulkan and 
gblur_vulkan filters
 - ADPCM IMA MTF decoder
 - FWSE demuxer
 - DERF DPCM decoder
diff --git a/configure b/configure
index af410a9d11..4b9a0d8e07 100755
--- a/configure
+++ b/configure
@@ -3601,6 +3601,7 @@ freezedetect_filter_select="scene_sad"
 frei0r_filter_deps="frei0r libdl"
 frei0r_src_filter_deps="frei0r libdl"
 fspp_filter_deps="gpl"
+gblur_vulkan_filter_deps="vulkan_lib libglslang"
 histeq_filter_deps="gpl"
 hqdn3d_filter_deps="gpl"
 interlace_filter_deps="gpl"
diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index af957a5ac0..5f74e33599 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -286,6 +286,7 @@ OBJS-$(CONFIG_FREEZEFRAMES_FILTER)   += 
vf_freezeframes.o
 OBJS-$(CONFIG_FREI0R_FILTER) += vf_frei0r.o
 OBJS-$(CONFIG_FSPP_FILTER)   += vf_fspp.o qp_table.o
 OBJS-$(CONFIG_GBLUR_FILTER)  += vf_gblur.o
+OBJS-$(CONFIG_GBLUR_VULKAN_FILTER)   += vf_gblur_vulkan.o vulkan.o
 OBJS-$(CONFIG_GEQ_FILTER)+= vf_geq.o
 OBJS-$(CONFIG_GRADFUN_FILTER)+= vf_gradfun.o
 OBJS-$(CONFIG_GRAPHMONITOR_FILTER)   += f_graphmonitor.o
diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c
index 0c6b2347c8..b5576de3af 100644
--- a/libavfilter/allfilters.c
+++ b/libavfilter/allfilters.c
@@ -271,6 +271,7 @@ extern const AVFilter ff_vf_freezeframes;
 extern const AVFilter ff_vf_frei0r;
 extern const AVFilter ff_vf_fspp;
 extern const AVFilter ff_vf_gblur;
+extern const AVFilter ff_vf_gblur_vulkan;
 extern const AVFilter ff_vf_geq;
 extern const AVFilter ff_vf_gradfun;
 extern const AVFilter ff_vf_graphmonitor;
diff --git a/libavfilter/vf_gblur_vulkan.c b/libavfilter/vf_gblur_vulkan.c
new file mode 100644
index 00..c1693f5d66
--- /dev/null
+++ b/libavfilter/vf_gblur_vulkan.c
@@ -0,0 +1,509 @@
+/*
+ * copyright (c) 2021 Wu Jianhua 
+ * 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 "libavutil/random_seed.h"
+#include "libavutil/opt.h"
+#include "vulkan.h"
+#include "internal.h"
+
+#define CGS 32
+#define GBLUR_MAX_KERNEL_SIZE 127
+
+typedef struct GBlurVulkanContext {
+VulkanFilterContext vkctx;
+FFVkExecContext *exec;
+VulkanPipeline *pl_hor;
+VulkanPipeline *pl_ver;
+FFVkBuffer params_buf_hor;
+FFVkBuffer params_buf_ver;
+
+VkDescriptorImageInfo input_images[3];
+VkDescriptorImageInfo tmp_images[3];
+VkDescriptorImageInfo output_images[3];
+VkDescriptorBufferInfo params_desc_hor;
+VkDescriptorBufferInfo params_desc_ver;
+
+int initialized;
+int planes;
+int kernel_size;
+int size;
+float sigma;
+float sigmaV;
+float *kernel;
+} GBlurVulkanContext;
+
+static const char gblur_horizontal[] = {
+C(0, void gblur(const ivec2 pos, const int index)  
)
+C(0, { 
)
+C(1, vec4 sum = texture(input_image[index], pos) * kernel[0];  
)
+C(0,   
)
+C

Re: [FFmpeg-devel] [PATCH v2] avutils/hwcontext: When deriving a hwdevice, search for existing device in both directions

2021-09-07 Thread Soft Works 



> -Original Message-
> From: ffmpeg-devel  On Behalf Of
> Chen, Wenbin
> Sent: Wednesday, 8 September 2021 07:58
> To: FFmpeg development discussions and patches  de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH v2] avutils/hwcontext: When
> deriving a hwdevice, search for existing device in both directions
> 
> Hi softworkz:
> 
> Any updates on this patch?
> I want to submit pathes to qsv, but they depends on this patch
> 
> Thanks
> Wenbin

Hi Wenbin,

Haihao has discovered a regression but I haven't looked into it
yet. Will do within the next few days.

softworkz
___
ffmpeg-devel mailing list
ffmpeg-devel@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/dxva2_av1: fix superres_denom parameter

2021-09-07 Thread Hendrik Leppkes 
On Wed, Sep 8, 2021 at 7:21 AM Tong Wu  wrote:
>
> Defined in spec 5.9.8. When superres is enabled, SuperresDenom equals
> "coded_denom + SUPERRES_DENOM_MIN" instead of coded_denom.
>
> Signed-off-by: Tong Wu 
> ---
>  libavcodec/dxva2_av1.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavcodec/dxva2_av1.c b/libavcodec/dxva2_av1.c
> index aa14e473df..c30b57799c 100644
> --- a/libavcodec/dxva2_av1.c
> +++ b/libavcodec/dxva2_av1.c
> @@ -73,7 +73,7 @@ static int fill_picture_parameters(const AVCodecContext 
> *avctx, AVDXVAContext *c
>  pp->max_height = seq->max_frame_height_minus_1 + 1;
>
>  pp->CurrPicTextureIndex = ff_dxva2_get_surface_index(avctx, ctx, 
> h->cur_frame.tf.f);
> -pp->superres_denom  = frame_header->use_superres ? 
> frame_header->coded_denom : AV1_SUPERRES_NUM;
> +pp->superres_denom  = frame_header->use_superres ? 
> frame_header->coded_denom + AV1_SUPERRES_DENOM_MIN : AV1_SUPERRES_NUM;
>  pp->bitdepth= get_bit_depth_from_seq(seq);
>  pp->seq_profile = seq->seq_profile;
>
> --
> 2.16.1.windows.4
>

LGTM. Confirmed in the spec. Will apply 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".