Re: [FFmpeg-devel] [PATCH 1/2] avformat/hlsenc: fall back to av_get_random_seed() when generating AES128 key

[Anton Khirnov]

Quoting Michael Niedermayer (2023-07-04 01:50:57)
> On Mon, Jul 03, 2023 at 11:09:54PM +0200, Anton Khirnov wrote:
> > Quoting Marton Balint (2023-07-03 22:54:41)
> > > On Mon, 3 Jul 2023, Anton Khirnov wrote:
> > > My patch use av_get_random_seed() which uses what the underlying OS 
> > > provides, BCrypt for Windows, /dev/urandom for Linux, arc4random() for 
> > > BSD/Mac.
> > 
> > IOW it's a jungle of various paths, some of which are not guaranteed to
> > be cryptographically secure. I see no such guarantees for arc4random()
> > from a brief web search, and the fallback get_generic_seed() certainly
> > is not either. Granted it's only used on obscure architectures, but
> > still.
> > 
> > The doxy even says
> > > This function tries to provide a good seed at a best effort bases.
> > 
> > > You really think that these are significantly worse than
> > > OpenSSL/GCrypt, so it should not be allowed to fallback to?
> > 
> > I think we should be using cryptographically secure PRNG for generating
> > encryption keys, or fail when they are not available. If you want to get
> > rid of the openssl dependency, IMO the best solution is a new
> >   int av_random(uint8_t* buf, size_t len);
> > that guarantees either cryptographically secure randomness or an error.
> 
> "guarantees cryptographically secure randomness" ?
> If one defined "cryptographically secure" as "not broken publically as of 
> today"
> 
> Iam saying that as i think "guarantees" can be misleading in what it means

I feel your snark is very much misplaced.

I recall way more instances of broken crypto caused by overconfident
non-experts with an attitude like yours ("those silly crypto libraries,
broken all the time, how hard can it be really") than by actual
vulnerabilities in actual crypto libraries.

In fact the highest-profile break I remember (Debian key entropy bug)
was caused precisely by non-experts fiddling with code they did not
understand.

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

[FFmpeg-devel] [PATCH] lavc/libvpxenc: prevent fifo from filling up

[David Lemler]

Prevent the fifo used in encoding VPx videos from filling up and stopping
encode when it reaches 21845 items, which happens when the video has more
than
that number of frames.

This problem occurs when performing the first pass of a 2-pass encode, as
otherwise, the fifo is properly drained, preventing it from overflowing.

Problem is fixed by manually draining the fifo when performing the first
pass
of a 2-pass encode.

Fixes the regression originally introduced in
5bda4ec6c3cb6f286bb40dee4457c3c26e0f78cb

Signed-off-by: David Lemler 
---
 libavcodec/libvpxenc.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/libavcodec/libvpxenc.c b/libavcodec/libvpxenc.c
index 8833df2d68..e4ab13e6ab 100644
--- a/libavcodec/libvpxenc.c
+++ b/libavcodec/libvpxenc.c
@@ -1452,6 +1452,12 @@ static int queue_frames(AVCodecContext *avctx, struct
vpx_codec_ctx *encoder,
 memcpy((uint8_t*)stats->buf + stats->sz,
pkt->data.twopass_stats.buf,
pkt->data.twopass_stats.sz);
 stats->sz += pkt->data.twopass_stats.sz;
+/* Drain the fifo if it has any items in it to prevent it from
+   filling up when performing the first pass of a 2-pass encode
if
+   the video has more than 21845 frames. */
+if (av_fifo_can_read(ctx->fifo) > 0) {
+av_fifo_drain2(ctx->fifo, 1);
+}
 break;
 }
 case VPX_CODEC_PSNR_PKT:
-- 
2.41.0.windows.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] doc/developer: Make tests a requirement

[Pierre-Anthony Lemieux]

+1

On Mon, Jul 3, 2023 at 19:32 Tomas Härdin  wrote:

> tis 2023-07-04 klockan 01:00 +0200 skrev Michael Niedermayer:
> > Suggested-by: Anton
> >
> > Signed-off-by: Michael Niedermayer 
> > ---
> >  doc/developer.texi | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/doc/developer.texi b/doc/developer.texi
> > index 0c2f2cd7d1..67f7f78e86 100644
> > --- a/doc/developer.texi
> > +++ b/doc/developer.texi
> > @@ -806,7 +806,7 @@ improves readability.
> >
> >  @item
> >  Consider adding a regression test for your code. All new modules
> > -should be covered by tests. That includes demuxers, muxers,
> > decoders, encoders
> > +must be covered by tests. That includes demuxers, muxers, decoders,
> > encoders
>
> +1
>
> /Tomas
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
>
___
ffmpeg-devel mailing list
ffmpeg-devel@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] doc/developer: Make tests a requirement

[Paul B Mahol]

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

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

Re: [FFmpeg-devel] [PATCH 1/2] avformat/hlsenc: fall back to av_get_random_seed() when generating AES128 key

[Michael Niedermayer]

On Mon, Jul 03, 2023 at 11:09:54PM +0200, Anton Khirnov wrote:
> Quoting Marton Balint (2023-07-03 22:54:41)
> > On Mon, 3 Jul 2023, Anton Khirnov wrote:
> > My patch use av_get_random_seed() which uses what the underlying OS 
> > provides, BCrypt for Windows, /dev/urandom for Linux, arc4random() for 
> > BSD/Mac.
> 
> IOW it's a jungle of various paths, some of which are not guaranteed to
> be cryptographically secure. I see no such guarantees for arc4random()
> from a brief web search, and the fallback get_generic_seed() certainly
> is not either. Granted it's only used on obscure architectures, but
> still.
> 
> The doxy even says
> > This function tries to provide a good seed at a best effort bases.
> 
> > You really think that these are significantly worse than
> > OpenSSL/GCrypt, so it should not be allowed to fallback to?
> 
> I think we should be using cryptographically secure PRNG for generating
> encryption keys, or fail when they are not available. If you want to get
> rid of the openssl dependency, IMO the best solution is a new
>   int av_random(uint8_t* buf, size_t len);
> that guarantees either cryptographically secure randomness or an error.

"guarantees cryptographically secure randomness" ?
If one defined "cryptographically secure" as "not broken publically as of today"

Iam saying that as i think "guarantees" can be misleading in what it means

thx

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

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


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

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

Re: [FFmpeg-devel] [PATCH] doc/developer: Make tests a requirement

[Tomas Härdin]

tis 2023-07-04 klockan 01:00 +0200 skrev Michael Niedermayer:
> Suggested-by: Anton
> 
> Signed-off-by: Michael Niedermayer 
> ---
>  doc/developer.texi | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/doc/developer.texi b/doc/developer.texi
> index 0c2f2cd7d1..67f7f78e86 100644
> --- a/doc/developer.texi
> +++ b/doc/developer.texi
> @@ -806,7 +806,7 @@ improves readability.
>  
>  @item
>  Consider adding a regression test for your code. All new modules
> -should be covered by tests. That includes demuxers, muxers,
> decoders, encoders
> +must be covered by tests. That includes demuxers, muxers, decoders,
> encoders

+1

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

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

Re: [FFmpeg-devel] [PATCH] lavfi/bwdif: remove interpolated sample clipping

[Thomas Mundt]

Lynne  schrieb am Di., 4. Juli 2023, 00:54:

> Jul 4, 2023, 00:08 by tmund...@gmail.com:
>
> > Am So., 2. Juli 2023 um 20:58 Uhr schrieb Lynne :
> >
> >> Jul 2, 2023, 20:41 by tmund...@gmail.com:
> >>
> >> > Am So., 2. Juli 2023 um 18:57 Uhr schrieb Lynne :
> >> >
> >> >> Jul 2, 2023, 18:54 by d...@lynne.ee:
> >> >>
> >> >> > The issue is that clipping the interpolated temporal sample against
> >> >> > the spatially predicted sample causes artifacts to appear.
> >> >> >
> >> >> > Discovered while writing the Vulkan version (where I omitted the
> >> >> > same check).
> >> >> >
> >> >> > The clipping in the code is carried over from yadif. Removing the
> >> >> > same code in yadif does not make any difference to the output.
> >> >> > I think that the check was simply ill-adapted to the new prediction
> >> >> > code and does more harm.
> >> >> >
> >> >> > I tested replacing the range clip with only an FFMAX, and only an
> >> >> > FFMIN, but in both cases, artifacts still appeared.
> >> >> >
> >> >> > Test sample 1:
> >> >> https://files.lynne.ee/testsamples/mbaff_1080i60_idx.mkvTest sample
> 2:
> >> >> https://files.lynne.ee/testsamples/mbaff_bdmv_1080i60_8slice.mkv
> >> >> >
> >> >> > Command line:
> >> >> > ./ffmpeg_g -cpuflags 0 -i  -vf bwdif=mode=send_field -c:v
> >> >> rawvideo -y .nut
> >> >> > Make sure to disable the assembly.
> >> >> >
> >> >> > Comparisons:
> >> >> > https://files.lynne.ee/bwdif_01_before.png
> >> >> > https://files.lynne.ee/bwdif_01_after.png
> >> >> > Generated from sample 1 via:
> >> >> > ffmpeg -ss 00:00:00.184 -i .nut -vf
> >> >> crop=w=420:h=240:x=700:y=300,scale=iw*2:ih*2 -y .png
> >> >> >
> >> >> > https://files.lynne.ee/bwdif_02_before.png
> >> >> > https://files.lynne.ee/bwdif_02_after.pngffmpeg -ss 00:00:00.417
> -i
> >> >> .nut -vf crop=w=420:h=240:x=1100:y=200,scale=iw*2:ih*2 -y
> >> >> .png
> >> >> >
> >> >>
> >> >> Corrected links for the second sample:
> >> >>
> >> >> https://files.lynne.ee/bwdif_02_before.png
> >> >> https://files.lynne.ee/bwdif_02_after.png
> >> >> ffmpeg -ss 00:00:00.417 -i .nut -vf
> >> >> crop=w=420:h=240:x=1100:y=200,scale=iw*2:ih*2 -y .png
> >> >>
> >> >> I'm sure I hit a newline. The artifacts are a lot more noticeable in
> the
> >> >> second sample.
> >> >>
> >> >
> >> > I developed the bwdif to achieve the best possible balance between
> speed
> >> > and quality of all different image contents from the broadcast point
> of
> >> > view. This includes moving video as well as moving and static graphic
> >> > elements. Unfortunately, the improvement of one image content often
> leads
> >> > to the degradation of another. The code you removed fundamentally
> >> > stabilizes the static graphic elements. This outweighs the slightly
> more
> >> > frequent artifacts in moving video considering the general purpose of
> the
> >> > filter.
> >> >
> >>
> >> Could you post examples? I've been unable to find any that look worse
> >> with the patch.
> >>
> >
> > Unfortunately, I no longer have most of the test material that I used
> years
> > ago at the development of the bwdif.
> > But on the quick I have this clip with an "Archiv" insert. With your
> patch
> > the letters are jumping. Without your patch they stay static.
> > https://www.dropbox.com/s/jzoezjbi3ho9nja/bwdif-test.mov?dl=1
> > ffmpeg.exe -cpuflags 0 -i "bwdif-test.mov" -vf "bwdif=1:-1:1,
> > scale=1920:1080" -sws_flags lanczos -aspect 16:9 -c:v libx264 -crf 21
> > "bwdif_original.mp4"
> > ffmpeg_lynne_patch.exe -cpuflags 0 -i "bwdif-test.mov" -vf "bwdif=1:-1:1,
> > scale=1920:1080" -sws_flags lanczos -aspect 16:9 -c:v libx264 -crf 21
> > "bwdif_lynne_patch.mp4"
> > https://www.dropbox.com/s/tonsomtkhyaha91/bwdif_original.mp4?dl=1
> > https://www.dropbox.com/s/aaj8o5yzlocu55z/bwdif_lynne_patch.mp4?dl=1
> >
>
> Can confirm the letters are jumping with my patch.
> Fair enough, consider this patch dropped. I've added the check
> in Vulkan to make that version exact to C.
> Thanks for testing and writing the filter!
>

Thanks

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

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

[FFmpeg-devel] [PATCH] doc/developer: Make tests a requirement

[Michael Niedermayer]

Suggested-by: Anton

Signed-off-by: Michael Niedermayer 
---
 doc/developer.texi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/doc/developer.texi b/doc/developer.texi
index 0c2f2cd7d1..67f7f78e86 100644
--- a/doc/developer.texi
+++ b/doc/developer.texi
@@ -806,7 +806,7 @@ improves readability.
 
 @item
 Consider adding a regression test for your code. All new modules
-should be covered by tests. That includes demuxers, muxers, decoders, encoders
+must be covered by tests. That includes demuxers, muxers, decoders, encoders
 filters, bitstream filters, parsers. If its not possible to do that, add
 an explanation why to your patchset, its ok to not test if theres a reason.
 
-- 
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] lavfi/bwdif: remove interpolated sample clipping

[Lynne]

Jul 4, 2023, 00:08 by tmund...@gmail.com:

> Am So., 2. Juli 2023 um 20:58 Uhr schrieb Lynne :
>
>> Jul 2, 2023, 20:41 by tmund...@gmail.com:
>>
>> > Am So., 2. Juli 2023 um 18:57 Uhr schrieb Lynne :
>> >
>> >> Jul 2, 2023, 18:54 by d...@lynne.ee:
>> >>
>> >> > The issue is that clipping the interpolated temporal sample against
>> >> > the spatially predicted sample causes artifacts to appear.
>> >> >
>> >> > Discovered while writing the Vulkan version (where I omitted the
>> >> > same check).
>> >> >
>> >> > The clipping in the code is carried over from yadif. Removing the
>> >> > same code in yadif does not make any difference to the output.
>> >> > I think that the check was simply ill-adapted to the new prediction
>> >> > code and does more harm.
>> >> >
>> >> > I tested replacing the range clip with only an FFMAX, and only an
>> >> > FFMIN, but in both cases, artifacts still appeared.
>> >> >
>> >> > Test sample 1:
>> >> https://files.lynne.ee/testsamples/mbaff_1080i60_idx.mkvTest sample 2:
>> >> https://files.lynne.ee/testsamples/mbaff_bdmv_1080i60_8slice.mkv
>> >> >
>> >> > Command line:
>> >> > ./ffmpeg_g -cpuflags 0 -i  -vf bwdif=mode=send_field -c:v
>> >> rawvideo -y .nut
>> >> > Make sure to disable the assembly.
>> >> >
>> >> > Comparisons:
>> >> > https://files.lynne.ee/bwdif_01_before.png
>> >> > https://files.lynne.ee/bwdif_01_after.png
>> >> > Generated from sample 1 via:
>> >> > ffmpeg -ss 00:00:00.184 -i .nut -vf
>> >> crop=w=420:h=240:x=700:y=300,scale=iw*2:ih*2 -y .png
>> >> >
>> >> > https://files.lynne.ee/bwdif_02_before.png
>> >> > https://files.lynne.ee/bwdif_02_after.pngffmpeg -ss 00:00:00.417 -i
>> >> .nut -vf crop=w=420:h=240:x=1100:y=200,scale=iw*2:ih*2 -y
>> >> .png
>> >> >
>> >>
>> >> Corrected links for the second sample:
>> >>
>> >> https://files.lynne.ee/bwdif_02_before.png
>> >> https://files.lynne.ee/bwdif_02_after.png
>> >> ffmpeg -ss 00:00:00.417 -i .nut -vf
>> >> crop=w=420:h=240:x=1100:y=200,scale=iw*2:ih*2 -y .png
>> >>
>> >> I'm sure I hit a newline. The artifacts are a lot more noticeable in the
>> >> second sample.
>> >>
>> >
>> > I developed the bwdif to achieve the best possible balance between speed
>> > and quality of all different image contents from the broadcast point of
>> > view. This includes moving video as well as moving and static graphic
>> > elements. Unfortunately, the improvement of one image content often leads
>> > to the degradation of another. The code you removed fundamentally
>> > stabilizes the static graphic elements. This outweighs the slightly more
>> > frequent artifacts in moving video considering the general purpose of the
>> > filter.
>> >
>>
>> Could you post examples? I've been unable to find any that look worse
>> with the patch.
>>
>
> Unfortunately, I no longer have most of the test material that I used years
> ago at the development of the bwdif.
> But on the quick I have this clip with an "Archiv" insert. With your patch
> the letters are jumping. Without your patch they stay static.
> https://www.dropbox.com/s/jzoezjbi3ho9nja/bwdif-test.mov?dl=1
> ffmpeg.exe -cpuflags 0 -i "bwdif-test.mov" -vf "bwdif=1:-1:1,
> scale=1920:1080" -sws_flags lanczos -aspect 16:9 -c:v libx264 -crf 21
> "bwdif_original.mp4"
> ffmpeg_lynne_patch.exe -cpuflags 0 -i "bwdif-test.mov" -vf "bwdif=1:-1:1,
> scale=1920:1080" -sws_flags lanczos -aspect 16:9 -c:v libx264 -crf 21
> "bwdif_lynne_patch.mp4"
> https://www.dropbox.com/s/tonsomtkhyaha91/bwdif_original.mp4?dl=1
> https://www.dropbox.com/s/aaj8o5yzlocu55z/bwdif_lynne_patch.mp4?dl=1
>

Can confirm the letters are jumping with my patch.
Fair enough, consider this patch dropped. I've added the check
in Vulkan to make that version exact to C.
Thanks for testing and writing the filter!
___
ffmpeg-devel mailing list
ffmpeg-devel@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 1/3] avutil/dict: add av_dict_pop

[Marvin Scholz]

On 3 Jul 2023, at 20:02, Andreas Rheinhardt wrote:

> Marvin Scholz:
>>
>>
>> On 3 Jul 2023, at 2:18, Andreas Rheinhardt wrote:
>>
>>> Marvin Scholz:
 This new API allows to remove an entry and obtain ownership of the
 key/value that was associated with the removed entry.
 ---

 Changes since v1:
 - Clarify documentation about av_free having to be used.
 - Fix fate test to not rely on specific error code value

  doc/APIchanges |  4 
  libavutil/dict.c   | 27 +++
  libavutil/dict.h   | 26 ++
  libavutil/tests/dict.c | 38 ++
  libavutil/version.h|  4 ++--
  tests/ref/fate/dict| 12 
  6 files changed, 109 insertions(+), 2 deletions(-)

 diff --git a/doc/APIchanges b/doc/APIchanges
 index f040211f7d..d55821f682 100644
 --- a/doc/APIchanges
 +++ b/doc/APIchanges
 @@ -2,6 +2,10 @@ The last version increases of all libraries were on 
 2023-02-09

  API changes, most recent first:

 +2023-06-02 - xx - lavu 58.14.100 - dict.h
 +  Add av_dict_pop() to remove an entry from a dict
 +  and get ownership of the removed key/value.
 +
  2023-05-29 - xx - lavc 60.16.100 - avcodec.h codec_id.h
Add AV_CODEC_ID_EVC, FF_PROFILE_EVC_BASELINE, and FF_PROFILE_EVC_MAIN.

 diff --git a/libavutil/dict.c b/libavutil/dict.c
 index f673977a98..ac41771994 100644
 --- a/libavutil/dict.c
 +++ b/libavutil/dict.c
 @@ -173,6 +173,33 @@ int av_dict_set_int(AVDictionary **pm, const char 
 *key, int64_t value,
  return av_dict_set(pm, key, valuestr, flags);
  }

 +int av_dict_pop(AVDictionary **pm, const char *key,
 +char **out_key, char **out_value, int flags)
 +{
 +AVDictionary *m = *pm;
 +AVDictionaryEntry *entry = NULL;
>>> Why don't you merge this initialization and the assignment below?
>>>
 +entry = (AVDictionaryEntry *)av_dict_get(m, key, NULL, flags);
 +if (!entry)
 +return AVERROR(ENOENT);
 +
 +if (out_key)
 +*out_key = entry->key;
 +else
 +av_free(entry->key);
 +
 +if (out_value)
 +*out_value = entry->value;
 +else
 +av_free(entry->value);
 +
 +*entry = m->elems[--m->count];
 +if (m && !m->count) {
>>>
>>> The check for m is completely unnecessary; Coverity will probably
>>> complain about this (because this check implies that m can be NULL, but
>>> then the line above the check would crash).
>>>
 +av_freep(>elems);
 +av_freep(pm);
 +}
 +return 0;
 +}
 +
  static int parse_key_value_pair(AVDictionary **pm, const char **buf,
  const char *key_val_sep, const char 
 *pairs_sep,
  int flags)
 diff --git a/libavutil/dict.h b/libavutil/dict.h
 index 713c9e361a..31d38dabec 100644
 --- a/libavutil/dict.h
 +++ b/libavutil/dict.h
 @@ -172,6 +172,32 @@ int av_dict_set(AVDictionary **pm, const char *key, 
 const char *value, int flags
   */
  int av_dict_set_int(AVDictionary **pm, const char *key, int64_t value, 
 int flags);

 +/**
 + * Remove the entry with the given key from the dictionary.
 + *
 + * Search for an entry matching @p key and remove it, if found. Optionally
 + * the found key and/or value can be returned using the @p out_key and
 + * @p out_value arguments.
 + *
 + * If more than one entry matches, only one entry is removed and returned
 + * on each call. Which entry is returned first in that case is undefined.
 + *
 + * @param pmPointer to a pointer to a dictionary struct.
 + * @param key   Entry key to match.
 + * @param out_key   Pointer whose pointee will be set to the matched
 + *  entry key. Must be freed using av_dict_free() by
>>>
>>> This is wrong: It must be freed using av_free() (or av_freep()); same below.
>>
>> Indeed, copy paste mistake, sorry.
>>
>>>
 + *  the caller. May be NULL.
 + * @param out_value Pointer whose pointee will be set to the matched
 + *  entry value. Must be freed using av_dict_free() by
 + *  the caller. May be NULL.
 + *
 + * @retval 0Success
 + * @retval AVERROR(ENOENT)  No item for the given key found
 + * @retval "Other (negative) AVERROR"   Other failure
 + */
 +int av_dict_pop(AVDictionary **pm, const char *key,
 +char **out_key, char **out_value, int flags);
>>>
>>> It is possible to store multiple entries with the same value in an
>>> AVDictionary. This function is not designed to handle this case, as one

[FFmpeg-devel] [PATCH] avcodec/v4l2_context: always log POLLERR when buffers are uninitialized

[Richard Acayan]

The error handler for POLLERRs assumes that the timeout is only zero
when v4l2_dequeue_v4l2buf is called by v4l2_getfree_v4l2buf. This
assumption is incorrect, as ff_v4l2_context_dequeue_frame also calls
this function with a timeout of zero. Do not check for unavailable
buffers if the buffers are uninitialized.

See https://trac.ffmpeg.org/ticket/9957 for the original bug report.

Signed-off-by: Richard Acayan 
---
 libavcodec/v4l2_context.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavcodec/v4l2_context.c b/libavcodec/v4l2_context.c
index a40be94690..69ddf80723 100644
--- a/libavcodec/v4l2_context.c
+++ b/libavcodec/v4l2_context.c
@@ -327,7 +327,7 @@ start:
 if (pfd.revents & POLLERR) {
 /* if we are trying to get free buffers but none have been queued yet
no need to raise a warning */
-if (timeout == 0) {
+if (timeout == 0 && ctx->buffers) {
 for (i = 0; i < ctx->num_buffers; i++) {
 if (ctx->buffers[i].status != V4L2BUF_AVAILABLE)
 av_log(logger(ctx), AV_LOG_WARNING, "%s POLLERR\n", 
ctx->name);
-- 
2.41.0

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

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

[FFmpeg-devel] [PATCH] fftools/ffmpeg: fix negative timestamps at the beginning of the encoding

[Marton Balint]

Also fix a couple of possible overflows while at it.

Fixes the negative initial timestamps in ticket #10358.

Signed-off-by: Marton Balint 
---
 fftools/ffmpeg.c | 26 +-
 1 file changed, 13 insertions(+), 13 deletions(-)

diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
index 435e12a37b..71d4067a6c 100644
--- a/fftools/ffmpeg.c
+++ b/fftools/ffmpeg.c
@@ -497,11 +497,12 @@ static void print_report(int is_last_report, int64_t 
timer_start, int64_t cur_ti
 int vid;
 double bitrate;
 double speed;
-int64_t pts = INT64_MIN + 1;
+int64_t pts = AV_NOPTS_VALUE;
 static int64_t last_time = -1;
 static int first_report = 1;
 uint64_t nb_frames_dup = 0, nb_frames_drop = 0;
-int hours, mins, secs, us;
+int mins, secs, us;
+int64_t hours;
 const char *hours_sign;
 int ret;
 float t;
@@ -553,7 +554,8 @@ static void print_report(int is_last_report, int64_t 
timer_start, int64_t cur_ti
 }
 /* compute min output value */
 if (ost->last_mux_dts != AV_NOPTS_VALUE) {
-pts = FFMAX(pts, ost->last_mux_dts);
+if (pts == AV_NOPTS_VALUE || ost->last_mux_dts > pts)
+pts = ost->last_mux_dts;
 if (copy_ts) {
 if (copy_ts_first_pts == AV_NOPTS_VALUE && pts > 1)
 copy_ts_first_pts = pts;
@@ -566,23 +568,21 @@ static void print_report(int is_last_report, int64_t 
timer_start, int64_t cur_ti
 nb_frames_drop += ost->last_dropped;
 }
 
-secs = FFABS(pts) / AV_TIME_BASE;
-us = FFABS(pts) % AV_TIME_BASE;
-mins = secs / 60;
-secs %= 60;
-hours = mins / 60;
-mins %= 60;
+us= FFABS64U(pts) % AV_TIME_BASE;
+secs  = FFABS64U(pts) / AV_TIME_BASE % 60;
+mins  = FFABS64U(pts) / AV_TIME_BASE / 60 % 60;
+hours = FFABS64U(pts) / AV_TIME_BASE / 3600;
 hours_sign = (pts < 0) ? "-" : "";
 
-bitrate = pts && total_size >= 0 ? total_size * 8 / (pts / 1000.0) : -1;
-speed = t != 0.0 ? (double)pts / AV_TIME_BASE / t : -1;
+bitrate = pts != AV_NOPTS_VALUE && pts && total_size >= 0 ? total_size * 8 
/ (pts / 1000.0) : -1;
+speed   = pts != AV_NOPTS_VALUE && t != 0.0 ? (double)pts / AV_TIME_BASE / 
t : -1;
 
 if (total_size < 0) av_bprintf(, "size=N/A time=");
 elseav_bprintf(, "size=%8.0fkB time=", total_size / 
1024.0);
 if (pts == AV_NOPTS_VALUE) {
 av_bprintf(, "N/A ");
 } else {
-av_bprintf(, "%s%02d:%02d:%02d.%02d ",
+av_bprintf(, "%s%02"PRId64":%02d:%02d.%02d ",
hours_sign, hours, mins, secs, (100 * us) / AV_TIME_BASE);
 }
 
@@ -603,7 +603,7 @@ static void print_report(int is_last_report, int64_t 
timer_start, int64_t cur_ti
 } else {
 av_bprintf(_script, "out_time_us=%"PRId64"\n", pts);
 av_bprintf(_script, "out_time_ms=%"PRId64"\n", pts);
-av_bprintf(_script, "out_time=%s%02d:%02d:%02d.%06d\n",
+av_bprintf(_script, "out_time=%s%02"PRId64":%02d:%02d.%06d\n",
hours_sign, hours, mins, secs, us);
 }
 
-- 
2.35.3

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

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

Re: [FFmpeg-devel] [PATCH v2 12/15] avfilter/vf_bwdif: Add a filter_line3 method for optimisation

[Thomas Mundt]

Am Mo., 3. Juli 2023 um 10:27 Uhr schrieb John Cox :

> On Mon, 3 Jul 2023 00:12:46 +0300 (EEST), you wrote:
>
> >On Sun, 2 Jul 2023, Thomas Mundt wrote:
> >
> >> Am So., 2. Juli 2023 um 14:34 Uhr schrieb John Cox :
> >>   Add an optional filter_line3 to the available optimisations.
> >>
> >>   filter_line3 is equivalent to filter_line, memcpy, filter_line
> >>
> >>   filter_line shares quite a number of loads and some calculations
> >>   in
> >>   common with its next iteration and testing shows that using
> >>   aarch64
> >>   neon filter_line3s performance is 30% better than two
> >>   filter_lines
> >>   and a memcpy.
> >>
> >>   Signed-off-by: John Cox 
> >>   ---
> >>libavfilter/bwdif.h|  7 +++
> >>libavfilter/vf_bwdif.c | 31 +++
> >>2 files changed, 38 insertions(+)
> >>
> >>   diff --git a/libavfilter/bwdif.h b/libavfilter/bwdif.h
> >>   index cce99953f3..496cec72ef 100644
> >>   --- a/libavfilter/bwdif.h
> >>   +++ b/libavfilter/bwdif.h
> >>   @@ -35,6 +35,9 @@ typedef struct BWDIFContext {
> >>void (*filter_edge)(void *dst, void *prev, void *cur, void
> >>   *next,
> >>int w, int prefs, int mrefs, int
> >>   prefs2, int mrefs2,
> >>int parity, int clip_max, int spat);
> >>   +void (*filter_line3)(void *dst, int dstride,
> >>   + const void *prev, const void *cur,
> >>   const void *next, int prefs,
> >>   + int w, int parity, int clip_max);
> >>} BWDIFContext;
> >>
> >>void ff_bwdif_init_filter_line(BWDIFContext *bwdif, int
> >>   bit_depth);
> >>   @@ -53,4 +56,8 @@ void ff_bwdif_filter_line_c(void *dst1, void
> >>   *prev1, void *cur1, void *next1,
> >>int prefs3, int mrefs3, int prefs4,
> >>   int mrefs4,
> >>int parity, int clip_max);
> >>
> >>   +void ff_bwdif_filter_line3_c(void * dst1, int d_stride,
> >>   + const void * prev1, const void *
> >>   cur1, const void * next1, int s_stride,
> >>   + int w, int parity, int clip_max);
> >>   +
> >>#endif /* AVFILTER_BWDIF_H */
> >>   diff --git a/libavfilter/vf_bwdif.c b/libavfilter/vf_bwdif.c
> >>   index 26349da1fd..52bc676cf8 100644
> >>   --- a/libavfilter/vf_bwdif.c
> >>   +++ b/libavfilter/vf_bwdif.c
> >>   @@ -150,6 +150,31 @@ void ff_bwdif_filter_line_c(void *dst1,
> >>   void *prev1, void *cur1, void *next1,
> >>FILTER2()
> >>}
> >>
> >>   +#define NEXT_LINE()\
> >>   +dst += d_stride; \
> >>   +prev += prefs; \
> >>   +cur  += prefs; \
> >>   +next += prefs;
> >>   +
> >>   +void ff_bwdif_filter_line3_c(void * dst1, int d_stride,
> >>   + const void * prev1, const void *
> >>   cur1, const void * next1, int s_stride,
> >>   + int w, int parity, int clip_max)
> >>   +{
> >>   +const int prefs = s_stride;
> >>   +uint8_t * dst  = dst1;
> >>   +const uint8_t * prev = prev1;
> >>   +const uint8_t * cur  = cur1;
> >>   +const uint8_t * next = next1;
> >>   +
> >>   +ff_bwdif_filter_line_c(dst, (void*)prev, (void*)cur,
> >>   (void*)next, w,
> >>   +   prefs, -prefs, prefs * 2, - prefs *
> >>   2, prefs * 3, -prefs * 3, prefs * 4, -prefs * 4, parity,
> >>   clip_max);
> >>   +NEXT_LINE();
> >>   +memcpy(dst, cur, w);
> >>   +NEXT_LINE();
> >>   +ff_bwdif_filter_line_c(dst, (void*)prev, (void*)cur,
> >>   (void*)next, w,
> >>   +   prefs, -prefs, prefs * 2, - prefs *
> >>   2, prefs * 3, -prefs * 3, prefs * 4, -prefs * 4, parity,
> >>   clip_max);
> >>   +}
> >>   +
> >>void ff_bwdif_filter_edge_c(void *dst1, void *prev1, void
> >>   *cur1, void *next1,
> >>int w, int prefs, int mrefs, int
> >>   prefs2, int mrefs2,
> >>int parity, int clip_max, int spat)
> >>   @@ -244,6 +269,11 @@ static int filter_slice(AVFilterContext
> >>   *ctx, void *arg, int jobnr, int nb_jobs)
> >>   refs << 1, -(refs << 1),
> >>   td->parity ^ td->tff, clip_max,
> >>   (y < 2) || ((y + 3) > td->h) ? 0
> >>   : 1);
> >>   +} else if (s->filter_line3 && y + 2 < slice_end &&
> >>   y + 6 < td->h) {
> >>   +s->filter_line3(dst,
> >>   td->frame->linesize[td->plane],
> >>   +prev, cur, next, linesize,
> >>  

Re: [FFmpeg-devel] [PATCH] lavfi/bwdif: remove interpolated sample clipping

[Thomas Mundt]

Am So., 2. Juli 2023 um 20:58 Uhr schrieb Lynne :

> Jul 2, 2023, 20:41 by tmund...@gmail.com:
>
> > Am So., 2. Juli 2023 um 18:57 Uhr schrieb Lynne :
> >
> >> Jul 2, 2023, 18:54 by d...@lynne.ee:
> >>
> >> > The issue is that clipping the interpolated temporal sample against
> >> > the spatially predicted sample causes artifacts to appear.
> >> >
> >> > Discovered while writing the Vulkan version (where I omitted the
> >> > same check).
> >> >
> >> > The clipping in the code is carried over from yadif. Removing the
> >> > same code in yadif does not make any difference to the output.
> >> > I think that the check was simply ill-adapted to the new prediction
> >> > code and does more harm.
> >> >
> >> > I tested replacing the range clip with only an FFMAX, and only an
> >> > FFMIN, but in both cases, artifacts still appeared.
> >> >
> >> > Test sample 1:
> >> https://files.lynne.ee/testsamples/mbaff_1080i60_idx.mkvTest sample 2:
> >> https://files.lynne.ee/testsamples/mbaff_bdmv_1080i60_8slice.mkv
> >> >
> >> > Command line:
> >> > ./ffmpeg_g -cpuflags 0 -i  -vf bwdif=mode=send_field -c:v
> >> rawvideo -y .nut
> >> > Make sure to disable the assembly.
> >> >
> >> > Comparisons:
> >> > https://files.lynne.ee/bwdif_01_before.png
> >> > https://files.lynne.ee/bwdif_01_after.png
> >> > Generated from sample 1 via:
> >> > ffmpeg -ss 00:00:00.184 -i .nut -vf
> >> crop=w=420:h=240:x=700:y=300,scale=iw*2:ih*2 -y .png
> >> >
> >> > https://files.lynne.ee/bwdif_02_before.png
> >> > https://files.lynne.ee/bwdif_02_after.pngffmpeg -ss 00:00:00.417 -i
> >> .nut -vf crop=w=420:h=240:x=1100:y=200,scale=iw*2:ih*2 -y
> >> .png
> >> >
> >>
> >> Corrected links for the second sample:
> >>
> >> https://files.lynne.ee/bwdif_02_before.png
> >> https://files.lynne.ee/bwdif_02_after.png
> >> ffmpeg -ss 00:00:00.417 -i .nut -vf
> >> crop=w=420:h=240:x=1100:y=200,scale=iw*2:ih*2 -y .png
> >>
> >> I'm sure I hit a newline. The artifacts are a lot more noticeable in the
> >> second sample.
> >>
> >
> > I developed the bwdif to achieve the best possible balance between speed
> > and quality of all different image contents from the broadcast point of
> > view. This includes moving video as well as moving and static graphic
> > elements. Unfortunately, the improvement of one image content often leads
> > to the degradation of another. The code you removed fundamentally
> > stabilizes the static graphic elements. This outweighs the slightly more
> > frequent artifacts in moving video considering the general purpose of the
> > filter.
> >
>
> Could you post examples? I've been unable to find any that look worse
> with the patch.
>

Unfortunately, I no longer have most of the test material that I used years
ago at the development of the bwdif.
But on the quick I have this clip with an "Archiv" insert. With your patch
the letters are jumping. Without your patch they stay static.
https://www.dropbox.com/s/jzoezjbi3ho9nja/bwdif-test.mov?dl=1
ffmpeg.exe -cpuflags 0 -i "bwdif-test.mov" -vf "bwdif=1:-1:1,
scale=1920:1080" -sws_flags lanczos -aspect 16:9 -c:v libx264 -crf 21
"bwdif_original.mp4"
ffmpeg_lynne_patch.exe -cpuflags 0 -i "bwdif-test.mov" -vf "bwdif=1:-1:1,
scale=1920:1080" -sws_flags lanczos -aspect 16:9 -c:v libx264 -crf 21
"bwdif_lynne_patch.mp4"
https://www.dropbox.com/s/tonsomtkhyaha91/bwdif_original.mp4?dl=1
https://www.dropbox.com/s/aaj8o5yzlocu55z/bwdif_lynne_patch.mp4?dl=1

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

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

Re: [FFmpeg-devel] [PATCH 1/2] avformat/hlsenc: fall back to av_get_random_seed() when generating AES128 key

[Marton Balint]

On Mon, 3 Jul 2023, Anton Khirnov wrote:


Quoting Marton Balint (2023-07-03 22:54:41)

On Mon, 3 Jul 2023, Anton Khirnov wrote:
My patch use av_get_random_seed() which uses what the underlying OS
provides, BCrypt for Windows, /dev/urandom for Linux, arc4random() for
BSD/Mac.


IOW it's a jungle of various paths, some of which are not guaranteed to
be cryptographically secure. I see no such guarantees for arc4random()


It depends on OS and version most likely.


from a brief web search, and the fallback get_generic_seed() certainly
is not either.
Granted it's only used on obscure architectures, but
still.


I am no expert on the subject, but even the generic code seems reasonably 
secure. It gathers entropy, it uses a crypto hash to get the output. And 
as you said, even that only used for obscure cases.




The doxy even says

This function tries to provide a good seed at a best effort bases.



You really think that these are significantly worse than
OpenSSL/GCrypt, so it should not be allowed to fallback to?


I think we should be using cryptographically secure PRNG for generating
encryption keys, or fail when they are not available. If you want to get
rid of the openssl dependency, IMO the best solution is a new
 int av_random(uint8_t* buf, size_t len);
that guarantees either cryptographically secure randomness or an error.


Sorry, seems a bit overdesign for me, so I won't be pursuing this further.

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 1/2] avformat/hlsenc: fall back to av_get_random_seed() when generating AES128 key

[Anton Khirnov]

Quoting Marton Balint (2023-07-03 22:54:41)
> On Mon, 3 Jul 2023, Anton Khirnov wrote:
> My patch use av_get_random_seed() which uses what the underlying OS 
> provides, BCrypt for Windows, /dev/urandom for Linux, arc4random() for 
> BSD/Mac.

IOW it's a jungle of various paths, some of which are not guaranteed to
be cryptographically secure. I see no such guarantees for arc4random()
from a brief web search, and the fallback get_generic_seed() certainly
is not either. Granted it's only used on obscure architectures, but
still.

The doxy even says
> This function tries to provide a good seed at a best effort bases.

> You really think that these are significantly worse than
> OpenSSL/GCrypt, so it should not be allowed to fallback to?

I think we should be using cryptographically secure PRNG for generating
encryption keys, or fail when they are not available. If you want to get
rid of the openssl dependency, IMO the best solution is a new
  int av_random(uint8_t* buf, size_t len);
that guarantees either cryptographically secure randomness or an error.

-- 
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/2] avformat/hlsenc: fall back to av_get_random_seed() when generating AES128 key

[Marton Balint]

On Mon, 3 Jul 2023, Anton Khirnov wrote:


Quoting James Almer (2023-07-03 21:33:04)

On 7/2/2023 4:30 PM, Marton Balint wrote:

It should be OK to use av_get_random_seed() to generate the key instead of
using openSSL/Gcrypt functions. This removes the hard dependancy of those libs
for key generation functionality.

Fixes ticket #10441.

Signed-off-by: Marton Balint 
---
  libavformat/hlsenc.c | 18 --
  1 file changed, 8 insertions(+), 10 deletions(-)

diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
index 1e0848ce3d..0b22c71186 100644
--- a/libavformat/hlsenc.c
+++ b/libavformat/hlsenc.c
@@ -40,6 +40,7 @@
  #include "libavutil/intreadwrite.h"
  #include "libavutil/opt.h"
  #include "libavutil/log.h"
+#include "libavutil/random_seed.h"
  #include "libavutil/time.h"
  #include "libavutil/time_internal.h"

@@ -710,18 +711,18 @@ fail:
  return ret;
  }

-static int randomize(uint8_t *buf, int len)
+static void randomize(uint8_t *buf, int len)
  {
  #if CONFIG_GCRYPT
  gcry_randomize(buf, len, GCRY_VERY_STRONG_RANDOM);
-return 0;
+return;
  #elif CONFIG_OPENSSL
  if (RAND_bytes(buf, len))
-return 0;
-#else
-return AVERROR(ENOSYS);
+return;
  #endif
-return AVERROR(EINVAL);
+av_assert0(len % 4 == 0);
+for (int i = 0; i < len; i += 4)
+AV_WB32(buf + i, av_get_random_seed());


Maybe instead use a PRNG, like the following:

AVLFG c;
av_lfg_init(, av_get_random_seed());
for (int i = 0; i < len; i += 4)
 AV_WB32(buf + i, av_lfg_get());


We really REALLY should not be taking any shortcuts when generating
keys.

Ideally we shouldn't be generating them ourselves in the first place, as
we are not a crypto library. This patch seems like a step backward to
me.


My patch use av_get_random_seed() which uses what the underlying OS 
provides, BCrypt for Windows, /dev/urandom for Linux, arc4random() for 
BSD/Mac. You really think that these are significantly worse than 
OpenSSL/GCrypt, so it should not be allowed to fallback to?


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 1/2] avformat/hlsenc: fall back to av_get_random_seed() when generating AES128 key

[Marton Balint]

On Mon, 3 Jul 2023, James Almer wrote:


On 7/2/2023 4:30 PM, Marton Balint wrote:

 It should be OK to use av_get_random_seed() to generate the key instead of
 using openSSL/Gcrypt functions. This removes the hard dependancy of those
 libs
 for key generation functionality.

 Fixes ticket #10441.

 Signed-off-by: Marton Balint 
 ---
   libavformat/hlsenc.c | 18 --
   1 file changed, 8 insertions(+), 10 deletions(-)

 diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
 index 1e0848ce3d..0b22c71186 100644
 --- a/libavformat/hlsenc.c
 +++ b/libavformat/hlsenc.c
 @@ -40,6 +40,7 @@
   #include "libavutil/intreadwrite.h"
   #include "libavutil/opt.h"
   #include "libavutil/log.h"
 +#include "libavutil/random_seed.h"
   #include "libavutil/time.h"
   #include "libavutil/time_internal.h"

 @@ -710,18 +711,18 @@ fail:
   return ret;
   }

 -static int randomize(uint8_t *buf, int len)
 +static void randomize(uint8_t *buf, int len)
   {
   #if CONFIG_GCRYPT
   gcry_randomize(buf, len, GCRY_VERY_STRONG_RANDOM);
 -return 0;
 +return;
   #elif CONFIG_OPENSSL
   if (RAND_bytes(buf, len))
 -return 0;
 -#else
 -return AVERROR(ENOSYS);
 +return;
   #endif
 -return AVERROR(EINVAL);
 +av_assert0(len % 4 == 0);
 +for (int i = 0; i < len; i += 4)
 +AV_WB32(buf + i, av_get_random_seed());


Maybe instead use a PRNG, like the following:

AVLFG c;
av_lfg_init(, av_get_random_seed());
for (int i = 0; i < len; i += 4)
   AV_WB32(buf + i, av_lfg_get());


If randomize() were to be used for arbitrary lengths, I'd agree, but here 
it is only used for key generation (only 128-bit keys in the current 
code), so I think av_get_random_seed() for the whole keysize is fine, and 
more secure.


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 1/2] avformat/hlsenc: fall back to av_get_random_seed() when generating AES128 key

[Anton Khirnov]

Quoting James Almer (2023-07-03 21:33:04)
> On 7/2/2023 4:30 PM, Marton Balint wrote:
> > It should be OK to use av_get_random_seed() to generate the key instead of
> > using openSSL/Gcrypt functions. This removes the hard dependancy of those 
> > libs
> > for key generation functionality.
> > 
> > Fixes ticket #10441.
> > 
> > Signed-off-by: Marton Balint 
> > ---
> >   libavformat/hlsenc.c | 18 --
> >   1 file changed, 8 insertions(+), 10 deletions(-)
> > 
> > diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
> > index 1e0848ce3d..0b22c71186 100644
> > --- a/libavformat/hlsenc.c
> > +++ b/libavformat/hlsenc.c
> > @@ -40,6 +40,7 @@
> >   #include "libavutil/intreadwrite.h"
> >   #include "libavutil/opt.h"
> >   #include "libavutil/log.h"
> > +#include "libavutil/random_seed.h"
> >   #include "libavutil/time.h"
> >   #include "libavutil/time_internal.h"
> >   
> > @@ -710,18 +711,18 @@ fail:
> >   return ret;
> >   }
> >   
> > -static int randomize(uint8_t *buf, int len)
> > +static void randomize(uint8_t *buf, int len)
> >   {
> >   #if CONFIG_GCRYPT
> >   gcry_randomize(buf, len, GCRY_VERY_STRONG_RANDOM);
> > -return 0;
> > +return;
> >   #elif CONFIG_OPENSSL
> >   if (RAND_bytes(buf, len))
> > -return 0;
> > -#else
> > -return AVERROR(ENOSYS);
> > +return;
> >   #endif
> > -return AVERROR(EINVAL);
> > +av_assert0(len % 4 == 0);
> > +for (int i = 0; i < len; i += 4)
> > +AV_WB32(buf + i, av_get_random_seed());
> 
> Maybe instead use a PRNG, like the following:
> 
> AVLFG c;
> av_lfg_init(, av_get_random_seed());
> for (int i = 0; i < len; i += 4)
>  AV_WB32(buf + i, av_lfg_get());

We really REALLY should not be taking any shortcuts when generating
keys.

Ideally we shouldn't be generating them ourselves in the first place, as
we are not a crypto library. This patch seems like a step backward to
me.

-- 
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] libswscale/riscv: Fix syntax of vsetvli

[Rémi Denis-Courmont]

Le maanantaina 3. heinäkuuta 2023, 18.52.13 EEST Khem Raj a écrit :
> > *Hopefully* LLVM gets their act together by release 16, and ship a usable
> > assembler, rather than tell us to use automatic RVV vectorisation (which
> > *is* a release 16 feature, though it was half-baked last time I tried).
> I am on clang/llvm trunk ( future 17.0 release ), I will also open an
> issue with llvm on github regarding this.

If I were you, I would first open an issue on the riscv-v-spec Github to seek 
clarification (though I'm not sure if it's open for bug submission?).

> > >Fixes building with clang
> > 
> > More like bug-compatible work-around than fix, AFAIU.
> 
> I can do it although I did not find a relevant section in spec about
> these being optional, I did see examples omitting them though.
> 
> > >| src/libswscale/riscv/rgb2rgb_rvv.S:88:25: error: operand must be
> > >| e[8|16|32|64|128|256|512|1024],m[1|2|4|8|f2|f4|f8],[ta|tu],[ma|mu]> 
> > Do you have a reference to the Github RVV spec to validate this, that I
> > overlooked, or it's just misled and misleading spew from LLVM?
> Perhaps the latter but I also did not see reference to the former.
> Here is a small example
> 
> a.S
> #.option arch, +zve32x
> # OK
> #vsetvli t4, t3, e8, m1, ta, ma
> # BAD
> vsetvli t4, t3, e8, ta, ma
> 
> clang -target riscv64 -march=rv64izve32x1p0  a.S -c

Well, yes but the idea is to keep V disabled in the target flags, and do run-
time detection... Especially so far, while RVV hardware remains unobtainium, 
the compiler can't assume that V is supported, or else...

And so LLVM AS has been so far unusable for both FFmpeg and kernel alike.

-- 
雷米‧德尼-库尔蒙
http://www.remlab.net/



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

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

Re: [FFmpeg-devel] [PATCH 1/2] avformat/hlsenc: fall back to av_get_random_seed() when generating AES128 key

[James Almer]

On 7/2/2023 4:30 PM, Marton Balint wrote:

It should be OK to use av_get_random_seed() to generate the key instead of
using openSSL/Gcrypt functions. This removes the hard dependancy of those libs
for key generation functionality.

Fixes ticket #10441.

Signed-off-by: Marton Balint 
---
  libavformat/hlsenc.c | 18 --
  1 file changed, 8 insertions(+), 10 deletions(-)

diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
index 1e0848ce3d..0b22c71186 100644
--- a/libavformat/hlsenc.c
+++ b/libavformat/hlsenc.c
@@ -40,6 +40,7 @@
  #include "libavutil/intreadwrite.h"
  #include "libavutil/opt.h"
  #include "libavutil/log.h"
+#include "libavutil/random_seed.h"
  #include "libavutil/time.h"
  #include "libavutil/time_internal.h"
  
@@ -710,18 +711,18 @@ fail:

  return ret;
  }
  
-static int randomize(uint8_t *buf, int len)

+static void randomize(uint8_t *buf, int len)
  {
  #if CONFIG_GCRYPT
  gcry_randomize(buf, len, GCRY_VERY_STRONG_RANDOM);
-return 0;
+return;
  #elif CONFIG_OPENSSL
  if (RAND_bytes(buf, len))
-return 0;
-#else
-return AVERROR(ENOSYS);
+return;
  #endif
-return AVERROR(EINVAL);
+av_assert0(len % 4 == 0);
+for (int i = 0; i < len; i += 4)
+AV_WB32(buf + i, av_get_random_seed());


Maybe instead use a PRNG, like the following:

AVLFG c;
av_lfg_init(, av_get_random_seed());
for (int i = 0; i < len; i += 4)
AV_WB32(buf + i, av_lfg_get());
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

[FFmpeg-devel] [PATCH v2 09/10] lavc/decode: move submitting input packets to bitstream filters

[Anton Khirnov]

Do it from ff_decode_get_packet() rather than from
avcodec_send_packet(). This way all nontrivial stages of the decoding
pipeline (i.e. other than just placing a packet at its entrance) are
pull-based rather than a mix of push an pull.
---
 libavcodec/decode.c | 37 +++--
 1 file changed, 27 insertions(+), 10 deletions(-)

diff --git a/libavcodec/decode.c b/libavcodec/decode.c
index 47714a9393..89c3c2a48d 100644
--- a/libavcodec/decode.c
+++ b/libavcodec/decode.c
@@ -48,6 +48,7 @@
 #include "decode.h"
 #include "hwconfig.h"
 #include "internal.h"
+#include "packet_internal.h"
 #include "thread.h"
 
 typedef struct DecodeContext {
@@ -200,14 +201,11 @@ fail:
 return ret;
 }
 
-int ff_decode_get_packet(AVCodecContext *avctx, AVPacket *pkt)
+static int decode_get_packet(AVCodecContext *avctx, AVPacket *pkt)
 {
 AVCodecInternal *avci = avctx->internal;
 int ret;
 
-if (avci->draining)
-return AVERROR_EOF;
-
 ret = av_bsf_receive_packet(avci->bsf, pkt);
 if (ret == AVERROR_EOF)
 avci->draining = 1;
@@ -230,6 +228,31 @@ finish:
 return ret;
 }
 
+int ff_decode_get_packet(AVCodecContext *avctx, AVPacket *pkt)
+{
+AVCodecInternal *avci = avctx->internal;
+DecodeContext *dc = decode_ctx(avci);
+
+if (avci->draining)
+return AVERROR_EOF;
+
+while (1) {
+int ret = decode_get_packet(avctx, pkt);
+if (ret == AVERROR(EAGAIN) &&
+(!AVPACKET_IS_EMPTY(avci->buffer_pkt) || dc->draining_started)) {
+ret = av_bsf_send_packet(avci->bsf, avci->buffer_pkt);
+if (ret < 0) {
+av_packet_unref(avci->buffer_pkt);
+return ret;
+}
+
+continue;
+}
+
+return ret;
+}
+}
+
 /**
  * Attempt to guess proper monotonic timestamps for decoded video frames
  * which might have incorrect times. Input timestamps may wrap around, in
@@ -651,12 +674,6 @@ int attribute_align_arg avcodec_send_packet(AVCodecContext 
*avctx, const AVPacke
 } else
 dc->draining_started = 1;
 
-ret = av_bsf_send_packet(avci->bsf, avci->buffer_pkt);
-if (ret < 0) {
-av_packet_unref(avci->buffer_pkt);
-return ret;
-}
-
 if (!avci->buffer_frame->buf[0]) {
 ret = decode_receive_frame_internal(avctx, avci->buffer_frame);
 if (ret < 0 && ret != AVERROR(EAGAIN) && ret != AVERROR_EOF)
-- 
2.40.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 v2 06/10] lavc: move AVCodecInternal.last_audio_frame to EncodeContext

[Anton Khirnov]

It does not need to be visible outside of encode.c.
---
 libavcodec/encode.c   | 13 ++---
 libavcodec/internal.h |  6 --
 2 files changed, 10 insertions(+), 9 deletions(-)

diff --git a/libavcodec/encode.c b/libavcodec/encode.c
index 6da5d86ea0..58eab5b001 100644
--- a/libavcodec/encode.c
+++ b/libavcodec/encode.c
@@ -42,6 +42,12 @@ typedef struct EncodeContext {
  * This is used to set said flag generically for said encoders.
  */
 int intra_only_flag;
+
+/**
+ * An audio frame with less than required samples has been submitted (and
+ * potentially padded with silence). Reject all subsequent frames.
+ */
+int last_audio_frame;
 } EncodeContext;
 
 static EncodeContext *encode_ctx(AVCodecInternal *avci)
@@ -174,7 +180,7 @@ static int pad_last_frame(AVCodecContext *s, AVFrame 
*frame, const AVFrame *src,
 
 fail:
 av_frame_unref(frame);
-s->internal->last_audio_frame = 0;
+encode_ctx(s->internal)->last_audio_frame = 0;
 return ret;
 }
 
@@ -446,6 +452,7 @@ static int encode_generate_icc_profile(av_unused 
AVCodecContext *c, av_unused AV
 static int encode_send_frame_internal(AVCodecContext *avctx, const AVFrame 
*src)
 {
 AVCodecInternal *avci = avctx->internal;
+EncodeContext *ec = encode_ctx(avci);
 AVFrame *dst = avci->buffer_frame;
 int ret;
 
@@ -458,7 +465,7 @@ static int encode_send_frame_internal(AVCodecContext 
*avctx, const AVFrame *src)
 /* check for valid frame size */
 if (!(avctx->codec->capabilities & AV_CODEC_CAP_VARIABLE_FRAME_SIZE)) {
 /* if we already got an undersized frame, that must have been the 
last */
-if (avctx->internal->last_audio_frame) {
+if (ec->last_audio_frame) {
 av_log(avctx, AV_LOG_ERROR, "frame_size (%d) was not respected 
for a non-last frame\n", avctx->frame_size);
 return AVERROR(EINVAL);
 }
@@ -467,7 +474,7 @@ static int encode_send_frame_internal(AVCodecContext 
*avctx, const AVFrame *src)
 return AVERROR(EINVAL);
 }
 if (src->nb_samples < avctx->frame_size) {
-avctx->internal->last_audio_frame = 1;
+ec->last_audio_frame = 1;
 if (!(avctx->codec->capabilities & 
AV_CODEC_CAP_SMALL_LAST_FRAME)) {
 int pad_samples = avci->pad_samples ? avci->pad_samples : 
avctx->frame_size;
 int out_samples = (src->nb_samples + pad_samples - 1) / 
pad_samples * pad_samples;
diff --git a/libavcodec/internal.h b/libavcodec/internal.h
index 497cd77f23..868dd46b48 100644
--- a/libavcodec/internal.h
+++ b/libavcodec/internal.h
@@ -56,12 +56,6 @@ typedef struct AVCodecInternal {
  */
 int is_copy;
 
-/**
- * An audio frame with less than required samples has been submitted (and
- * potentially padded with silence). Reject all subsequent frames.
- */
-int last_audio_frame;
-
 /**
  * Audio encoders can set this flag during init to indicate that they
  * want the small last frame to be padded to a multiple of pad_samples.
-- 
2.40.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 v2 10/10] lavc/decode: do not perform decoding when sending draining packets

[Anton Khirnov]

This way decoding errors will not be returned when the user starts
draining the decoder, avoiding confusion over whether draining did or
did not start.

Fixes failures of fate-h264-attachment-631 for certain numbers of frame
threads (e.g. 5).
---
 libavcodec/decode.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavcodec/decode.c b/libavcodec/decode.c
index 89c3c2a48d..269633ce10 100644
--- a/libavcodec/decode.c
+++ b/libavcodec/decode.c
@@ -674,7 +674,7 @@ int attribute_align_arg avcodec_send_packet(AVCodecContext 
*avctx, const AVPacke
 } else
 dc->draining_started = 1;
 
-if (!avci->buffer_frame->buf[0]) {
+if (!avci->buffer_frame->buf[0] && !dc->draining_started) {
 ret = decode_receive_frame_internal(avctx, avci->buffer_frame);
 if (ret < 0 && ret != AVERROR(EAGAIN) && ret != AVERROR_EOF)
 return ret;
-- 
2.40.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 v2 08/10] lavc/bsf: move IS_EMPTY() to packet_internal()

[Anton Khirnov]

It will be useful in other places.
---
 libavcodec/bsf.c | 11 +--
 libavcodec/packet_internal.h |  2 ++
 2 files changed, 7 insertions(+), 6 deletions(-)

diff --git a/libavcodec/bsf.c b/libavcodec/bsf.c
index 42cc1b5ab0..1e710f7d4a 100644
--- a/libavcodec/bsf.c
+++ b/libavcodec/bsf.c
@@ -31,8 +31,7 @@
 #include "bsf_internal.h"
 #include "codec_desc.h"
 #include "codec_par.h"
-
-#define IS_EMPTY(pkt) (!(pkt)->data && !(pkt)->side_data_elems)
+#include "packet_internal.h"
 
 static av_always_inline const FFBitStreamFilter *ff_bsf(const 
AVBitStreamFilter *bsf)
 {
@@ -205,7 +204,7 @@ int av_bsf_send_packet(AVBSFContext *ctx, AVPacket *pkt)
 FFBSFContext *const bsfi = ffbsfcontext(ctx);
 int ret;
 
-if (!pkt || IS_EMPTY(pkt)) {
+if (!pkt || AVPACKET_IS_EMPTY(pkt)) {
 if (pkt)
 av_packet_unref(pkt);
 bsfi->eof = 1;
@@ -217,7 +216,7 @@ int av_bsf_send_packet(AVBSFContext *ctx, AVPacket *pkt)
 return AVERROR(EINVAL);
 }
 
-if (!IS_EMPTY(bsfi->buffer_pkt))
+if (!AVPACKET_IS_EMPTY(bsfi->buffer_pkt))
 return AVERROR(EAGAIN);
 
 ret = av_packet_make_refcounted(pkt);
@@ -241,7 +240,7 @@ int ff_bsf_get_packet(AVBSFContext *ctx, AVPacket **pkt)
 if (bsfi->eof)
 return AVERROR_EOF;
 
-if (IS_EMPTY(bsfi->buffer_pkt))
+if (AVPACKET_IS_EMPTY(bsfi->buffer_pkt))
 return AVERROR(EAGAIN);
 
 tmp_pkt = av_packet_alloc();
@@ -261,7 +260,7 @@ int ff_bsf_get_packet_ref(AVBSFContext *ctx, AVPacket *pkt)
 if (bsfi->eof)
 return AVERROR_EOF;
 
-if (IS_EMPTY(bsfi->buffer_pkt))
+if (AVPACKET_IS_EMPTY(bsfi->buffer_pkt))
 return AVERROR(EAGAIN);
 
 av_packet_move_ref(pkt, bsfi->buffer_pkt);
diff --git a/libavcodec/packet_internal.h b/libavcodec/packet_internal.h
index 92a0d4e6d5..52fa6d9be9 100644
--- a/libavcodec/packet_internal.h
+++ b/libavcodec/packet_internal.h
@@ -23,6 +23,8 @@
 
 #include "packet.h"
 
+#define AVPACKET_IS_EMPTY(pkt) (!(pkt)->data && !(pkt)->side_data_elems)
+
 typedef struct PacketListEntry {
 struct PacketListEntry *next;
 AVPacket pkt;
-- 
2.40.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 v2 04/10] lavc: add generic-decode-layer private data

[Anton Khirnov]

Move AVCodecInternal.nb_draining_errors to it, should should not be
visible outside of decode.c.
---
 libavcodec/avcodec.c  |  4 +++-
 libavcodec/avcodec_internal.h |  2 ++
 libavcodec/decode.c   | 21 +++--
 libavcodec/internal.h |  3 ---
 libavcodec/pthread_frame.c|  3 ++-
 5 files changed, 26 insertions(+), 7 deletions(-)

diff --git a/libavcodec/avcodec.c b/libavcodec/avcodec.c
index c01dac2049..aef2edce32 100644
--- a/libavcodec/avcodec.c
+++ b/libavcodec/avcodec.c
@@ -150,7 +150,9 @@ int attribute_align_arg avcodec_open2(AVCodecContext 
*avctx, const AVCodec *code
 if (avctx->extradata_size < 0 || avctx->extradata_size >= 
FF_MAX_EXTRADATA_SIZE)
 return AVERROR(EINVAL);
 
-avci = av_mallocz(sizeof(*avci));
+avci = av_codec_is_decoder(codec) ?
+ff_decode_internal_alloc():
+av_mallocz(sizeof(AVCodecInternal));
 if (!avci) {
 ret = AVERROR(ENOMEM);
 goto end;
diff --git a/libavcodec/avcodec_internal.h b/libavcodec/avcodec_internal.h
index 6ffe575c3e..f52f91e07c 100644
--- a/libavcodec/avcodec_internal.h
+++ b/libavcodec/avcodec_internal.h
@@ -53,4 +53,6 @@ int ff_decode_preinit(struct AVCodecContext *avctx);
 void ff_decode_flush_buffers(struct AVCodecContext *avctx);
 void ff_encode_flush_buffers(struct AVCodecContext *avctx);
 
+struct AVCodecInternal *ff_decode_internal_alloc(void);
+
 #endif // AVCODEC_AVCODEC_INTERNAL_H
diff --git a/libavcodec/decode.c b/libavcodec/decode.c
index 3115282923..acec9860a5 100644
--- a/libavcodec/decode.c
+++ b/libavcodec/decode.c
@@ -50,6 +50,18 @@
 #include "internal.h"
 #include "thread.h"
 
+typedef struct DecodeContext {
+AVCodecInternal avci;
+
+/* to prevent infinite loop on errors when draining */
+int nb_draining_errors;
+} DecodeContext;
+
+static DecodeContext *decode_ctx(AVCodecInternal *avci)
+{
+return (DecodeContext *)avci;
+}
+
 static int apply_param_change(AVCodecContext *avctx, const AVPacket *avpkt)
 {
 int ret;
@@ -439,7 +451,7 @@ FF_ENABLE_DEPRECATION_WARNINGS
 int nb_errors_max = 20 + (HAVE_THREADS && 
avctx->active_thread_type & FF_THREAD_FRAME ?
 avctx->thread_count : 1);
 
-if (avci->nb_draining_errors++ >= nb_errors_max) {
+if (decode_ctx(avci)->nb_draining_errors++ >= nb_errors_max) {
 av_log(avctx, AV_LOG_ERROR, "Too many errors when draining, 
this is a bug. "
"Stop draining and force EOF.\n");
 avci->draining_done = 1;
@@ -1753,5 +1765,10 @@ void ff_decode_flush_buffers(AVCodecContext *avctx)
 
 av_bsf_flush(avci->bsf);
 
-avci->nb_draining_errors = 0;
+decode_ctx(avci)->nb_draining_errors = 0;
+}
+
+AVCodecInternal *ff_decode_internal_alloc(void)
+{
+return av_mallocz(sizeof(DecodeContext));
 }
diff --git a/libavcodec/internal.h b/libavcodec/internal.h
index dceae182c0..0c1f0b82ea 100644
--- a/libavcodec/internal.h
+++ b/libavcodec/internal.h
@@ -148,9 +148,6 @@ typedef struct AVCodecInternal {
 AVFrame *buffer_frame;
 int draining_done;
 
-/* to prevent infinite loop on errors when draining */
-int nb_draining_errors;
-
 /* used when avctx flag AV_CODEC_FLAG_DROPCHANGED is set */
 int changed_frames_dropped;
 int initial_format;
diff --git a/libavcodec/pthread_frame.c b/libavcodec/pthread_frame.c
index 008f3da43b..bc305f561f 100644
--- a/libavcodec/pthread_frame.c
+++ b/libavcodec/pthread_frame.c
@@ -28,6 +28,7 @@
 #include 
 
 #include "avcodec.h"
+#include "avcodec_internal.h"
 #include "codec_internal.h"
 #include "decode.h"
 #include "hwconfig.h"
@@ -815,7 +816,7 @@ static av_cold int init_thread(PerThreadContext *p, int 
*threads_to_free,
 p->parent = fctx;
 p->avctx  = copy;
 
-copy->internal = av_mallocz(sizeof(*copy->internal));
+copy->internal = ff_decode_internal_alloc();
 if (!copy->internal)
 return AVERROR(ENOMEM);
 copy->internal->thread_ctx = p;
-- 
2.40.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 v2 05/10] lavc: add generic-encode-layer private data

[Anton Khirnov]

Move AVCodecInternal.intra_only_flag to it, should should not be visible
outside of encode.c.
---
 libavcodec/avcodec.c  |  2 +-
 libavcodec/avcodec_internal.h |  1 +
 libavcodec/encode.c   | 26 --
 libavcodec/internal.h |  7 ---
 4 files changed, 26 insertions(+), 10 deletions(-)

diff --git a/libavcodec/avcodec.c b/libavcodec/avcodec.c
index aef2edce32..8ccc610227 100644
--- a/libavcodec/avcodec.c
+++ b/libavcodec/avcodec.c
@@ -152,7 +152,7 @@ int attribute_align_arg avcodec_open2(AVCodecContext 
*avctx, const AVCodec *code
 
 avci = av_codec_is_decoder(codec) ?
 ff_decode_internal_alloc():
-av_mallocz(sizeof(AVCodecInternal));
+ff_encode_internal_alloc();
 if (!avci) {
 ret = AVERROR(ENOMEM);
 goto end;
diff --git a/libavcodec/avcodec_internal.h b/libavcodec/avcodec_internal.h
index f52f91e07c..9b93ff3d81 100644
--- a/libavcodec/avcodec_internal.h
+++ b/libavcodec/avcodec_internal.h
@@ -54,5 +54,6 @@ void ff_decode_flush_buffers(struct AVCodecContext *avctx);
 void ff_encode_flush_buffers(struct AVCodecContext *avctx);
 
 struct AVCodecInternal *ff_decode_internal_alloc(void);
+struct AVCodecInternal *ff_encode_internal_alloc(void);
 
 #endif // AVCODEC_AVCODEC_INTERNAL_H
diff --git a/libavcodec/encode.c b/libavcodec/encode.c
index 2620810476..6da5d86ea0 100644
--- a/libavcodec/encode.c
+++ b/libavcodec/encode.c
@@ -33,6 +33,22 @@
 #include "frame_thread_encoder.h"
 #include "internal.h"
 
+typedef struct EncodeContext {
+AVCodecInternal avci;
+
+/**
+ * This is set to AV_PKT_FLAG_KEY for encoders that encode intra-only
+ * formats (i.e. whose codec descriptor has AV_CODEC_PROP_INTRA_ONLY set).
+ * This is used to set said flag generically for said encoders.
+ */
+int intra_only_flag;
+} EncodeContext;
+
+static EncodeContext *encode_ctx(AVCodecInternal *avci)
+{
+return (EncodeContext*)avci;
+}
+
 int ff_alloc_packet(AVCodecContext *avctx, AVPacket *avpkt, int64_t size)
 {
 if (size < 0 || size > INT_MAX - AV_INPUT_BUFFER_PADDING_SIZE) {
@@ -372,7 +388,7 @@ static int encode_receive_packet_internal(AVCodecContext 
*avctx, AVPacket *avpkt
 } else
 ret = encode_simple_receive_packet(avctx, avpkt);
 if (ret >= 0)
-avpkt->flags |= avci->intra_only_flag;
+avpkt->flags |= encode_ctx(avci)->intra_only_flag;
 
 if (ret == AVERROR_EOF)
 avci->draining_done = 1;
@@ -680,6 +696,7 @@ static int encode_preinit_audio(AVCodecContext *avctx)
 int ff_encode_preinit(AVCodecContext *avctx)
 {
 AVCodecInternal *avci = avctx->internal;
+EncodeContext *ec = encode_ctx(avci);
 int ret = 0;
 
 if (avctx->time_base.num <= 0 || avctx->time_base.den <= 0) {
@@ -710,7 +727,7 @@ int ff_encode_preinit(AVCodecContext *avctx)
 avctx->rc_initial_buffer_occupancy = avctx->rc_buffer_size * 3LL / 4;
 
 if (avctx->codec_descriptor->props & AV_CODEC_PROP_INTRA_ONLY)
-avctx->internal->intra_only_flag = AV_PKT_FLAG_KEY;
+ec->intra_only_flag = AV_PKT_FLAG_KEY;
 
 if (ffcodec(avctx->codec)->cb_type == FF_CODEC_CB_TYPE_ENCODE) {
 avci->in_frame = av_frame_alloc();
@@ -795,3 +812,8 @@ void ff_encode_flush_buffers(AVCodecContext *avctx)
 if (avci->recon_frame)
 av_frame_unref(avci->recon_frame);
 }
+
+AVCodecInternal *ff_encode_internal_alloc(void)
+{
+return av_mallocz(sizeof(EncodeContext));
+}
diff --git a/libavcodec/internal.h b/libavcodec/internal.h
index 0c1f0b82ea..497cd77f23 100644
--- a/libavcodec/internal.h
+++ b/libavcodec/internal.h
@@ -95,13 +95,6 @@ typedef struct AVCodecInternal {
 uint8_t *byte_buffer;
 unsigned int byte_buffer_size;
 
-/**
- * This is set to AV_PKT_FLAG_KEY for encoders that encode intra-only
- * formats (i.e. whose codec descriptor has AV_CODEC_PROP_INTRA_ONLY set).
- * This is used to set said flag generically for said encoders.
- */
-int intra_only_flag;
-
 void *frame_thread_encoder;
 
 /**
-- 
2.40.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 v2 07/10] lavc/decode: track whether the caller started draining with a separate flag

[Anton Khirnov]

Decoding pipeline has multiple stages, some of which may have their own
delay (e.g. bitstream filters). The code currently uses
AVCodecInternal.draining to track all of them, but they do not have to
all be in sync.
---
 libavcodec/decode.c | 15 ---
 1 file changed, 12 insertions(+), 3 deletions(-)

diff --git a/libavcodec/decode.c b/libavcodec/decode.c
index acec9860a5..47714a9393 100644
--- a/libavcodec/decode.c
+++ b/libavcodec/decode.c
@@ -55,6 +55,11 @@ typedef struct DecodeContext {
 
 /* to prevent infinite loop on errors when draining */
 int nb_draining_errors;
+
+/**
+ * The caller has submitted a NULL packet on input.
+ */
+int draining_started;
 } DecodeContext;
 
 static DecodeContext *decode_ctx(AVCodecInternal *avci)
@@ -626,12 +631,13 @@ FF_ENABLE_DEPRECATION_WARNINGS
 int attribute_align_arg avcodec_send_packet(AVCodecContext *avctx, const 
AVPacket *avpkt)
 {
 AVCodecInternal *avci = avctx->internal;
+DecodeContext *dc = decode_ctx(avci);
 int ret;
 
 if (!avcodec_is_open(avctx) || !av_codec_is_decoder(avctx->codec))
 return AVERROR(EINVAL);
 
-if (avctx->internal->draining)
+if (dc->draining_started)
 return AVERROR_EOF;
 
 if (avpkt && !avpkt->size && avpkt->data)
@@ -642,7 +648,8 @@ int attribute_align_arg avcodec_send_packet(AVCodecContext 
*avctx, const AVPacke
 ret = av_packet_ref(avci->buffer_pkt, avpkt);
 if (ret < 0)
 return ret;
-}
+} else
+dc->draining_started = 1;
 
 ret = av_bsf_send_packet(avci->bsf, avci->buffer_pkt);
 if (ret < 0) {
@@ -1756,6 +1763,7 @@ AVBufferRef *ff_hwaccel_frame_priv_alloc(AVCodecContext 
*avctx,
 void ff_decode_flush_buffers(AVCodecContext *avctx)
 {
 AVCodecInternal *avci = avctx->internal;
+DecodeContext *dc = decode_ctx(avci);
 
 av_packet_unref(avci->last_pkt_props);
 av_packet_unref(avci->in_pkt);
@@ -1765,7 +1773,8 @@ void ff_decode_flush_buffers(AVCodecContext *avctx)
 
 av_bsf_flush(avci->bsf);
 
-decode_ctx(avci)->nb_draining_errors = 0;
+dc->nb_draining_errors = 0;
+dc->draining_started   = 0;
 }
 
 AVCodecInternal *ff_decode_internal_alloc(void)
-- 
2.40.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 v2 03/10] lavc: reindent after previous commit

[Anton Khirnov]

---
 libavcodec/decode.c | 10 +-
 libavcodec/encode.c |  8 
 2 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/libavcodec/decode.c b/libavcodec/decode.c
index 01ac35bf34..3115282923 100644
--- a/libavcodec/decode.c
+++ b/libavcodec/decode.c
@@ -1745,13 +1745,13 @@ void ff_decode_flush_buffers(AVCodecContext *avctx)
 {
 AVCodecInternal *avci = avctx->internal;
 
-av_packet_unref(avci->last_pkt_props);
-av_packet_unref(avci->in_pkt);
+av_packet_unref(avci->last_pkt_props);
+av_packet_unref(avci->in_pkt);
 
-avctx->pts_correction_last_pts =
-avctx->pts_correction_last_dts = INT64_MIN;
+avctx->pts_correction_last_pts =
+avctx->pts_correction_last_dts = INT64_MIN;
 
-av_bsf_flush(avci->bsf);
+av_bsf_flush(avci->bsf);
 
 avci->nb_draining_errors = 0;
 }
diff --git a/libavcodec/encode.c b/libavcodec/encode.c
index 0b1947c781..2620810476 100644
--- a/libavcodec/encode.c
+++ b/libavcodec/encode.c
@@ -790,8 +790,8 @@ void ff_encode_flush_buffers(AVCodecContext *avctx)
 {
 AVCodecInternal *avci = avctx->internal;
 
-if (avci->in_frame)
-av_frame_unref(avci->in_frame);
-if (avci->recon_frame)
-av_frame_unref(avci->recon_frame);
+if (avci->in_frame)
+av_frame_unref(avci->in_frame);
+if (avci->recon_frame)
+av_frame_unref(avci->recon_frame);
 }
-- 
2.40.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 v2 01/10] lavc: add a header for internal generic-layer APIs

[Anton Khirnov]

The goal is to distinguish between APIs provided by the generic layer to
individual codecs and APIs internal to the generic layer.

Start by moving ff_{decode,encode}_receive_frame() and
ff_{decode,encode}_preinit() into this new header, as those functions
are called from generic code and should not be visible to individual
codecs.
---
 libavcodec/avcodec.c  |  1 +
 libavcodec/avcodec_internal.h | 53 +++
 libavcodec/decode.c   |  1 +
 libavcodec/decode.h   | 11 
 libavcodec/encode.c   |  1 +
 libavcodec/encode.h   | 11 
 6 files changed, 56 insertions(+), 22 deletions(-)
 create mode 100644 libavcodec/avcodec_internal.h

diff --git a/libavcodec/avcodec.c b/libavcodec/avcodec.c
index db8226f9b3..638cb55146 100644
--- a/libavcodec/avcodec.c
+++ b/libavcodec/avcodec.c
@@ -34,6 +34,7 @@
 #include "libavutil/opt.h"
 #include "libavutil/thread.h"
 #include "avcodec.h"
+#include "avcodec_internal.h"
 #include "bsf.h"
 #include "codec_internal.h"
 #include "decode.h"
diff --git a/libavcodec/avcodec_internal.h b/libavcodec/avcodec_internal.h
new file mode 100644
index 00..be60a36644
--- /dev/null
+++ b/libavcodec/avcodec_internal.h
@@ -0,0 +1,53 @@
+/*
+ * 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
+ */
+
+/*
+ * APIs internal to the generic codec layer.
+ *
+ * MUST NOT be included by individual encoders or decoders.
+ */
+
+#ifndef AVCODEC_AVCODEC_INTERNAL_H
+#define AVCODEC_AVCODEC_INTERNAL_H
+
+struct AVCodecContext;
+struct AVFrame;
+
+/**
+ * avcodec_receive_frame() implementation for decoders.
+ */
+int ff_decode_receive_frame(struct AVCodecContext *avctx, struct AVFrame 
*frame);
+
+/**
+ * avcodec_receive_frame() implementation for encoders.
+ */
+int ff_encode_receive_frame(struct AVCodecContext *avctx, struct AVFrame 
*frame);
+
+/*
+ * Perform encoder initialization and validation.
+ * Called when opening the encoder, before the FFCodec.init() call.
+ */
+int ff_encode_preinit(struct AVCodecContext *avctx);
+
+/**
+ * Perform decoder initialization and validation.
+ * Called when opening the decoder, before the FFCodec.init() call.
+ */
+int ff_decode_preinit(struct AVCodecContext *avctx);
+
+#endif // AVCODEC_AVCODEC_INTERNAL_H
diff --git a/libavcodec/decode.c b/libavcodec/decode.c
index 6ee2c85a75..336635f772 100644
--- a/libavcodec/decode.c
+++ b/libavcodec/decode.c
@@ -41,6 +41,7 @@
 #include "libavutil/opt.h"
 
 #include "avcodec.h"
+#include "avcodec_internal.h"
 #include "bytestream.h"
 #include "bsf.h"
 #include "codec_internal.h"
diff --git a/libavcodec/decode.h b/libavcodec/decode.h
index aaa29bc7f5..2b9fe59907 100644
--- a/libavcodec/decode.h
+++ b/libavcodec/decode.h
@@ -53,11 +53,6 @@ typedef struct FrameDecodeData {
 void (*hwaccel_priv_free)(void *priv);
 } FrameDecodeData;
 
-/**
- * avcodec_receive_frame() implementation for decoders.
- */
-int ff_decode_receive_frame(AVCodecContext *avctx, AVFrame *frame);
-
 /**
  * Called by decoders to get the next packet for decoding.
  *
@@ -99,12 +94,6 @@ int ff_attach_decode_data(AVFrame *frame);
  */
 int ff_copy_palette(void *dst, const AVPacket *src, void *logctx);
 
-/**
- * Perform decoder initialization and validation.
- * Called when opening the decoder, before the FFCodec.init() call.
- */
-int ff_decode_preinit(AVCodecContext *avctx);
-
 /**
  * Check that the provided frame dimensions are valid and set them on the codec
  * context.
diff --git a/libavcodec/encode.c b/libavcodec/encode.c
index ab5f889615..3a016b14c1 100644
--- a/libavcodec/encode.c
+++ b/libavcodec/encode.c
@@ -27,6 +27,7 @@
 #include "libavutil/samplefmt.h"
 
 #include "avcodec.h"
+#include "avcodec_internal.h"
 #include "codec_internal.h"
 #include "encode.h"
 #include "frame_thread_encoder.h"
diff --git a/libavcodec/encode.h b/libavcodec/encode.h
index 26a3304045..dfaab7c976 100644
--- a/libavcodec/encode.h
+++ b/libavcodec/encode.h
@@ -26,11 +26,6 @@
 #include "avcodec.h"
 #include "packet.h"
 
-/**
- * avcodec_receive_frame() implementation for encoders.
- */
-int ff_encode_receive_frame(AVCodecContext *avctx, AVFrame *frame);
-
 /**
  * Called by encoders to get the next frame for encoding.
  *
@@ -75,12 +70,6 @@ int ff_alloc_packet(AVCodecContext *avctx, 

[FFmpeg-devel] [PATCH v2 02/10] lavc/avcodec: split flushing into decode- and encode-specific functions

[Anton Khirnov]

Will allow making some state private to encoding/decoding in the future.
---
 libavcodec/avcodec.c  | 17 +++--
 libavcodec/avcodec_internal.h |  3 +++
 libavcodec/decode.c   | 15 +++
 libavcodec/encode.c   | 10 ++
 4 files changed, 31 insertions(+), 14 deletions(-)

diff --git a/libavcodec/avcodec.c b/libavcodec/avcodec.c
index 638cb55146..c01dac2049 100644
--- a/libavcodec/avcodec.c
+++ b/libavcodec/avcodec.c
@@ -383,23 +383,12 @@ void avcodec_flush_buffers(AVCodecContext *avctx)
"that doesn't support it\n");
 return;
 }
-if (avci->in_frame)
-av_frame_unref(avci->in_frame);
-if (avci->recon_frame)
-av_frame_unref(avci->recon_frame);
-} else {
-av_packet_unref(avci->last_pkt_props);
-av_packet_unref(avci->in_pkt);
-
-avctx->pts_correction_last_pts =
-avctx->pts_correction_last_dts = INT64_MIN;
-
-av_bsf_flush(avci->bsf);
-}
+ff_encode_flush_buffers(avctx);
+} else
+ff_decode_flush_buffers(avctx);
 
 avci->draining  = 0;
 avci->draining_done = 0;
-avci->nb_draining_errors = 0;
 av_frame_unref(avci->buffer_frame);
 av_packet_unref(avci->buffer_pkt);
 
diff --git a/libavcodec/avcodec_internal.h b/libavcodec/avcodec_internal.h
index be60a36644..6ffe575c3e 100644
--- a/libavcodec/avcodec_internal.h
+++ b/libavcodec/avcodec_internal.h
@@ -50,4 +50,7 @@ int ff_encode_preinit(struct AVCodecContext *avctx);
  */
 int ff_decode_preinit(struct AVCodecContext *avctx);
 
+void ff_decode_flush_buffers(struct AVCodecContext *avctx);
+void ff_encode_flush_buffers(struct AVCodecContext *avctx);
+
 #endif // AVCODEC_AVCODEC_INTERNAL_H
diff --git a/libavcodec/decode.c b/libavcodec/decode.c
index 336635f772..01ac35bf34 100644
--- a/libavcodec/decode.c
+++ b/libavcodec/decode.c
@@ -1740,3 +1740,18 @@ AVBufferRef *ff_hwaccel_frame_priv_alloc(AVCodecContext 
*avctx,
 
 return ref;
 }
+
+void ff_decode_flush_buffers(AVCodecContext *avctx)
+{
+AVCodecInternal *avci = avctx->internal;
+
+av_packet_unref(avci->last_pkt_props);
+av_packet_unref(avci->in_pkt);
+
+avctx->pts_correction_last_pts =
+avctx->pts_correction_last_dts = INT64_MIN;
+
+av_bsf_flush(avci->bsf);
+
+avci->nb_draining_errors = 0;
+}
diff --git a/libavcodec/encode.c b/libavcodec/encode.c
index 3a016b14c1..0b1947c781 100644
--- a/libavcodec/encode.c
+++ b/libavcodec/encode.c
@@ -785,3 +785,13 @@ int ff_encode_receive_frame(AVCodecContext *avctx, AVFrame 
*frame)
 av_frame_move_ref(frame, avci->recon_frame);
 return 0;
 }
+
+void ff_encode_flush_buffers(AVCodecContext *avctx)
+{
+AVCodecInternal *avci = avctx->internal;
+
+if (avci->in_frame)
+av_frame_unref(avci->in_frame);
+if (avci->recon_frame)
+av_frame_unref(avci->recon_frame);
+}
-- 
2.40.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 v2 00/10] lavc generic-layer private data

[Anton Khirnov]

* using IS_EMPTY() as suggested by James;
* use a different pattern for allocating private data, as suggested by
  Andreas
* rebased against master


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

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

Re: [FFmpeg-devel] [PATCH 1/2] avformat/hlsenc: fall back to av_get_random_seed() when generating AES128 key

[Marton Balint]

On Mon, 3 Jul 2023, Steven Liu wrote:


Marton Balint  于2023年7月3日周一 03:30写道：


It should be OK to use av_get_random_seed() to generate the key instead of
using openSSL/Gcrypt functions. This removes the hard dependancy of those libs
for key generation functionality.

Fixes ticket #10441.

Signed-off-by: Marton Balint 
---


[...]


 static int do_encrypt(AVFormatContext *s, VariantStream *vs)
@@ -775,10 +776,7 @@ static int do_encrypt(AVFormatContext *s, VariantStream 
*vs)
 if (!*hls->key_string) {
 AVDictionary *options = NULL;
 if (!hls->key) {
-if ((ret = randomize(key, sizeof(key))) < 0) {
-av_log(s, AV_LOG_ERROR, "Cannot generate a strong random 
key\n");
-return ret;
-}
+randomize(key, sizeof(key));
 } else {
 memcpy(key, hls->key, sizeof(key));
 }

Hi Marton,

Should remove braces too. I cannot sure how to make it more simpler as
!hls->key ?  randomize(key, sizeof(key)) : memcpy(key, hls->key,
sizeof(key)); ?


I will just remove the braces, looks more readable to me than using the 
ternary operator.


Will apply the series, thanks.

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

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

Re: [FFmpeg-devel] [PATCH 4/9] lavc: add generic-decode-layer private data

[Anton Khirnov]

Quoting Andreas Rheinhardt (2023-06-24 21:34:58)
> > diff --git a/libavcodec/internal.h b/libavcodec/internal.h
> > index dceae182c0..b672092ac4 100644
> > --- a/libavcodec/internal.h
> > +++ b/libavcodec/internal.h
> > @@ -49,7 +49,14 @@
> >  #   define STRIDE_ALIGN 8
> >  #endif
> >  
> > +typedef struct DecodeContext DecodeContext;
> > +
> >  typedef struct AVCodecInternal {
> > +/**
> > + * Generic decoding private data.
> > + */
> > +DecodeContext *d;
> 
> This approach has the downside of adding unnecessary indirecations; it
> furthermore adds pointers to DecodeContext and EncodeContext to
> AVCodecInternal, as if both could be valid at the same time.
> 
> The above could be overcome by using the typical approach to access
> these extra fields, as is used for FFStream etc.
> 
> Furthermore, I do not really think that is worth it: The number of
> fields affected by it are just so small. Has encoder code ever tried to
> set nb_draining_errors?

True, for decoding there are currently very few fields. But there are
many more that are encoding-only - I am not handling more of them in
this set because some of them are not trivial and I did not want to make
this patchset overly large, as its point is fixing the FATE test in 9/9.

And I belive there is a strong case for hiding generic-layer private
state from individual decoders/encoders, as it is prone to being
misunderstood and misused (e.g. AVCodecInternal.draining is currently
used in ways it most likely should not be).

Since the overhead of having a private decode context in addition to a
private encode context is very small, I prefer adding it now, at least
for consistency. Otherwise I'd have to add a shared encode-decode
context, which would be about the same amount of code.

-- 
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 4/5] mpegtsenc: Don't periodically announce PCR on SCTE-35 streams

[Marton Balint]

On Mon, 3 Jul 2023, Devin Heitmueller wrote:


Changes were made between in the last two years to periodically
send PCR-only packets on all PIDs, but for cases where the stream
may send packets very infrequently (like SCTE-35), this results in
extra TR101290 errors because it fails the PCR interval test.

I am not quite sure what the "right" fix should be for this, but
for now just disable all periodic sending of PCR-only packets on
SCTE-35 streams.


Hmm, only one PID per service should generate PCR, and if there is a video 
stream in the service, then that is preferred for PCR generation. An SCTE 
stream should only get selected for PCR if there are no video streams in a 
service. Or are you seeing something else?


And it is also strange that not sending PCR for any stream improves the 
PCR interval test, it should make it worse, because less PCRs are 
provided, no?


Thanks,
Marton



Signed-off-by: Devin Heitmueller 
---
libavformat/mpegtsenc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavformat/mpegtsenc.c b/libavformat/mpegtsenc.c
index c6cd1fd..ba60582 100644
--- a/libavformat/mpegtsenc.c
+++ b/libavformat/mpegtsenc.c
@@ -1579,7 +1579,7 @@ static void mpegts_write_pes(AVFormatContext *s, AVStream 
*st,
int st2_index = i < st->index ? i : (i + 1 == s->nb_streams ? 
st->index : i + 1);
AVStream *st2 = s->streams[st2_index];
MpegTSWriteStream *ts_st2 = st2->priv_data;
-if (ts_st2->pcr_period) {
+if (ts_st2->pcr_period && st2->codecpar->codec_id != 
AV_CODEC_ID_SCTE_35) {
if (pcr - ts_st2->last_pcr >= ts_st2->pcr_period) {
ts_st2->last_pcr = FFMAX(pcr - ts_st2->pcr_period, 
ts_st2->last_pcr + ts_st2->pcr_period);
if (st2 != st) {
--
1.8.3.1

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

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


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

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

[FFmpeg-devel] [PATCH v2] libavformat/data_uri: export mime_type of data urls

[David Lou]

Fix the fact that ffprobe no longer detects m3u8 in a data url correctly.

For example,

ffprobe 
data:application/vnd.apple.mpegurl;base64,I0VYVE0zVQojRVhULVgtVkVSU0lPTjozCiNFWFQtWC1UQVJHRVREVVJBVElPTjozMAojRVhUSU5GOjMwLApodHRwczovL2Rvd25sb2FkLnNhbXBsZWxpYi5jb20vbXA0L3NhbXBsZS0zMHMubXA0

This provides the mime_type hls detection requires.

Thank you.

Hopefully this patch doesn't get truncated by email again.

Signed-off-by: David Lou 
---
 libavformat/data_uri.c | 37 ++---
 1 file changed, 30 insertions(+), 7 deletions(-)

diff --git a/libavformat/data_uri.c b/libavformat/data_uri.c
index 28eb2b9e08..fdc1a2eef9 100644
--- a/libavformat/data_uri.c
+++ b/libavformat/data_uri.c
@@ -19,18 +19,24 @@
  */
 
 #include 
+
 #include "libavutil/avstring.h"
 #include "libavutil/avutil.h"
 #include "libavutil/base64.h"
+#include "libavutil/opt.h"
+
 #include "url.h"
 
 typedef struct {
+const AVClass *class;
 const uint8_t *data;
 void *tofree;
 size_t size;
 size_t pos;
+char *mime_type;
 } DataContext;
 
+
 static av_cold int data_open(URLContext *h, const char *uri, int flags)
 {
 DataContext *dc = h->priv_data;
@@ -56,8 +62,10 @@ static av_cold int data_open(URLContext *h, const char *uri, 
int flags)
(int)(next - opt), opt);
 return AVERROR(EINVAL);
 }
-av_log(h, AV_LOG_VERBOSE, "Content-type: %.*s\n",
-   (int)(next - opt), opt);
+av_free(dc->mime_type);
+dc->mime_type = av_strndup(opt, (int)(next - opt));
+av_log(h, AV_LOG_VERBOSE, "Content-type: %s\n",
+   dc->mime_type);
 } else {
 if (!av_strncasecmp(opt, "base64", next - opt)) {
 base64 = 1;
@@ -110,10 +118,25 @@ static int data_read(URLContext *h, unsigned char *buf, 
int size)
 return size;
 }
 
+#define OFFSET(x) offsetof(DataContext, x)
+
+static const AVOption options[] = {
+{ "mime_type", "export the MIME type", OFFSET(mime_type), 
AV_OPT_TYPE_STRING, { .str = NULL }, 0, 0, AV_OPT_FLAG_EXPORT | 
AV_OPT_FLAG_READONLY },
+{ NULL }
+};
+
+static const AVClass data_context_class = {
+.class_name = "data",
+.item_name  = av_default_item_name,
+.option = options,
+.version= LIBAVUTIL_VERSION_INT,
+};
+
 const URLProtocol ff_data_protocol = {
-.name   = "data",
-.url_open   = data_open,
-.url_close  = data_close,
-.url_read   = data_read,
-.priv_data_size = sizeof(DataContext),
+.name   = "data",
+.url_open   = data_open,
+.url_close  = data_close,
+.url_read   = data_read,
+.priv_data_size = sizeof(DataContext),
+.priv_data_class= _context_class,
 };
-- 
2.41.0

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

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

[FFmpeg-devel] [PATCH v3 7/7] avfilter/vf_bwdif: Add neon for filter_line3

[John Cox]

Signed-off-by: John Cox 
---
 libavfilter/aarch64/vf_bwdif_init_aarch64.c |  28 ++
 libavfilter/aarch64/vf_bwdif_neon.S | 272 
 2 files changed, 300 insertions(+)

diff --git a/libavfilter/aarch64/vf_bwdif_init_aarch64.c 
b/libavfilter/aarch64/vf_bwdif_init_aarch64.c
index 21e67884ab..f52bc4b9b4 100644
--- a/libavfilter/aarch64/vf_bwdif_init_aarch64.c
+++ b/libavfilter/aarch64/vf_bwdif_init_aarch64.c
@@ -36,6 +36,33 @@ void ff_bwdif_filter_line_neon(void *dst1, void *prev1, void 
*cur1, void *next1,
int prefs3, int mrefs3, int prefs4, int mrefs4,
int parity, int clip_max);
 
+void ff_bwdif_filter_line3_neon(void * dst1, int d_stride,
+const void * prev1, const void * cur1, const 
void * next1, int s_stride,
+int w, int parity, int clip_max);
+
+
+static void filter_line3_helper(void * dst1, int d_stride,
+const void * prev1, const void * cur1, const 
void * next1, int s_stride,
+int w, int parity, int clip_max)
+{
+// Asm works on 16 byte chunks
+// If w is a multiple of 16 then all is good - if not then if width rounded
+// up to nearest 16 will fit in both src & dst strides then allow the asm
+// to write over the padding bytes as that is almost certainly faster than
+// having to invoke the C version to clean up the tail.
+const int w1 = FFALIGN(w, 16);
+const int w0 = clip_max != 255 ? 0 :
+   d_stride <= w1 && s_stride <= w1 ? w : w & ~15;
+
+ff_bwdif_filter_line3_neon(dst1, d_stride,
+   prev1, cur1, next1, s_stride,
+   w0, parity, clip_max);
+
+if (w0 < w)
+ff_bwdif_filter_line3_c((char *)dst1 + w0, d_stride,
+(const char *)prev1 + w0, (const char *)cur1 + 
w0, (const char *)next1 + w0, s_stride,
+w - w0, parity, clip_max);
+}
 
 static void filter_line_helper(void *dst1, void *prev1, void *cur1, void 
*next1,
int w, int prefs, int mrefs, int prefs2, int 
mrefs2,
@@ -93,5 +120,6 @@ ff_bwdif_init_aarch64(BWDIFContext *s, int bit_depth)
 s->filter_intra = filter_intra_helper;
 s->filter_line  = filter_line_helper;
 s->filter_edge  = filter_edge_helper;
+s->filter_line3 = filter_line3_helper;
 }
 
diff --git a/libavfilter/aarch64/vf_bwdif_neon.S 
b/libavfilter/aarch64/vf_bwdif_neon.S
index ae5f09c511..bc092477b9 100644
--- a/libavfilter/aarch64/vf_bwdif_neon.S
+++ b/libavfilter/aarch64/vf_bwdif_neon.S
@@ -154,6 +154,278 @@ const coeffs, align=4   // align 4 means align on 2^4 
boundry
 .hword  5077, 981   // sp[0] = v0.h[6]
 endconst
 
+// ===
+//
+// void ff_bwdif_filter_line3_neon(
+// void * dst1, // x0
+// int d_stride,// w1
+// const void * prev1,  // x2
+// const void * cur1,   // x3
+// const void * next1,  // x4
+// int s_stride,// w5
+// int w,   // w6
+// int parity,  // w7
+// int clip_max);   // [sp, #0] (Ignored)
+
+function ff_bwdif_filter_line3_neon, export=1
+// Sanity check w
+cmp w6, #0
+ble 99f
+
+LDR_COEFFS  v0, x17
+
+// #define prev2 cur
+//const uint8_t * restrict next2 = parity ? prev : next;
+cmp w7, #0
+cselx17, x2, x4, ne
+
+// We want all the V registers - save all the ones we must
+PUSH_VREGS
+
+// Some rearrangement of initial values for nice layout of refs in regs
+mov w10, w6 // w10 = loop count
+neg w9,  w5 // w9  = mref
+lsl w8,  w9,  #1// w8 =  mref2
+add w7,  w9,  w9, LSL #1// w7  = mref3
+lsl w6,  w9,  #2// w6  = mref4
+mov w11, w5 // w11 = pref
+lsl w12, w5,  #1// w12 = pref2
+add w13, w5,  w5, LSL #1// w13 = pref3
+lsl w14, w5,  #2// w14 = pref4
+add w15, w5,  w5, LSL #2// w15 = pref5
+add w16, w14, w12   // w16 = pref6
+
+lsl w5,  w1,  #1// w5 = d_stride * 2
+
+// for (x = 0; x < w; x++) {
+// int diff0, diff2;
+// int d0, d2;
+// int temporal_diff0, temporal_diff2;
+//
+// int i1, i2;
+// int j1, j2;
+// int p6, p5, p4, p3, p2, p1, 

[FFmpeg-devel] [PATCH v3 5/7] avfilter/vf_bwdif: Add neon for filter_line Exports C filter_line needed for tail fixup of neon code

[John Cox]

Signed-off-by: John Cox 
---
 libavfilter/aarch64/vf_bwdif_init_aarch64.c |  21 ++
 libavfilter/aarch64/vf_bwdif_neon.S | 208 
 libavfilter/bwdif.h |   5 +
 libavfilter/vf_bwdif.c  |  10 +-
 4 files changed, 239 insertions(+), 5 deletions(-)

diff --git a/libavfilter/aarch64/vf_bwdif_init_aarch64.c 
b/libavfilter/aarch64/vf_bwdif_init_aarch64.c
index e75cf2f204..21e67884ab 100644
--- a/libavfilter/aarch64/vf_bwdif_init_aarch64.c
+++ b/libavfilter/aarch64/vf_bwdif_init_aarch64.c
@@ -31,6 +31,26 @@ void ff_bwdif_filter_edge_neon(void *dst1, void *prev1, void 
*cur1, void *next1,
 void ff_bwdif_filter_intra_neon(void *dst1, void *cur1, int w, int prefs, int 
mrefs,
 int prefs3, int mrefs3, int parity, int 
clip_max);
 
+void ff_bwdif_filter_line_neon(void *dst1, void *prev1, void *cur1, void 
*next1,
+   int w, int prefs, int mrefs, int prefs2, int 
mrefs2,
+   int prefs3, int mrefs3, int prefs4, int mrefs4,
+   int parity, int clip_max);
+
+
+static void filter_line_helper(void *dst1, void *prev1, void *cur1, void 
*next1,
+   int w, int prefs, int mrefs, int prefs2, int 
mrefs2,
+   int prefs3, int mrefs3, int prefs4, int mrefs4,
+   int parity, int clip_max)
+{
+const int w0 = clip_max != 255 ? 0 : w & ~15;
+
+ff_bwdif_filter_line_neon(dst1, prev1, cur1, next1,
+  w0, prefs, mrefs, prefs2, mrefs2, prefs3, 
mrefs3, prefs4, mrefs4, parity, clip_max);
+
+if (w0 < w)
+ff_bwdif_filter_line_c((char *)dst1 + w0, (char *)prev1 + w0, (char 
*)cur1 + w0, (char *)next1 + w0,
+   w - w0, prefs, mrefs, prefs2, mrefs2, prefs3, 
mrefs3, prefs4, mrefs4, parity, clip_max);
+}
 
 static void filter_edge_helper(void *dst1, void *prev1, void *cur1, void 
*next1,
int w, int prefs, int mrefs, int prefs2, int 
mrefs2,
@@ -71,6 +91,7 @@ ff_bwdif_init_aarch64(BWDIFContext *s, int bit_depth)
 return;
 
 s->filter_intra = filter_intra_helper;
+s->filter_line  = filter_line_helper;
 s->filter_edge  = filter_edge_helper;
 }
 
diff --git a/libavfilter/aarch64/vf_bwdif_neon.S 
b/libavfilter/aarch64/vf_bwdif_neon.S
index 389302b813..ae5f09c511 100644
--- a/libavfilter/aarch64/vf_bwdif_neon.S
+++ b/libavfilter/aarch64/vf_bwdif_neon.S
@@ -154,6 +154,214 @@ const coeffs, align=4   // align 4 means align on 2^4 
boundry
 .hword  5077, 981   // sp[0] = v0.h[6]
 endconst
 
+// ===
+//
+// void filter_line(
+//  void *dst1, // x0
+//  void *prev1,// x1
+//  void *cur1, // x2
+//  void *next1,// x3
+//  int w,  // w4
+//  int prefs,  // w5
+//  int mrefs,  // w6
+//  int prefs2, // w7
+//  int mrefs2, // [sp, #0]
+//  int prefs3, // [sp, #SP_INT]
+//  int mrefs3, // [sp, #SP_INT*2]
+//  int prefs4, // [sp, #SP_INT*3]
+//  int mrefs4, // [sp, #SP_INT*4]
+//  int parity, // [sp, #SP_INT*5]
+//  int clip_max)   // [sp, #SP_INT*6]
+
+function ff_bwdif_filter_line_neon, export=1
+// Sanity check w
+cmp w4, #0
+ble 99f
+
+// Rearrange regs to be the same as line3 for ease of debug!
+mov w10, w4 // w10 = loop count
+mov w9,  w6 // w9  = mref
+mov w12, w7 // w12 = pref2
+mov w11, w5 // w11 = pref
+ldr w8,  [sp, #0]   // w8 =  mref2
+ldr w7,  [sp, #SP_INT*2]// w7  = mref3
+ldr w6,  [sp, #SP_INT*4]// w6  = mref4
+ldr w13, [sp, #SP_INT]  // w13 = pref3
+ldr w14, [sp, #SP_INT*3]// w14 = pref4
+
+mov x4,  x3
+mov x3,  x2
+mov x2,  x1
+
+LDR_COEFFS  v0, x17
+
+// #define prev2 cur
+//const uint8_t * restrict next2 = parity ? prev : next;
+ldr w17, [sp, #SP_INT*5]// parity
+cmp w17, #0
+cselx17, x2, x4, ne
+
+PUSH_VREGS
+
+// for (x = 0; x < w; x++) {
+// int diff0, diff2;
+// int d0, d2;
+// int temporal_diff0, temporal_diff2;
+//
+// int i1, i2;
+// int j1, j2;
+// int p6, p5, p4, p3, p2, p1, c0, m1, m2, m3, m4;
+
+10:
+// c0 = prev2[0] + next2[0];// c0 = v20, v21
+// d0  = c0 >> 1; 

[FFmpeg-devel] [PATCH v3 6/7] avfilter/vf_bwdif: Add a filter_line3 method for optimisation

[John Cox]

Add an optional filter_line3 to the available optimisations.

filter_line3 is equivalent to filter_line, memcpy, filter_line

filter_line shares quite a number of loads and some calculations in
common with its next iteration and testing shows that using aarch64
neon filter_line3s performance is 30% better than two filter_lines
and a memcpy.

Adds a test for vf_bwdif filter_line3 to checkasm

Rounds job start lines down to a multiple of 4. This means that if
filter_line3 exists then filter_line will not sometimes be called
once at the end of a slice depending on thread count. The final slice
may do up to 3 extra lines but filter_edge is faster than filter_line
so it is unlikely to create any noticable thread load variation.

Signed-off-by: John Cox 
---
 libavfilter/bwdif.h   |  7 
 libavfilter/vf_bwdif.c| 44 +++--
 tests/checkasm/vf_bwdif.c | 81 +++
 3 files changed, 129 insertions(+), 3 deletions(-)

diff --git a/libavfilter/bwdif.h b/libavfilter/bwdif.h
index cce99953f3..496cec72ef 100644
--- a/libavfilter/bwdif.h
+++ b/libavfilter/bwdif.h
@@ -35,6 +35,9 @@ typedef struct BWDIFContext {
 void (*filter_edge)(void *dst, void *prev, void *cur, void *next,
 int w, int prefs, int mrefs, int prefs2, int mrefs2,
 int parity, int clip_max, int spat);
+void (*filter_line3)(void *dst, int dstride,
+ const void *prev, const void *cur, const void *next, 
int prefs,
+ int w, int parity, int clip_max);
 } BWDIFContext;
 
 void ff_bwdif_init_filter_line(BWDIFContext *bwdif, int bit_depth);
@@ -53,4 +56,8 @@ void ff_bwdif_filter_line_c(void *dst1, void *prev1, void 
*cur1, void *next1,
 int prefs3, int mrefs3, int prefs4, int mrefs4,
 int parity, int clip_max);
 
+void ff_bwdif_filter_line3_c(void * dst1, int d_stride,
+ const void * prev1, const void * cur1, const void 
* next1, int s_stride,
+ int w, int parity, int clip_max);
+
 #endif /* AVFILTER_BWDIF_H */
diff --git a/libavfilter/vf_bwdif.c b/libavfilter/vf_bwdif.c
index 26349da1fd..6701208efe 100644
--- a/libavfilter/vf_bwdif.c
+++ b/libavfilter/vf_bwdif.c
@@ -150,6 +150,31 @@ void ff_bwdif_filter_line_c(void *dst1, void *prev1, void 
*cur1, void *next1,
 FILTER2()
 }
 
+#define NEXT_LINE()\
+dst += d_stride; \
+prev += prefs; \
+cur  += prefs; \
+next += prefs;
+
+void ff_bwdif_filter_line3_c(void * dst1, int d_stride,
+ const void * prev1, const void * cur1, const void 
* next1, int s_stride,
+ int w, int parity, int clip_max)
+{
+const int prefs = s_stride;
+uint8_t * dst  = dst1;
+const uint8_t * prev = prev1;
+const uint8_t * cur  = cur1;
+const uint8_t * next = next1;
+
+ff_bwdif_filter_line_c(dst, (void*)prev, (void*)cur, (void*)next, w,
+   prefs, -prefs, prefs * 2, - prefs * 2, prefs * 3, 
-prefs * 3, prefs * 4, -prefs * 4, parity, clip_max);
+NEXT_LINE();
+memcpy(dst, cur, w);
+NEXT_LINE();
+ff_bwdif_filter_line_c(dst, (void*)prev, (void*)cur, (void*)next, w,
+   prefs, -prefs, prefs * 2, - prefs * 2, prefs * 3, 
-prefs * 3, prefs * 4, -prefs * 4, parity, clip_max);
+}
+
 void ff_bwdif_filter_edge_c(void *dst1, void *prev1, void *cur1, void *next1,
 int w, int prefs, int mrefs, int prefs2, int 
mrefs2,
 int parity, int clip_max, int spat)
@@ -212,6 +237,13 @@ static void filter_edge_16bit(void *dst1, void *prev1, 
void *cur1, void *next1,
 FILTER2()
 }
 
+// Round job start line down to multiple of 4 so that if filter_line3 exists
+// and the frame is a multiple of 4 high then filter_line will never be called
+static inline int job_start(const int jobnr, const int nb_jobs, const int h)
+{
+return jobnr >= nb_jobs ? h : ((h * jobnr) / nb_jobs) & ~3;
+}
+
 static int filter_slice(AVFilterContext *ctx, void *arg, int jobnr, int 
nb_jobs)
 {
 BWDIFContext *s = ctx->priv;
@@ -221,8 +253,8 @@ static int filter_slice(AVFilterContext *ctx, void *arg, 
int jobnr, int nb_jobs)
 int clip_max = (1 << (yadif->csp->comp[td->plane].depth)) - 1;
 int df = (yadif->csp->comp[td->plane].depth + 7) / 8;
 int refs = linesize / df;
-int slice_start = (td->h *  jobnr   ) / nb_jobs;
-int slice_end   = (td->h * (jobnr+1)) / nb_jobs;
+int slice_start = job_start(jobnr, nb_jobs, td->h);
+int slice_end   = job_start(jobnr + 1, nb_jobs, td->h);
 int y;
 
 for (y = slice_start; y < slice_end; y++) {
@@ -244,6 +276,11 @@ static int filter_slice(AVFilterContext *ctx, void *arg, 
int jobnr, int nb_jobs)
refs << 1, -(refs << 1),
td->parity ^ td->tff, clip_max,
  

[FFmpeg-devel] [PATCH v3 4/7] avfilter/vf_bwdif: Add neon for filter_edge

[John Cox]

Adds clip and spatial macros for aarch64 neon
Exports C filter_edge needed for tail fixup of neon code
Adds neon for filter_edge

Signed-off-by: John Cox 
---
 libavfilter/aarch64/vf_bwdif_init_aarch64.c |  20 +++
 libavfilter/aarch64/vf_bwdif_neon.S | 177 
 libavfilter/bwdif.h |   4 +
 libavfilter/vf_bwdif.c  |   8 +-
 4 files changed, 205 insertions(+), 4 deletions(-)

diff --git a/libavfilter/aarch64/vf_bwdif_init_aarch64.c 
b/libavfilter/aarch64/vf_bwdif_init_aarch64.c
index 3ffaa07ab3..e75cf2f204 100644
--- a/libavfilter/aarch64/vf_bwdif_init_aarch64.c
+++ b/libavfilter/aarch64/vf_bwdif_init_aarch64.c
@@ -24,10 +24,29 @@
 #include "libavfilter/bwdif.h"
 #include "libavutil/aarch64/cpu.h"
 
+void ff_bwdif_filter_edge_neon(void *dst1, void *prev1, void *cur1, void 
*next1,
+   int w, int prefs, int mrefs, int prefs2, int 
mrefs2,
+   int parity, int clip_max, int spat);
+
 void ff_bwdif_filter_intra_neon(void *dst1, void *cur1, int w, int prefs, int 
mrefs,
 int prefs3, int mrefs3, int parity, int 
clip_max);
 
 
+static void filter_edge_helper(void *dst1, void *prev1, void *cur1, void 
*next1,
+   int w, int prefs, int mrefs, int prefs2, int 
mrefs2,
+   int parity, int clip_max, int spat)
+{
+const int w0 = clip_max != 255 ? 0 : w & ~15;
+
+ff_bwdif_filter_edge_neon(dst1, prev1, cur1, next1, w0, prefs, mrefs, 
prefs2, mrefs2,
+  parity, clip_max, spat);
+
+if (w0 < w)
+ff_bwdif_filter_edge_c((char *)dst1 + w0, (char *)prev1 + w0, (char 
*)cur1 + w0, (char *)next1 + w0,
+   w - w0, prefs, mrefs, prefs2, mrefs2,
+   parity, clip_max, spat);
+}
+
 static void filter_intra_helper(void *dst1, void *cur1, int w, int prefs, int 
mrefs,
 int prefs3, int mrefs3, int parity, int 
clip_max)
 {
@@ -52,5 +71,6 @@ ff_bwdif_init_aarch64(BWDIFContext *s, int bit_depth)
 return;
 
 s->filter_intra = filter_intra_helper;
+s->filter_edge  = filter_edge_helper;
 }
 
diff --git a/libavfilter/aarch64/vf_bwdif_neon.S 
b/libavfilter/aarch64/vf_bwdif_neon.S
index e288efbe6c..389302b813 100644
--- a/libavfilter/aarch64/vf_bwdif_neon.S
+++ b/libavfilter/aarch64/vf_bwdif_neon.S
@@ -66,6 +66,79 @@
 umlsl2  \a3\().4s, \s1\().8h, \k
 .endm
 
+//  int b = m2s1 - m1;
+//  int f = p2s1 - p1;
+//  int dc = c0s1 - m1;
+//  int de = c0s1 - p1;
+//  int sp_max = FFMIN(p1 - c0s1, m1 - c0s1);
+//  sp_max = FFMIN(sp_max, FFMAX(-b,-f));
+//  int sp_min = FFMIN(c0s1 - p1, c0s1 - m1);
+//  sp_min = FFMIN(sp_min, FFMAX(b,f));
+//  diff = diff == 0 ? 0 : FFMAX3(diff, sp_min, sp_max);
+.macro SPAT_CHECK diff, m2s1, m1, c0s1, p1, p2s1, t0, t1, t2, t3
+uqsub   \t0\().16b, \p1\().16b, \c0s1\().16b
+uqsub   \t2\().16b, \m1\().16b, \c0s1\().16b
+umin\t2\().16b, \t0\().16b, \t2\().16b
+
+uqsub   \t1\().16b, \m1\().16b, \m2s1\().16b
+uqsub   \t3\().16b, \p1\().16b, \p2s1\().16b
+umax\t3\().16b, \t3\().16b, \t1\().16b
+umin\t3\().16b, \t3\().16b, \t2\().16b
+
+uqsub   \t0\().16b, \c0s1\().16b, \p1\().16b
+uqsub   \t2\().16b, \c0s1\().16b, \m1\().16b
+umin\t2\().16b, \t0\().16b, \t2\().16b
+
+uqsub   \t1\().16b, \m2s1\().16b, \m1\().16b
+uqsub   \t0\().16b, \p2s1\().16b, \p1\().16b
+umax\t0\().16b, \t0\().16b, \t1\().16b
+umin\t2\().16b, \t2\().16b, \t0\().16b
+
+cmeq\t1\().16b, \diff\().16b, #0
+umax\diff\().16b, \diff\().16b, \t3\().16b
+umax\diff\().16b, \diff\().16b, \t2\().16b
+bic \diff\().16b, \diff\().16b, \t1\().16b
+.endm
+
+//  i0 = s0;
+//  if (i0 > d0 + diff0)
+//  i0 = d0 + diff0;
+//  else if (i0 < d0 - diff0)
+//  i0 = d0 - diff0;
+//
+// i0 = s0 is safe
+.macro DIFF_CLIP i0, s0, d0, diff, t0, t1
+uqadd   \t0\().16b, \d0\().16b, \diff\().16b
+uqsub   \t1\().16b, \d0\().16b, \diff\().16b
+umin\i0\().16b, \s0\().16b, \t0\().16b
+umax\i0\().16b, \i0\().16b, \t1\().16b
+.endm
+
+//  i0 = FFABS(m1 - p1) > td0 ? i1 : i2;
+//  DIFF_CLIP
+//
+// i0 = i1 is safe
+.macro INTERPOL i0, i1, i2, m1, d0, p1, td0, diff, t0, t1, t2
+uabd\t0\().16b, \m1\().16b, \p1\().16b
+cmhi\t0\().16b, \t0\().16b, \td0\().16b
+bsl \t0\().16b, \i1\().16b, \i2\().16b
+DIFF_CLIP   \i0, \t0, \d0, \diff, \t1, \t2
+.endm
+
+.macro PUSH_VREGS
+stp 

[FFmpeg-devel] [PATCH v3 3/7] tests/checkasm: Add test for vf_bwdif filter_edge

[John Cox]

Signed-off-by: John Cox 
---
 tests/checkasm/vf_bwdif.c | 54 +++
 1 file changed, 54 insertions(+)

diff --git a/tests/checkasm/vf_bwdif.c b/tests/checkasm/vf_bwdif.c
index 034bbabb4c..5fdba09fdc 100644
--- a/tests/checkasm/vf_bwdif.c
+++ b/tests/checkasm/vf_bwdif.c
@@ -83,6 +83,60 @@ void checkasm_check_vf_bwdif(void)
 report("bwdif10");
 }
 
+{
+LOCAL_ALIGNED_16(uint8_t, prev0, [11*WIDTH]);
+LOCAL_ALIGNED_16(uint8_t, prev1, [11*WIDTH]);
+LOCAL_ALIGNED_16(uint8_t, next0, [11*WIDTH]);
+LOCAL_ALIGNED_16(uint8_t, next1, [11*WIDTH]);
+LOCAL_ALIGNED_16(uint8_t, cur0,  [11*WIDTH]);
+LOCAL_ALIGNED_16(uint8_t, cur1,  [11*WIDTH]);
+LOCAL_ALIGNED_16(uint8_t, dst0,  [WIDTH*3]);
+LOCAL_ALIGNED_16(uint8_t, dst1,  [WIDTH*3]);
+const int stride = WIDTH;
+const int mask = (1<<8)-1;
+int spat;
+int parity;
+
+for (spat = 0; spat != 2; ++spat) {
+for (parity = 0; parity != 2; ++parity) {
+if (check_func(ctx_8.filter_edge, "bwdif8.edge.s%d.p%d", spat, 
parity)) {
+
+declare_func(void, void *dst1, void *prev1, void *cur1, 
void *next1,
+int w, int prefs, int mrefs, int 
prefs2, int mrefs2,
+int parity, int clip_max, int 
spat);
+
+randomize_buffers(prev0, prev1, mask, 11*WIDTH);
+randomize_buffers(next0, next1, mask, 11*WIDTH);
+randomize_buffers( cur0,  cur1, mask, 11*WIDTH);
+memset(dst0, 0xba, WIDTH * 3);
+memset(dst1, 0xba, WIDTH * 3);
+
+call_ref(dst0 + stride,
+ prev0 + stride * 4, cur0 + stride * 4, next0 + 
stride * 4, WIDTH,
+ stride, -stride, stride * 2, -stride * 2,
+ parity, mask, spat);
+call_new(dst1 + stride,
+ prev1 + stride * 4, cur1 + stride * 4, next1 + 
stride * 4, WIDTH,
+ stride, -stride, stride * 2, -stride * 2,
+ parity, mask, spat);
+
+if (memcmp(dst0, dst1, WIDTH*3)
+|| memcmp(prev0, prev1, WIDTH*11)
+|| memcmp(next0, next1, WIDTH*11)
+|| memcmp( cur0,  cur1, WIDTH*11))
+fail();
+
+bench_new(dst1 + stride,
+ prev1 + stride * 4, cur1 + stride * 4, next1 + 
stride * 4, WIDTH,
+ stride, -stride, stride * 2, -stride * 2,
+ parity, mask, spat);
+}
+}
+}
+
+report("bwdif8.edge");
+}
+
 if (check_func(ctx_8.filter_intra, "bwdif8.intra")) {
 LOCAL_ALIGNED_16(uint8_t, cur0,  [11*WIDTH]);
 LOCAL_ALIGNED_16(uint8_t, cur1,  [11*WIDTH]);
-- 
2.39.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".

[FFmpeg-devel] [PATCH v3 2/7] avfilter/vf_bwdif: Add neon for filter_intra

[John Cox]

Adds an outline for aarch neon functions
Adds common macros and consts for aarch64 neon
Exports C filter_intra needed for tail fixup of neon code
Adds neon for filter_intra

Signed-off-by: John Cox 
---
 libavfilter/aarch64/Makefile|   2 +
 libavfilter/aarch64/vf_bwdif_init_aarch64.c |  56 
 libavfilter/aarch64/vf_bwdif_neon.S | 136 
 libavfilter/bwdif.h |   4 +
 libavfilter/vf_bwdif.c  |   8 +-
 5 files changed, 203 insertions(+), 3 deletions(-)
 create mode 100644 libavfilter/aarch64/vf_bwdif_init_aarch64.c
 create mode 100644 libavfilter/aarch64/vf_bwdif_neon.S

diff --git a/libavfilter/aarch64/Makefile b/libavfilter/aarch64/Makefile
index b58daa3a3f..b68209bc94 100644
--- a/libavfilter/aarch64/Makefile
+++ b/libavfilter/aarch64/Makefile
@@ -1,3 +1,5 @@
+OBJS-$(CONFIG_BWDIF_FILTER)  += aarch64/vf_bwdif_init_aarch64.o
 OBJS-$(CONFIG_NLMEANS_FILTER)+= aarch64/vf_nlmeans_init.o
 
+NEON-OBJS-$(CONFIG_BWDIF_FILTER) += aarch64/vf_bwdif_neon.o
 NEON-OBJS-$(CONFIG_NLMEANS_FILTER)   += aarch64/vf_nlmeans_neon.o
diff --git a/libavfilter/aarch64/vf_bwdif_init_aarch64.c 
b/libavfilter/aarch64/vf_bwdif_init_aarch64.c
new file mode 100644
index 00..3ffaa07ab3
--- /dev/null
+++ b/libavfilter/aarch64/vf_bwdif_init_aarch64.c
@@ -0,0 +1,56 @@
+/*
+ * bwdif aarch64 NEON optimisations
+ *
+ * Copyright (c) 2023 John Cox 
+ *
+ * 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/common.h"
+#include "libavfilter/bwdif.h"
+#include "libavutil/aarch64/cpu.h"
+
+void ff_bwdif_filter_intra_neon(void *dst1, void *cur1, int w, int prefs, int 
mrefs,
+int prefs3, int mrefs3, int parity, int 
clip_max);
+
+
+static void filter_intra_helper(void *dst1, void *cur1, int w, int prefs, int 
mrefs,
+int prefs3, int mrefs3, int parity, int 
clip_max)
+{
+const int w0 = clip_max != 255 ? 0 : w & ~15;
+
+ff_bwdif_filter_intra_neon(dst1, cur1, w0, prefs, mrefs, prefs3, mrefs3, 
parity, clip_max);
+
+if (w0 < w)
+ff_bwdif_filter_intra_c((char *)dst1 + w0, (char *)cur1 + w0,
+w - w0, prefs, mrefs, prefs3, mrefs3, parity, 
clip_max);
+}
+
+void
+ff_bwdif_init_aarch64(BWDIFContext *s, int bit_depth)
+{
+const int cpu_flags = av_get_cpu_flags();
+
+if (bit_depth != 8)
+return;
+
+if (!have_neon(cpu_flags))
+return;
+
+s->filter_intra = filter_intra_helper;
+}
+
diff --git a/libavfilter/aarch64/vf_bwdif_neon.S 
b/libavfilter/aarch64/vf_bwdif_neon.S
new file mode 100644
index 00..e288efbe6c
--- /dev/null
+++ b/libavfilter/aarch64/vf_bwdif_neon.S
@@ -0,0 +1,136 @@
+/*
+ * bwdif aarch64 NEON optimisations
+ *
+ * Copyright (c) 2023 John Cox 
+ *
+ * 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/aarch64/asm.S"
+
+// Space taken on the stack by an int (32-bit)
+#ifdef __APPLE__
+.setSP_INT, 4
+#else
+.setSP_INT, 8
+#endif
+
+.macro SQSHRUNN b, s0, s1, s2, s3, n
+sqshrun \s0\().4h, \s0\().4s, #\n - 8
+sqshrun2\s0\().8h, \s1\().4s, #\n - 8
+sqshrun \s1\().4h, \s2\().4s, #\n - 8
+sqshrun2\s1\().8h, \s3\().4s, #\n - 8
+uzp2\b\().16b, \s0\().16b, \s1\().16b
+.endm
+
+.macro SMULL4K a0, a1, a2, a3, s0, s1, k
+smull   \a0\().4s, \s0\().4h, \k
+smull2  \a1\().4s, 

[FFmpeg-devel] [PATCH v3 1/7] tests/checkasm: Add test for vf_bwdif filter_intra

[John Cox]

Signed-off-by: John Cox 
---
 tests/checkasm/vf_bwdif.c | 37 +
 1 file changed, 37 insertions(+)

diff --git a/tests/checkasm/vf_bwdif.c b/tests/checkasm/vf_bwdif.c
index 46224bb575..034bbabb4c 100644
--- a/tests/checkasm/vf_bwdif.c
+++ b/tests/checkasm/vf_bwdif.c
@@ -20,6 +20,7 @@
 #include "checkasm.h"
 #include "libavcodec/internal.h"
 #include "libavfilter/bwdif.h"
+#include "libavutil/mem_internal.h"
 
 #define WIDTH 256
 
@@ -81,4 +82,40 @@ void checkasm_check_vf_bwdif(void)
 BODY(uint16_t, 10);
 report("bwdif10");
 }
+
+if (check_func(ctx_8.filter_intra, "bwdif8.intra")) {
+LOCAL_ALIGNED_16(uint8_t, cur0,  [11*WIDTH]);
+LOCAL_ALIGNED_16(uint8_t, cur1,  [11*WIDTH]);
+LOCAL_ALIGNED_16(uint8_t, dst0,  [WIDTH*3]);
+LOCAL_ALIGNED_16(uint8_t, dst1,  [WIDTH*3]);
+const int stride = WIDTH;
+const int mask = (1<<8)-1;
+
+declare_func(void, void *dst1, void *cur1, int w, int prefs, int mrefs,
+ int prefs3, int mrefs3, int parity, int clip_max);
+
+randomize_buffers( cur0,  cur1, mask, 11*WIDTH);
+memset(dst0, 0xba, WIDTH * 3);
+memset(dst1, 0xba, WIDTH * 3);
+
+call_ref(dst0 + stride,
+ cur0 + stride * 4, WIDTH,
+ stride, -stride, stride * 3, -stride * 3,
+ 0, mask);
+call_new(dst1 + stride,
+ cur0 + stride * 4, WIDTH,
+ stride, -stride, stride * 3, -stride * 3,
+ 0, mask);
+
+if (memcmp(dst0, dst1, WIDTH*3)
+|| memcmp( cur0,  cur1, WIDTH*11))
+fail();
+
+bench_new(dst1 + stride,
+  cur0 + stride * 4, WIDTH,
+  stride, -stride, stride * 3, -stride * 3,
+  0, mask);
+
+report("bwdif8.intra");
+}
 }
-- 
2.39.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".

[FFmpeg-devel] [PATCH v3 0/7] avfilter/vf_bwdif: Add aarch64 neon functions

[John Cox]

Also adds a filter_line3 method which on aarch64 neon yields approx 30%
speedup over 2xfilter_line and a memcpy

Differences from v2:
coeffs moved into const segment
number of patches reduced

John Cox (7):
  tests/checkasm: Add test for vf_bwdif filter_intra
  avfilter/vf_bwdif: Add neon for filter_intra
  tests/checkasm: Add test for vf_bwdif filter_edge
  avfilter/vf_bwdif: Add neon for filter_edge
  avfilter/vf_bwdif: Add neon for filter_line Exports C filter_line
needed for tail fixup of neon code
  avfilter/vf_bwdif: Add a filter_line3 method for optimisation
  avfilter/vf_bwdif: Add neon for filter_line3

 libavfilter/aarch64/Makefile|   2 +
 libavfilter/aarch64/vf_bwdif_init_aarch64.c | 125 +++
 libavfilter/aarch64/vf_bwdif_neon.S | 793 
 libavfilter/bwdif.h |  20 +
 libavfilter/vf_bwdif.c  |  70 +-
 tests/checkasm/vf_bwdif.c   | 172 +
 6 files changed, 1167 insertions(+), 15 deletions(-)
 create mode 100644 libavfilter/aarch64/vf_bwdif_init_aarch64.c
 create mode 100644 libavfilter/aarch64/vf_bwdif_neon.S

-- 
2.39.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 v2 1/3] avutil/dict: add av_dict_pop

[Andreas Rheinhardt]

Marvin Scholz:
> 
> 
> On 3 Jul 2023, at 2:18, Andreas Rheinhardt wrote:
> 
>> Marvin Scholz:
>>> This new API allows to remove an entry and obtain ownership of the
>>> key/value that was associated with the removed entry.
>>> ---
>>>
>>> Changes since v1:
>>> - Clarify documentation about av_free having to be used.
>>> - Fix fate test to not rely on specific error code value
>>>
>>>  doc/APIchanges |  4 
>>>  libavutil/dict.c   | 27 +++
>>>  libavutil/dict.h   | 26 ++
>>>  libavutil/tests/dict.c | 38 ++
>>>  libavutil/version.h|  4 ++--
>>>  tests/ref/fate/dict| 12 
>>>  6 files changed, 109 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/doc/APIchanges b/doc/APIchanges
>>> index f040211f7d..d55821f682 100644
>>> --- a/doc/APIchanges
>>> +++ b/doc/APIchanges
>>> @@ -2,6 +2,10 @@ The last version increases of all libraries were on 
>>> 2023-02-09
>>>
>>>  API changes, most recent first:
>>>
>>> +2023-06-02 - xx - lavu 58.14.100 - dict.h
>>> +  Add av_dict_pop() to remove an entry from a dict
>>> +  and get ownership of the removed key/value.
>>> +
>>>  2023-05-29 - xx - lavc 60.16.100 - avcodec.h codec_id.h
>>>Add AV_CODEC_ID_EVC, FF_PROFILE_EVC_BASELINE, and FF_PROFILE_EVC_MAIN.
>>>
>>> diff --git a/libavutil/dict.c b/libavutil/dict.c
>>> index f673977a98..ac41771994 100644
>>> --- a/libavutil/dict.c
>>> +++ b/libavutil/dict.c
>>> @@ -173,6 +173,33 @@ int av_dict_set_int(AVDictionary **pm, const char 
>>> *key, int64_t value,
>>>  return av_dict_set(pm, key, valuestr, flags);
>>>  }
>>>
>>> +int av_dict_pop(AVDictionary **pm, const char *key,
>>> +char **out_key, char **out_value, int flags)
>>> +{
>>> +AVDictionary *m = *pm;
>>> +AVDictionaryEntry *entry = NULL;
>> Why don't you merge this initialization and the assignment below?
>>
>>> +entry = (AVDictionaryEntry *)av_dict_get(m, key, NULL, flags);
>>> +if (!entry)
>>> +return AVERROR(ENOENT);
>>> +
>>> +if (out_key)
>>> +*out_key = entry->key;
>>> +else
>>> +av_free(entry->key);
>>> +
>>> +if (out_value)
>>> +*out_value = entry->value;
>>> +else
>>> +av_free(entry->value);
>>> +
>>> +*entry = m->elems[--m->count];
>>> +if (m && !m->count) {
>>
>> The check for m is completely unnecessary; Coverity will probably
>> complain about this (because this check implies that m can be NULL, but
>> then the line above the check would crash).
>>
>>> +av_freep(>elems);
>>> +av_freep(pm);
>>> +}
>>> +return 0;
>>> +}
>>> +
>>>  static int parse_key_value_pair(AVDictionary **pm, const char **buf,
>>>  const char *key_val_sep, const char 
>>> *pairs_sep,
>>>  int flags)
>>> diff --git a/libavutil/dict.h b/libavutil/dict.h
>>> index 713c9e361a..31d38dabec 100644
>>> --- a/libavutil/dict.h
>>> +++ b/libavutil/dict.h
>>> @@ -172,6 +172,32 @@ int av_dict_set(AVDictionary **pm, const char *key, 
>>> const char *value, int flags
>>>   */
>>>  int av_dict_set_int(AVDictionary **pm, const char *key, int64_t value, int 
>>> flags);
>>>
>>> +/**
>>> + * Remove the entry with the given key from the dictionary.
>>> + *
>>> + * Search for an entry matching @p key and remove it, if found. Optionally
>>> + * the found key and/or value can be returned using the @p out_key and
>>> + * @p out_value arguments.
>>> + *
>>> + * If more than one entry matches, only one entry is removed and returned
>>> + * on each call. Which entry is returned first in that case is undefined.
>>> + *
>>> + * @param pmPointer to a pointer to a dictionary struct.
>>> + * @param key   Entry key to match.
>>> + * @param out_key   Pointer whose pointee will be set to the matched
>>> + *  entry key. Must be freed using av_dict_free() by
>>
>> This is wrong: It must be freed using av_free() (or av_freep()); same below.
> 
> Indeed, copy paste mistake, sorry.
> 
>>
>>> + *  the caller. May be NULL.
>>> + * @param out_value Pointer whose pointee will be set to the matched
>>> + *  entry value. Must be freed using av_dict_free() by
>>> + *  the caller. May be NULL.
>>> + *
>>> + * @retval 0Success
>>> + * @retval AVERROR(ENOENT)  No item for the given key found
>>> + * @retval "Other (negative) AVERROR"   Other failure
>>> + */
>>> +int av_dict_pop(AVDictionary **pm, const char *key,
>>> +char **out_key, char **out_value, int flags);
>>
>> It is possible to store multiple entries with the same value in an
>> AVDictionary. This function is not designed to handle this case, as one
>> can't tell it which one one wants to pop (IIRC the rest of the API does
>> not properly support this either, but that is not a reason to add a new
>> API with this limitation).
> 

[FFmpeg-devel] [PATCH v2 5/5] bsf: Add new bitstream filter to set pts_adjustment when reclocking

[Devin Heitmueller]

Because SCTE-35 messages are represented in TS streams as sections
rather than PES packets, we cannot rely on ffmpeg's standard
mechanisms to adjust PTS values if reclocking the stream.
This filter will leverage the SCTE-35 pts_adjust field to
compensate for any change in the PTS values in the stream.

See SCTE-35 2019 Sec 9.6 for information about the use of
the pts_adjust field.

This filter also tweaks the mpegtsenc mux to automatically
add it so the user doesn't have to include it manually.

Thanks to Andreas Rheinhardt for providing feedback/suggestions
on improving the patch.

Signed-off-by: Devin Heitmueller 
---
 doc/bitstream_filters.texi   |   9 
 libavcodec/Makefile  |   1 +
 libavcodec/bitstream_filters.c   |   1 +
 libavcodec/scte35ptsadjust_bsf.c | 103 +++
 libavformat/mpegtsenc.c  |   2 +
 5 files changed, 116 insertions(+)
 create mode 100644 libavcodec/scte35ptsadjust_bsf.c

diff --git a/doc/bitstream_filters.texi b/doc/bitstream_filters.texi
index c63c203..068b0c9 100644
--- a/doc/bitstream_filters.texi
+++ b/doc/bitstream_filters.texi
@@ -797,6 +797,15 @@ Remove extradata from all frames.
 @end table
 @end table
 
+@section scte35ptsadjust
+This bitstream filter makes use of side data injected by the MPEG-TS demux
+in order to rewrite the PTS adjust field within SCTE-35 packets.  This
+ensures the pts_adjust field contains a valid value if the caller changes
+the timebase of the stream.
+
+The bitstream filter is added automatically by the mpegtsenc mux, and no
+action is required on the part of the user.
+
 @section setts
 Set PTS and DTS in packets.
 
diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index 1b0226c..4c1b312 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -1253,6 +1253,7 @@ OBJS-$(CONFIG_PCM_RECHUNK_BSF)+= 
pcm_rechunk_bsf.o
 OBJS-$(CONFIG_PGS_FRAME_MERGE_BSF)+= pgs_frame_merge_bsf.o
 OBJS-$(CONFIG_PRORES_METADATA_BSF)+= prores_metadata_bsf.o
 OBJS-$(CONFIG_REMOVE_EXTRADATA_BSF)   += remove_extradata_bsf.o av1_parse.o
+OBJS-$(CONFIG_SCTE35PTSADJUST_BSF)+= scte35ptsadjust_bsf.o
 OBJS-$(CONFIG_SETTS_BSF)  += setts_bsf.o
 OBJS-$(CONFIG_TEXT2MOVSUB_BSF)+= movsub_bsf.o
 OBJS-$(CONFIG_TRACE_HEADERS_BSF)  += trace_headers_bsf.o
diff --git a/libavcodec/bitstream_filters.c b/libavcodec/bitstream_filters.c
index 1e9a676..60ed164 100644
--- a/libavcodec/bitstream_filters.c
+++ b/libavcodec/bitstream_filters.c
@@ -57,6 +57,7 @@ extern const FFBitStreamFilter ff_pcm_rechunk_bsf;
 extern const FFBitStreamFilter ff_pgs_frame_merge_bsf;
 extern const FFBitStreamFilter ff_prores_metadata_bsf;
 extern const FFBitStreamFilter ff_remove_extradata_bsf;
+extern const FFBitStreamFilter ff_scte35ptsadjust_bsf;
 extern const FFBitStreamFilter ff_setts_bsf;
 extern const FFBitStreamFilter ff_text2movsub_bsf;
 extern const FFBitStreamFilter ff_trace_headers_bsf;
diff --git a/libavcodec/scte35ptsadjust_bsf.c b/libavcodec/scte35ptsadjust_bsf.c
new file mode 100644
index 000..9870737
--- /dev/null
+++ b/libavcodec/scte35ptsadjust_bsf.c
@@ -0,0 +1,103 @@
+/*
+ * SCTE-35 PTS fixup bitstream filter
+ * Copyright (c) 2023 LTN Global Communications, Inc.
+ *
+ * Author: Devin Heitmueller 
+ *
+ * Because SCTE-35 messages are represented in TS streams as sections
+ * rather than PES packets, we cannot rely on ffmpeg's standard
+ * mechanisms to adjust PTS values if reclocking the stream.
+ * This filter will leverage the SCTE-35 pts_adjust field to
+ * compensate for any change in the PTS values in the stream.
+ *
+ * See SCTE-35 2019 Sec 9.6 for information about the use of
+ * the pts_adjust field.
+ *
+ * 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 "bsf.h"
+#include "bsf_internal.h"
+#include "defs.h"
+#include "libavutil/intreadwrite.h"
+
+static int scte35ptsadjust_filter(AVBSFContext *ctx, AVPacket *pkt)
+{
+const AVTransportTimestamp *transport_ts;
+int64_t cur_pts_adjust;
+int ret = 0;
+
+ret = ff_bsf_get_packet_ref(ctx, pkt);
+if (ret < 0)
+return ret;
+
+/* Retrieve the original PTS, which will be used to calculate the 
pts_adjust */
+transport_ts = (AVTransportTimestamp *) 

[FFmpeg-devel] [PATCH v2 4/5] mpegtsenc: Don't periodically announce PCR on SCTE-35 streams

[Devin Heitmueller]

Changes were made between in the last two years to periodically
send PCR-only packets on all PIDs, but for cases where the stream
may send packets very infrequently (like SCTE-35), this results in
extra TR101290 errors because it fails the PCR interval test.

I am not quite sure what the "right" fix should be for this, but
for now just disable all periodic sending of PCR-only packets on
SCTE-35 streams.

Signed-off-by: Devin Heitmueller 
---
 libavformat/mpegtsenc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavformat/mpegtsenc.c b/libavformat/mpegtsenc.c
index c6cd1fd..ba60582 100644
--- a/libavformat/mpegtsenc.c
+++ b/libavformat/mpegtsenc.c
@@ -1579,7 +1579,7 @@ static void mpegts_write_pes(AVFormatContext *s, AVStream 
*st,
 int st2_index = i < st->index ? i : (i + 1 == 
s->nb_streams ? st->index : i + 1);
 AVStream *st2 = s->streams[st2_index];
 MpegTSWriteStream *ts_st2 = st2->priv_data;
-if (ts_st2->pcr_period) {
+if (ts_st2->pcr_period && st2->codecpar->codec_id != 
AV_CODEC_ID_SCTE_35) {
 if (pcr - ts_st2->last_pcr >= ts_st2->pcr_period) {
 ts_st2->last_pcr = FFMAX(pcr - ts_st2->pcr_period, 
ts_st2->last_pcr + ts_st2->pcr_period);
 if (st2 != st) {
-- 
1.8.3.1

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

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

[FFmpeg-devel] [PATCH v2 3/5] mpegtsenc: Add support for output of SCTE-35 streams over TS

[Devin Heitmueller]

Introduce the ability to pass through SCTE-35 packets when creating
MPEG transport streams.  Note that this patch makes no effort to
change the PTS values in the SCTE-35 packets, and thus only works
when not reclocking the stream (i.e. using -copyts).  A subsequent
patch includes a BSF to recompute the PTS values.

Signed-off-by: Devin Heitmueller 
---
 libavformat/mpegts.h|  1 +
 libavformat/mpegtsenc.c | 74 ++---
 libavformat/mux.c   |  6 ++--
 3 files changed, 75 insertions(+), 6 deletions(-)

diff --git a/libavformat/mpegts.h b/libavformat/mpegts.h
index a48f14e..a7aaaba 100644
--- a/libavformat/mpegts.h
+++ b/libavformat/mpegts.h
@@ -137,6 +137,7 @@
 #define STREAM_TYPE_AUDIO_AC3   0x81
 #define STREAM_TYPE_AUDIO_DTS   0x82
 #define STREAM_TYPE_AUDIO_TRUEHD0x83
+#define STREAM_TYPE_SCTE_35 0x86
 #define STREAM_TYPE_AUDIO_EAC3  0x87
 
 /* ISO/IEC 13818-1 Table 2-22 */
diff --git a/libavformat/mpegtsenc.c b/libavformat/mpegtsenc.c
index 700fc54..c6cd1fd 100644
--- a/libavformat/mpegtsenc.c
+++ b/libavformat/mpegtsenc.c
@@ -425,6 +425,9 @@ static int get_dvb_stream_type(AVFormatContext *s, AVStream 
*st)
 case AV_CODEC_ID_SMPTE_2038:
 stream_type = STREAM_TYPE_PRIVATE_DATA;
 break;
+case AV_CODEC_ID_SCTE_35:
+stream_type = STREAM_TYPE_SCTE_35;
+break;
 case AV_CODEC_ID_DVB_SUBTITLE:
 case AV_CODEC_ID_DVB_TELETEXT:
 case AV_CODEC_ID_ARIB_CAPTION:
@@ -522,6 +525,16 @@ static int mpegts_write_pmt(AVFormatContext *s, 
MpegTSService *service)
 *q++ = 0xfc;// private_data_byte
 }
 
+/* If there is an SCTE-35 stream, we need a registration descriptor
+   at the program level (SCTE 35 2016 Sec 8.1) */
+for (i = 0; i < s->nb_streams; i++) {
+AVStream *st = s->streams[i];
+if (st->codecpar->codec_id == AV_CODEC_ID_SCTE_35) {
+put_registration_descriptor(, MKTAG('C', 'U', 'E', 'I'));
+break;
+}
+}
+
 val = 0xf000 | (q - program_info_length_ptr - 2);
 program_info_length_ptr[0] = val >> 8;
 program_info_length_ptr[1] = val;
@@ -533,6 +546,14 @@ static int mpegts_write_pmt(AVFormatContext *s, 
MpegTSService *service)
 const char default_language[] = "und";
 const char *language = lang && strlen(lang->value) >= 3 ? lang->value 
: default_language;
 enum AVCodecID codec_id = st->codecpar->codec_id;
+uint16_t pid;
+
+if (st->codecpar->codec_id == AV_CODEC_ID_SCTE_35) {
+MpegTSSection *sect = st->priv_data;
+pid = sect->pid;
+} else {
+pid = ts_st->pid;
+}
 
 if (s->nb_programs) {
 int k, found = 0;
@@ -556,7 +577,7 @@ static int mpegts_write_pmt(AVFormatContext *s, 
MpegTSService *service)
 stream_type = ts->m2ts_mode ? get_m2ts_stream_type(s, st) : 
get_dvb_stream_type(s, st);
 
 *q++ = stream_type;
-put16(, 0xe000 | ts_st->pid);
+put16(, 0xe000 | pid);
 desc_length_ptr = q;
 q += 2; /* patched after */
 
@@ -819,6 +840,10 @@ static int mpegts_write_pmt(AVFormatContext *s, 
MpegTSService *service)
 putbuf(, tag, strlen(tag));
 *q++ = 0;/* metadata service ID */
 *q++ = 0xF;  /* 
metadata_locator_record_flag|MPEG_carriage_flags|reserved */
+} else if (st->codecpar->codec_id == AV_CODEC_ID_SCTE_35) {
+*q++ = 0x8a; /* Cue Identifier Descriptor */
+*q++ = 0x01; /* length */
+*q++ = 0x01; /* Cue Stream Type (see Sec 8.2) */
 }
 break;
 }
@@ -1159,6 +1184,33 @@ static int mpegts_init(AVFormatContext *s)
 AVStream *st = s->streams[i];
 MpegTSWriteStream *ts_st;
 
+if (st->codecpar->codec_id == AV_CODEC_ID_SCTE_35) {
+struct MpegTSSection *sect;
+sect = av_mallocz(sizeof(MpegTSSection));
+if (!sect) {
+ret = AVERROR(ENOMEM);
+continue;
+}
+
+if (st->id < 16) {
+sect->pid = ts->start_pid + i;
+} else if (st->id < 0x1FFF) {
+sect->pid = st->id;
+} else {
+av_log(s, AV_LOG_ERROR,
+   "Invalid stream id %d, must be less than 8191\n", 
st->id);
+ret = AVERROR(EINVAL);
+continue;
+}
+
+sect->write_packet = section_write_packet;
+sect->opaque   = s;
+sect->cc   = 15;
+sect->discontinuity= ts->flags & MPEGTS_FLAG_DISCONT;
+st->priv_data = sect;
+continue;
+}
+
 ts_st = av_mallocz(sizeof(MpegTSWriteStream));
 if (!ts_st) {
 return AVERROR(ENOMEM);
@@ -1877,6 +1929,19 @@ static int mpegts_write_packet_internal(AVFormatContext 
*s, 

[FFmpeg-devel] [PATCH v2 1/5] avcodec: Add new side data type to contain original PTS value

[Devin Heitmueller]

In order to properly process SCTE-35 packets, we need the original
PTS value from the demux (i.e. not mangled by the application or
reclocked for the output).  This allows us to set the pts_adjustment
field in an BSF on the output side.

Introduce a new side data type to store the original PTS.

Signed-off-by: Devin Heitmueller 
---
 libavcodec/defs.h   | 12 
 libavcodec/packet.h | 11 +++
 2 files changed, 23 insertions(+)

diff --git a/libavcodec/defs.h b/libavcodec/defs.h
index deadfe7..173020f 100644
--- a/libavcodec/defs.h
+++ b/libavcodec/defs.h
@@ -28,6 +28,7 @@
 
 #include 
 #include 
+#include "libavutil/rational.h"
 
 /**
  * @ingroup lavc_decoding
@@ -131,6 +132,17 @@ typedef struct AVBarData {
 } AVBarData;
 
 /**
+ * Original Transport Timestamp.  Provides the original timestamp
+ * of the packet as specified by the libavformat source  This allows that
+ * data to be used in calculations even if the clocks have been
+ * rebased or otherwise modified.
+ */
+typedef struct AVTransportTimestamp {
+int64_t pts;
+AVRational time_base;
+} AVTransportTimestamp;
+
+/**
  * This structure describes the bitrate properties of an encoded bitstream. It
  * roughly corresponds to a subset the VBV parameters for MPEG-2 or HRD
  * parameters for H.264/HEVC.
diff --git a/libavcodec/packet.h b/libavcodec/packet.h
index bdad21e..6c39a45 100644
--- a/libavcodec/packet.h
+++ b/libavcodec/packet.h
@@ -306,6 +306,17 @@ enum AVPacketSideDataType {
 AV_PKT_DATA_BARDATA,
 
 /**
+ * Provides the original PTS when passed through the demux.  This can
+ * be used to offset any subsequent changes made by the caller to
+ * adjust PTS values (such as pts_offset).  We need this for SCTE-35,
+ * since by the time the packets reach the output the PTS values have
+ * already been re-written, and we cannot calculate pre-roll values
+ * using the PTS values embedded in the packet content
+ * Format for this data can be found in AVTransportTimestamp struct
+ */
+AV_PKT_DATA_TRANSPORT_TIMESTAMP,
+
+/**
  * The number of side data types.
  * This is not part of the public API/ABI in the sense that it may
  * change when new side data types are added.
-- 
1.8.3.1

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

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

[FFmpeg-devel] [PATCH v2 0/5] Add passthrough support for SCTE-35

[Devin Heitmueller]

Properly set up the MPEG-TS mux and recalculate the pts_adjust field
in SCTE_35 packets, such that a user can transparently pass through
SCTE-35 streams when both the input and output are MPEG-TS.

This patch series updated to add a time_base field to the new side-data
type, as well as various improvements suggested by Andreas Rheinhardt
to the BSF filter.

Devin Heitmueller (5):
  avcodec: Add new side data type to contain original PTS value
  mpegts: Stash original PTS for SCTE-35 sections for processing later
  mpegtsenc: Add support for output of SCTE-35 streams over TS
  mpegtsenc: Don't periodically announce PCR on SCTE-35 streams
  bsf: Add new bitstream filter to set pts_adjustment when reclocking

 doc/bitstream_filters.texi   |   9 
 libavcodec/Makefile  |   1 +
 libavcodec/bitstream_filters.c   |   1 +
 libavcodec/defs.h|  12 +
 libavcodec/packet.h  |  11 +
 libavcodec/scte35ptsadjust_bsf.c | 103 +++
 libavformat/mpegts.c |  11 -
 libavformat/mpegts.h |   1 +
 libavformat/mpegtsenc.c  |  78 +++--
 libavformat/mux.c|   6 ++-
 10 files changed, 225 insertions(+), 8 deletions(-)
 create mode 100644 libavcodec/scte35ptsadjust_bsf.c

-- 
1.8.3.1

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

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

[FFmpeg-devel] [PATCH v2 2/5] mpegts: Stash original PTS for SCTE-35 sections for processing later

[Devin Heitmueller]

We need the original PTS value in order to do subsequent processing,
so set it as packet side data.

Signed-off-by: Devin Heitmueller 
---
 libavformat/mpegts.c | 11 ++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/libavformat/mpegts.c b/libavformat/mpegts.c
index 0b3edda..a1b2420 100644
--- a/libavformat/mpegts.c
+++ b/libavformat/mpegts.c
@@ -1783,8 +1783,17 @@ static void scte_data_cb(MpegTSFilter *filter, const 
uint8_t *section,
 prg = av_find_program_from_stream(ts->stream, NULL, idx);
 if (prg && prg->pcr_pid != -1 && prg->discard != AVDISCARD_ALL) {
 MpegTSFilter *f = ts->pids[prg->pcr_pid];
-if (f && f->last_pcr != -1)
+if (f && f->last_pcr != -1) {
+AVTransportTimestamp *transport_ts;
 ts->pkt->pts = ts->pkt->dts = f->last_pcr/300;
+transport_ts = (AVTransportTimestamp *) 
av_packet_new_side_data(ts->pkt,
+
AV_PKT_DATA_TRANSPORT_TIMESTAMP,
+
sizeof(AVTransportTimestamp));
+if (transport_ts) {
+transport_ts->pts = ts->pkt->pts;
+transport_ts->time_base = av_make_q(1, 9);
+}
+}
 }
 ts->stop_parse = 1;
 
-- 
1.8.3.1

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

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

Re: [FFmpeg-devel] [PATCH 2/2] lavc/libx264: add mb_info option

[Carotti, Elias]

On Wed, 2023-06-21 at 15:57 +, Carotti, Elias wrote:
> Hi all,
> please find the second part of the patch set.
> Best,
> Elias

Hi all,
please find the second part of the patch, updating libavcodec/libx264.c
to use the AVVideoHint side data. This should use the block_size field
to scan the AVVideoRect array.

Best,
Elias



NICE SRL, viale Monte Grappa 3/5, 20124 Milano, Italia, Registro delle Imprese 
di Milano Monza Brianza Lodi REA n. 2096882, Capitale Sociale: 10.329,14 EUR 
i.v., Cod. Fisc. e P.IVA 01133050052, Societa con Socio Unico


From 5bdb624d8dbcff96493a63f02f68a3961cf72723 Mon Sep 17 00:00:00 2001
From: Elias Carotti 
Date: Tue, 20 Jun 2023 19:29:08 +0200
Subject: [PATCH 2/2] lavc/libx264: add mb_info option

Pass the information about unchanged parts of the frame by means of the
AVVideoHint side data.
---
 Changelog|  1 +
 doc/APIchanges   |  3 ++
 libavcodec/libx264.c | 94 
 libavcodec/version.h |  2 +-
 4 files changed, 99 insertions(+), 1 deletion(-)

diff --git a/Changelog b/Changelog
index 3876082844..70b0fe94a3 100644
--- a/Changelog
+++ b/Changelog
@@ -25,6 +25,7 @@ version :
 - Raw VVC bitstream parser, muxer and demuxer
 - Bitstream filter for editing metadata in VVC streams
 - Bitstream filter for converting VVC from MP4 to Annex B
+- support for the P_SKIP hinting to speed up libx264 encoding
 
 version 6.0:
 - Radiance HDR image support
diff --git a/doc/APIchanges b/doc/APIchanges
index bfe04556d2..89ff88af15 100644
--- a/doc/APIchanges
+++ b/doc/APIchanges
@@ -2,6 +2,9 @@ The last version increases of all libraries were on 2023-02-09
 
 API changes, most recent first:
 
+2023-06-21 - xx - lavc 60.23.100 - libx264.c
+  Add mb_info option.
+
 2023-06-21 - xx - lavu 58.14.100 - video_hint.h
   Add AVVideoHint API.
 
diff --git a/libavcodec/libx264.c b/libavcodec/libx264.c
index 5736f1efa7..67bdbd06b0 100644
--- a/libavcodec/libx264.c
+++ b/libavcodec/libx264.c
@@ -30,6 +30,7 @@
 #include "libavutil/stereo3d.h"
 #include "libavutil/time.h"
 #include "libavutil/intreadwrite.h"
+#include "libavutil/video_hint.h"
 #include "avcodec.h"
 #include "codec_internal.h"
 #include "encode.h"
@@ -48,6 +49,9 @@
 // from x264.h, for quant_offsets, Macroblocks are 16x16
 // blocks of pixels (with respect to the luma plane)
 #define MB_SIZE 16
+#define MB_LSIZE 4
+#define MB_FLOOR(x)  ((x) >> (MB_LSIZE))
+#define MB_CEIL(x)   MB_FLOOR((x) + (MB_SIZE - 1))
 
 typedef struct X264Opaque {
 #if FF_API_REORDERED_OPAQUE
@@ -123,6 +127,8 @@ typedef struct X264Context {
  * encounter a frame with ROI side data.
  */
 int roi_warned;
+
+int mb_info;
 } X264Context;
 
 static void X264_log(void *p, int level, const char *fmt, va_list args)
@@ -295,6 +301,7 @@ static void free_picture(x264_picture_t *pic)
 av_free(pic->extra_sei.payloads[i].payload);
 av_freep(>extra_sei.payloads);
 av_freep(>prop.quant_offsets);
+av_freep(>prop.mb_info);
 pic->extra_sei.num_payloads = 0;
 }
 
@@ -320,6 +327,74 @@ static enum AVPixelFormat csp_to_pixfmt(int csp)
 return AV_PIX_FMT_NONE;
 }
 
+static void av_always_inline mbinfo_compute_changed_coords(const AVVideoRect *rect,
+   int *min_x,
+   int *max_x,
+   int *min_y,
+   int *max_y)
+{
+*min_y = MB_FLOOR(rect->y);
+*max_y = MB_CEIL(rect->y + rect->height);
+*min_x = MB_FLOOR(rect->x);
+*max_x = MB_CEIL(rect->x + rect->width);
+}
+
+static void av_always_inline mbinfo_compute_constant_coords(const AVVideoRect *rect,
+int *min_x,
+int *max_x,
+int *min_y,
+int *max_y)
+{
+*min_y = MB_CEIL(rect->y);
+*max_y = MB_FLOOR(rect->y + rect->height);
+*min_x = MB_CEIL(rect->x);
+*max_x = MB_FLOOR(rect->x + rect->width);
+}
+
+static int setup_mb_info(AVCodecContext *ctx, x264_picture_t *pic,
+ const AVFrame *frame,
+ const AVVideoHint *info)
+{
+int mb_width = (frame->width + MB_SIZE - 1) / MB_SIZE;
+int mb_height = (frame->height + MB_SIZE - 1) / MB_SIZE;
+
+const uint8_t *mbinfo_rects;
+int nb_rects;
+uint8_t *mbinfo;
+
+mbinfo_rects = (const uint8_t *)av_video_hint_rects(info);
+nb_rects = info->nb_rects;
+
+mbinfo = av_calloc(mb_width * mb_height, sizeof(*mbinfo));
+if (!mbinfo)
+return AVERROR(ENOMEM);
+
+#define COMPUTE_MBINFO(mbinfo_filler_, mbinfo_marker_, compute_coords_fn_) \
+memset(mbinfo, mbinfo_filler_, sizeof(*mbinfo) * mb_width * mb_height); \
+   

Re: [FFmpeg-devel] [PATCH] libswscale/riscv: Fix syntax of vsetvli

[Khem Raj]

On Mon, Jul 3, 2023 at 1:00 AM Rémi Denis-Courmont  wrote:
>
> Hi,
>
> The diff is ok. I even have a slight incline in favour thereof for the sake 
> of consistency. Yet, I may be vainly pedantic but I do have problems with the 
> description.
>
> Le 3 juillet 2023 05:44:12 GMT+03:00, Khem Raj  a écrit :
> >Add missing operand
>
> The spec does explicitly make the mask and tail policy mandatory, but I can't 
> see any such requirements for the group multiplier. To the contrary, there 
> are several examples in the spec _without_ explicit multiplier.
>
> In reality, `vsetvli` (and `vsetivli`) merely transfers an immediate value to 
> the vector configuration register. Missing fields are to be left at zero for 
> forward compatibility, and `m1` happens to encode as 0b000.
>

I just replicated what GAS is doing here implicitly.

> > Which clang complains about but gcc assumes it to be
> >'m1' if not specifiied.
>
> The technical term for the RISC-V support in LLVM AS version 15 and earlier 
> is "useless junk". If you want to compile FFmpeg on RISC-V with Clang, you 
> *must* disable the integrated AS and use binutils GNU/as instead.
>
> The Linux RISC-V kernel altogether gave up on LLVM entirely, requiring GCC 
> for RVV, so they're even stricter (and without kernel support, FFmpeg support 
> is obviously useless).
>
> *Hopefully* LLVM gets their act together by release 16, and ship a usable 
> assembler, rather than tell us to use automatic RVV vectorisation (which *is* 
> a release 16 feature, though it was half-baked last time I tried).
>

I am on clang/llvm trunk ( future 17.0 release ), I will also open an
issue with llvm on github regarding this.

> >
> >Fixes building with clang
>
> More like bug-compatible work-around than fix, AFAIU.

I can do it although I did not find a relevant section in spec about
these being optional, I did see examples omitting them though.

>
> >| src/libswscale/riscv/rgb2rgb_rvv.S:88:25: error: operand must be 
> >e[8|16|32|64|128|256|512|1024],m[1|2|4|8|f2|f4|f8],[ta|tu],[ma|mu]
>
> Do you have a reference to the Github RVV spec to validate this, that I 
> overlooked, or it's just misled and misleading spew from LLVM?

Perhaps the latter but I also did not see reference to the former.
Here is a small example

a.S
#.option arch, +zve32x
# OK
#vsetvli t4, t3, e8, m1, ta, ma
# BAD
vsetvli t4, t3, e8, ta, ma

clang -target riscv64 -march=rv64izve32x1p0  a.S -c

>
> >| vsetvli t4, t3, e8, ta, ma
> >| ^
> >
> >Signed-off-by: Khem Raj 
> >---
> > libswscale/riscv/rgb2rgb_rvv.S | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> >diff --git a/libswscale/riscv/rgb2rgb_rvv.S b/libswscale/riscv/rgb2rgb_rvv.S
> >index 5626d906eb..bbdfdbebbc 100644
> >--- a/libswscale/riscv/rgb2rgb_rvv.S
> >+++ b/libswscale/riscv/rgb2rgb_rvv.S
> >@@ -85,7 +85,7 @@ func ff_interleave_bytes_rvv, zve32x
> > mv  t3, a3
> > addia4, a4, -1
> > 2:
> >-vsetvlit4, t3, e8, ta, ma
> >+vsetvlit4, t3, e8, m1, ta, ma
> > subt3, t3, t4
> > vle8.v v8, (t0)
> > addt0, t4, t0
___
ffmpeg-devel mailing list
ffmpeg-devel@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] Optimization: support for libx264's mb_info

[Carotti, Elias]

On Sat, 2023-07-01 at 10:33 +0200, Anton Khirnov wrote:
> CAUTION: This email originated from outside of the organization. Do
> not click links or open attachments unless you can confirm the sender
> and know the content is safe.
> 
> 
> 
> Sorry to still nag you, but I just noticed that unlike
> video_enc_params,
> you do not store AVVideoRect size in AVVideoHint. This means that
> no new fields can be added to AVVideoRect without an ABI break. This
> seems suboptimal, since I do see potential use for per-block
> information.
> 

Hi Anton,
I do agree with you. 
Please find the updated (and rebased) patch attached to this email.

Best,
Elias

P.S. By the way, I would be tempted  (I didn't do that here) to declare
the block_size field as 

const size_t block_size;

and then when setting it into av_video_hint_alloc(...) cast away the
const (it has to be assigned only once, upon allocation of the struct),
just to enforce compiler checking against accidental assignments and
for better clarity that this is a read-only field, in the general case.

P.P.S.: I'm sending the second part of the patch for libavcodec  as a
separate email. 


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




NICE SRL, viale Monte Grappa 3/5, 20124 Milano, Italia, Registro delle Imprese 
di Milano Monza Brianza Lodi REA n. 2096882, Capitale Sociale: 10.329,14 EUR 
i.v., Cod. Fisc. e P.IVA 01133050052, Societa con Socio Unico


From b0fb79736c082d4c6c8bfd698f8f76a835d41770 Mon Sep 17 00:00:00 2001
From: Elias Carotti 
Date: Tue, 20 Jun 2023 19:28:04 +0200
Subject: [PATCH 1/2] lavu: add AVVideoHint API

Add side data type to provide hint to the video encoders about unchanged
portions of each frame.
---
 doc/APIchanges |  3 ++
 libavutil/Makefile |  4 ++
 libavutil/frame.h  | 10 +
 libavutil/version.h|  4 +-
 libavutil/video_hint.c | 82 
 libavutil/video_hint.h | 94 ++
 6 files changed, 195 insertions(+), 2 deletions(-)
 create mode 100644 libavutil/video_hint.c
 create mode 100644 libavutil/video_hint.h

diff --git a/doc/APIchanges b/doc/APIchanges
index f040211f7d..bfe04556d2 100644
--- a/doc/APIchanges
+++ b/doc/APIchanges
@@ -2,6 +2,9 @@ The last version increases of all libraries were on 2023-02-09

 API changes, most recent first:

+2023-06-21 - xx - lavu 58.14.100 - video_hint.h
+  Add AVVideoHint API.
+
 2023-05-29 - xx - lavc 60.16.100 - avcodec.h codec_id.h
   Add AV_CODEC_ID_EVC, FF_PROFILE_EVC_BASELINE, and FF_PROFILE_EVC_MAIN.

diff --git a/libavutil/Makefile b/libavutil/Makefile
index bd9c6f9e32..a0b43faa9f 100644
--- a/libavutil/Makefile
+++ b/libavutil/Makefile
@@ -91,6 +91,7 @@ HEADERS = adler32.h \
   tea.h \
   tx.h  \
   film_grain_params.h   \
+  video_hint.h

 ARCH_HEADERS = bswap.h  \
intmath.h\
@@ -188,6 +189,7 @@ OBJS-$(CONFIG_CUDA) += hwcontext_cuda.o
 OBJS-$(CONFIG_D3D11VA)  += hwcontext_d3d11va.o
 OBJS-$(CONFIG_DXVA2)+= hwcontext_dxva2.o
 OBJS-$(CONFIG_LIBDRM)   += hwcontext_drm.o
+OBJS-$(CONFIG_LIBX264)  += video_hint.o
 OBJS-$(CONFIG_MACOS_KPERF)  += macos_kperf.o
 OBJS-$(CONFIG_MEDIACODEC)   += hwcontext_mediacodec.o
 OBJS-$(CONFIG_OPENCL)   += hwcontext_opencl.o
@@ -219,6 +221,8 @@ SKIPHEADERS-$(CONFIG_VULKAN)   += hwcontext_vulkan.h vulkan.h   \
   vulkan_functions.h\
   vulkan_loader.h

+SKIPHEADERS-$(CONFIG_LIBX264)  	   += video_hint.h
+
 TESTPROGS = adler32 \
 aes \
 aes_ctr \
diff --git a/libavutil/frame.h b/libavutil/frame.h
index a491315f25..c0c1b23db7 100644
--- a/libavutil/frame.h
+++ b/libavutil/frame.h
@@ -214,6 +214,16 @@ enum AVFrameSideDataType {
  * Ambient viewing environment metadata, as defined by H.274.
  */
 AV_FRAME_DATA_AMBIENT_VIEWING_ENVIRONMENT,
+
+/**
+ * Provide encoder-specific hinting information about changed/unchanged
+ * portions of a frame.  It can be used to pass information about which
+ * macroblocks can be skipped because they didn't change from 

Re: [FFmpeg-devel] [PATCH v7 00/11] Add support for H266/VVC

[Thomas Siedel]

On Thu, 29 Jun 2023 at 19:39, James Almer  wrote:

> On 3/21/2023 12:01 PM, Thomas Siedel wrote:
> > This patch set adds H266/VVC support.
> > This includes parsing, muxing, demuxing, decoding and encoding.
> > Decoding is done using the external library VVdeC
> > (https://github.com/fraunhoferhhi/vvdec.git) and can be enabled with
> > --enable-libvvdec.
> > Encoding is done using the external library VVenC
> > (https://github.com/fraunhoferhhi/vvenc.git) and can be enabled with
> > --enable-libvvenc.
> >
> > For conformance testing, the following JVET bitstreams can be used:
> >
> https://www.itu.int/wftp3/av-arch/jvet-site/bitstream_exchange/VVC/draft_conformance/draft6/
> > DVB test streams can be found here:
> > https://dvb.org/specifications/verification-validation/vvc-test-content/
> > All JVET conformance bitstreams that are supported by VVdeC can be
> decoded.
> > Pallete mode and multi-layer streams are unsupported.
> > The DVB MP4 and TS reference files can be decoded as well.
>
> I have pushed patches 1 to 6, and the raw muxer part of 7. Will look at
> the ISOBMFF and ts stuff better later, as well as the encoder wrapper.
>

That is great, thank you for pushing the patches.
___
ffmpeg-devel mailing list
ffmpeg-devel@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/cbs_h266: add support for Decoding capability information NALU type

[Nuo Mi]

On Mon, Jul 3, 2023 at 7:28 AM James Almer  wrote:

> Signed-off-by: James Almer 
> ---
>  libavcodec/cbs_h2645.c| 18 ++
>  libavcodec/cbs_h266.h | 10 ++
>  libavcodec/cbs_h266_syntax_template.c | 24 
>  libavcodec/vvc.h  |  3 +++
>  4 files changed, 55 insertions(+)
>
> diff --git a/libavcodec/cbs_h2645.c b/libavcodec/cbs_h2645.c
> index 8dc9ae471d..95da597427 100644
> --- a/libavcodec/cbs_h2645.c
> +++ b/libavcodec/cbs_h2645.c
> @@ -1059,6 +1059,14 @@ static int
> cbs_h266_read_nal_unit(CodedBitstreamContext *ctx,
>  return err;
>
>  switch (unit->type) {
> +case VVC_DCI_NUT:
> +{
> +err = cbs_h266_read_dci(ctx, , unit->content);
> +
> +if (err < 0)
> +return err;
> +}
> +break;
>  case VVC_OPI_NUT:
>  {
>  err = cbs_h266_read_opi(ctx, , unit->content);
> @@ -1601,6 +1609,15 @@ static int
> cbs_h266_write_nal_unit(CodedBitstreamContext *ctx,
>  int err;
>
>  switch (unit->type) {
> +case VVC_DCI_NUT:
> +{
> +H266RawDCI *dci = unit->content;
> +
> +err = cbs_h266_write_dci(ctx, pbc, dci);
> +if (err < 0)
> +return err;
> +}
> +break;
>  case VVC_OPI_NUT:
>  {
>  H266RawOPI *opi = unit->content;
> @@ -1982,6 +1999,7 @@ static void cbs_h266_free_sei(void *opaque, uint8_t
> *content)
>  }
>
>  static const CodedBitstreamUnitTypeDescriptor cbs_h266_unit_types[] = {
> +CBS_UNIT_TYPE_INTERNAL_REF(VVC_DCI_NUT, H266RawDCI,
> extension_data.data),
>  CBS_UNIT_TYPE_INTERNAL_REF(VVC_OPI_NUT, H266RawOPI,
> extension_data.data),
>  CBS_UNIT_TYPE_INTERNAL_REF(VVC_VPS_NUT, H266RawVPS,
> extension_data.data),
>  CBS_UNIT_TYPE_INTERNAL_REF(VVC_SPS_NUT, H266RawSPS,
> extension_data.data),
> diff --git a/libavcodec/cbs_h266.h b/libavcodec/cbs_h266.h
> index 693d1ca1fd..87aa2d849d 100644
> --- a/libavcodec/cbs_h266.h
> +++ b/libavcodec/cbs_h266.h
> @@ -241,6 +241,16 @@ typedef struct H266RawOPI {
>  H266RawExtensionData extension_data;
>  } H266RawOPI;
>
> +typedef struct H266RawDCI {
> +H266RawNALUnitHeader nal_unit_header;
> +
> +uint8_t dci_reserved_zero_4bits;
> +uint8_t dci_num_ptls_minus1;
> +H266RawProfileTierLevel dci_profile_tier_level[VVC_MAX_DCI_PTLS];
> +uint8_t dci_extension_flag;
> +H266RawExtensionData extension_data;
> +} H266RawDCI;
> +
>  typedef struct H266RawVPS {
>  H266RawNALUnitHeader nal_unit_header;
>
> diff --git a/libavcodec/cbs_h266_syntax_template.c
> b/libavcodec/cbs_h266_syntax_template.c
> index d9c8e0afbe..4ea29ec789 100644
> --- a/libavcodec/cbs_h266_syntax_template.c
> +++ b/libavcodec/cbs_h266_syntax_template.c
> @@ -650,6 +650,30 @@ static int FUNC(opi)(CodedBitstreamContext *ctx,
> RWContext *rw,
>  return 0;
>  }
>
> +static int FUNC(dci)(CodedBitstreamContext *ctx, RWContext *rw,
> + H266RawDCI *current)
> +{
> +int err, i;
> +
> +HEADER("Decoding capability information");
> +
> +CHECK(FUNC(nal_unit_header)(ctx, rw,
> +>nal_unit_header, VVC_DCI_NUT));
> +
> +ub(4, dci_reserved_zero_4bits);
> +ub(4, dci_num_ptls_minus1);
> +for (i = 0; i <= current->dci_num_ptls_minus1; i++)
> +CHECK(FUNC(profile_tier_level)(ctx, rw,
> +   current->dci_profile_tier_level +
> i, 1, 0));
> +
> +flag(dci_extension_flag);
> +if (current->dci_extension_flag)
> +CHECK(FUNC(extension_data)(ctx, rw, >extension_data));
> +CHECK(FUNC(rbsp_trailing_bits)(ctx, rw));
> +
> +return 0;
> +}
> +
>  static int FUNC(vps) (CodedBitstreamContext *ctx, RWContext *rw,
>   H266RawVPS *current)
>  {
> diff --git a/libavcodec/vvc.h b/libavcodec/vvc.h
> index 099d2fc2ad..eda1b40eef 100644
> --- a/libavcodec/vvc.h
> +++ b/libavcodec/vvc.h
> @@ -76,6 +76,9 @@ enum {
>  //7.4.3.3 The value of vps_max_sublayers_minus1 shall be in the
> range of 0 to 6, inclusive
>  VVC_MAX_SUBLAYERS = 7,
>
> +//7.3.2.1 dci_num_ptls_minus1 is u(4)
> +VVC_MAX_DCI_PTLS = 16,
> +
>  //7.4.3.3 vps_num_ptls_minus1 is u(8)
>  VVC_MAX_PTLS = 256,
>
> --
> 2.41.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".
>
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] [SDR][RFC] libavradio branch changes

[Michael Niedermayer]

On Mon, Jul 03, 2023 at 10:54:05AM +0200, Paul B Mahol wrote:
> On Mon, Jul 3, 2023 at 7:48 AM Michael Niedermayer 
> wrote:
> 
> > Hi
> >
> > the new libavradio in its new repository needs some changes the problem
> > is that maintaining it in a separate repository AND seperate directory is
> > not
> > so simple
> > But let me show this in numbers, this is the stats of the changes related
> > to the build
> > system that would need to be maintained:
> >
> > commit e262fd4b85a1a3ddf34c365bb88e54cdc6be53eb
> > Author: Michael Niedermayer 
> > Date:   Sun Jul 2 14:08:42 2023 +0200
> >
> > Move sdr to new libavradio
> >
> > Signed-off-by: Michael Niedermayer 
> >
> >  Makefile  |   5 +--
> >  configure |  36
> > --
> >  fftools/ffmpeg.c  |   5 +++
> >  fftools/ffplay.c  |   4 +++
> >  fftools/ffprobe.c |   4 +++
> >  fftools/opt_common.c  |  62
> > ++---
> >  fftools/opt_common.h  |  27 
> >  libavdevice/Makefile  |   1 -
> >  libavdevice/alldevices.c  |   1 -
> >  libavdevice/utils.c   |   2 +-
> >  libavformat/allformats.c  |  32
> > ++-
> >  libavformat/internal.h|   1 +
> >  libavradio/Makefile   |  14 +
> >  libavradio/allradios.c|  65
> > +++
> >  libavradio/avradio.c  |  32
> > +++
> >  libavradio/avradio.h  | 121
> > 
> >  libavradio/internal.h |  28 +
> >  libavdevice/sdrindev.c => libavradio/sdrinradio.c |   2 +-
> >  {libavdevice => libavradio}/utils.c   |   4 +--
> >  libavradio/version.c  |  45
> > +++
> >  libavradio/version.h  |  45
> > +++
> >  libavradio/version_major.h|  36
> > ++
> >  libavutil/log.h   |   1 +
> >  tools/uncoded_frame.c |   4 +++
> >  24 files changed, 554 insertions(+), 23 deletions(-)
> >
> >
> >
> > I do not know if changes to the build system can be marged in git master or
> > if people agree to that at all.
> > But if this needs to be maintained in its current form, it will cause bugs
> > and alot of extra work over time
> >
> > the alternative would be to undo the libavradio thing and rather maintain
> > sdr as input device and demuxer in the libavradio repository
> >


> > Of course having the sdr input device and file demuxer in git master would
> > be the least amount of work
> >
> 
> Everyone is against this, pushing for it will not make it happen.

I think there where about 6 people who had varing levels of dislike to it.
Probably a few more. Thats not everyone

But i have not suggested that to be done now, i have not pushed for that at
all in the text or mail above.
Its just a statement of fact that it would be least work.
That statement, that its least work, has not been disputed by anyone

I mentioned this so people dont miss that the way its done now, has a
cost to it. The 2 repository approuch costs additional time to maintain

Also moving the whole libavradio to git master is not what this mail was
intended to suggest at all.

Thx

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

Take away the freedom of one citizen and you will be jailed, take away
the freedom of all citizens and you will be congratulated by your peers
in Parliament.


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

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

Re: [FFmpeg-devel] [PATCH v2 0/7] Misc AFD improvements and support for Bar Data

[Devin Heitmueller]

Hi Anton,

On Sat, Jul 1, 2023 at 4:14 AM Anton Khirnov  wrote:
>
> IIUC the only source of bar data after this set is the new filter you're
> adding. Is there supposed to be some other demuxer or decoder that
> produces it?

I have support in my tree for the H.264 and HEVC decoders, but I still
need to rebase it against master.

> Also, FATE tests would be much appreciated.

Sure.  At this point it wasn't clear I could do FATE tests since the
patch series today only includes support for filtering and the
decklink output.  I agree though that once the H.264 and/or HEVC stuff
is submitted it makes sense to generate a short sample for FATE usage.

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] Create video from one picture and one audio file

[Matej Marko]

Small update:
 
And this command also does not work correctly. The video is cannot be converted 
for YouTube servers:
After video upload on YouTube I see error message, that video is no possible process, if I create video from this command: 
ffmpeg -r 1 -i 22.jpg -i 22.mp3 -c:a copy -r 1 -c:v libvpx-vp9 video-output2.mkv

 
On VLC player play this video correct. But for youtube servers it is problem.

 
(YouTube servers use probably FFMPEG too)


Thanks for answer Marvin. I am sorry, I am use first time this email 
substrition system.
 
 
__

Od: "Marvin Scholz" 
Komu: "FFmpeg development discussions and patches" 
Dátum: 03.07.2023 14:31
Predmet: Re: [FFmpeg-devel] Create video from one picture and one audio file


On 3 Jul 2023, at 14:13, Matej Marko wrote:

> Create video from one picture and one audio file
>  
> Hello,
>  

You already sent your email once before, do not re-send the
same thing please. If you have things to add, reply to your previously
sent e-mail so it is properly threaded.

> This command not work correct. Video is longer than audio file
> ffmpeg -loop 1 -framerate 2/60 -i 22.jpg -i 22.mp3 -c:v libvpx-vp9 -c:a copy 
-shortest -r 2 video-vystup2.mkv
>  
> This command not work correct too. Video is no possible convert for YouTube 
servers.
> ffmpeg -framerate 1 -i 22.jpg -i 22.mp3 -c:a copy -c:v libvpx-vp9 
video-vystup.mkv
>  
> Audio an picture yo can download here
> https://mega.nz/folder/JuID2BiA#uZ4qVDe6yb0xjDjiXFlJvw 
 
>
>  
> Or can you me please help?
> FFMPEG developers, can you please repair it?
>  
> Thanks
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel 

>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@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 v2 3/7] avcodec/avframe: add new side data types for Bar Data

[Devin Heitmueller]

On Sat, Jul 1, 2023 at 4:11 AM Anton Khirnov  wrote:
> >  /**
> > + * Bar data - used by side data for avcodec and avframe.  Defines the 
> > location
> > + * of horizontal or vertical black bars (i.e. letterbox/pillar bars)
> > + */
> > +typedef struct AVBarData {
> > +int top_bottom; /* 0=top/bottom 1=left/right */
> > +int top;
> > +int left;
> > +int bottom;
> > +int right;
>
> Am I understanding correctly that half of these are never used for a
> given AVBarData instance? Seems wasteful. Could make it a generic
> bound0, bound1 or a union instead.

It was only an extra eight bytes per video frame, so I wasn't
particularly worried about the size.  That said, perhaps a union would
make it more clear that you can't set both simultaneously.

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] Create video from one picture and one audio file

[Marvin Scholz]

On 3 Jul 2023, at 14:13, Matej Marko wrote:

> Create video from one picture and one audio file
>  
> Hello,
>  

You already sent your email once before, do not re-send the
same thing please. If you have things to add, reply to your previously
sent e-mail so it is properly threaded.

> This command not work correct. Video is longer than audio file
> ffmpeg -loop 1 -framerate 2/60 -i 22.jpg -i 22.mp3 -c:v libvpx-vp9 -c:a copy 
> -shortest -r 2 video-vystup2.mkv
>  
> This command not work correct too. Video is no possible convert for YouTube 
> servers.
> ffmpeg -framerate 1 -i 22.jpg -i 22.mp3 -c:a copy -c:v libvpx-vp9 
> video-vystup.mkv
>  
> Audio an picture yo can download here
> https://mega.nz/folder/JuID2BiA#uZ4qVDe6yb0xjDjiXFlJvw 
> 
>  
> Or can you me please help?
> FFMPEG developers, can you please repair it?
>  
> Thanks
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@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] Create video from one picture and one audio file

[Matej Marko]

Create video from one picture and one audio file
 
Hello,
 
This command not work correct. Video is longer than audio file
ffmpeg -loop 1 -framerate 2/60 -i 22.jpg -i 22.mp3 -c:v libvpx-vp9 -c:a copy 
-shortest -r 2 video-vystup2.mkv
 
This command not work correct too. Video is no possible convert for YouTube 
servers.
ffmpeg -framerate 1 -i 22.jpg -i 22.mp3 -c:a copy -c:v libvpx-vp9 
video-vystup.mkv
 
Audio an picture yo can download here
https://mega.nz/folder/JuID2BiA#uZ4qVDe6yb0xjDjiXFlJvw 

 
Or can you me please help?
FFMPEG developers, can you please repair it?
 
Thanks

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

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

[FFmpeg-devel] ffmpeg create video from one picture and one audio file

[Matej Marko]

 
Hello,
official way of ffmpeg bug report actually not work correct. I created 
alternative way of bug report here.
 
This command not worg correct. Video is longer than audio file
ffmpeg -loop 1 -framerate 2/60 -i 22.jpg -i 22.mp3 -c:v libvpx-vp9 -c:a copy 
-shortest -r 2 video-vystup2.mkv
 
This command not worg correct. Video is no possible convert for Youtube 
servers. Youtube servers use FFMPEG too.
ffmpeg -framerate 1 -i 22.jpg -i 22.mp3 -c:a copy -c:v libvpx-vp9 
video-vystup.mkv
 
Developers Can you please repair it?
 
Or can you me please help
 
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] avcodec/vlc: auto calculate depth

[Paul B Mahol]

On Mon, Jul 3, 2023 at 1:56 AM Andreas Rheinhardt <
andreas.rheinha...@outlook.com> wrote:

> Paul B Mahol:
> > Will apply this soon as there are no more comments.
>
> My objection still stands.
>

Your objections are invalid, also you tend to object just to object.


>
> - 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 v2 1/3] avutil/dict: add av_dict_pop

[Marvin Scholz]

On 3 Jul 2023, at 2:18, Andreas Rheinhardt wrote:

> Marvin Scholz:
>> This new API allows to remove an entry and obtain ownership of the
>> key/value that was associated with the removed entry.
>> ---
>>
>> Changes since v1:
>> - Clarify documentation about av_free having to be used.
>> - Fix fate test to not rely on specific error code value
>>
>>  doc/APIchanges |  4 
>>  libavutil/dict.c   | 27 +++
>>  libavutil/dict.h   | 26 ++
>>  libavutil/tests/dict.c | 38 ++
>>  libavutil/version.h|  4 ++--
>>  tests/ref/fate/dict| 12 
>>  6 files changed, 109 insertions(+), 2 deletions(-)
>>
>> diff --git a/doc/APIchanges b/doc/APIchanges
>> index f040211f7d..d55821f682 100644
>> --- a/doc/APIchanges
>> +++ b/doc/APIchanges
>> @@ -2,6 +2,10 @@ The last version increases of all libraries were on 
>> 2023-02-09
>>
>>  API changes, most recent first:
>>
>> +2023-06-02 - xx - lavu 58.14.100 - dict.h
>> +  Add av_dict_pop() to remove an entry from a dict
>> +  and get ownership of the removed key/value.
>> +
>>  2023-05-29 - xx - lavc 60.16.100 - avcodec.h codec_id.h
>>Add AV_CODEC_ID_EVC, FF_PROFILE_EVC_BASELINE, and FF_PROFILE_EVC_MAIN.
>>
>> diff --git a/libavutil/dict.c b/libavutil/dict.c
>> index f673977a98..ac41771994 100644
>> --- a/libavutil/dict.c
>> +++ b/libavutil/dict.c
>> @@ -173,6 +173,33 @@ int av_dict_set_int(AVDictionary **pm, const char *key, 
>> int64_t value,
>>  return av_dict_set(pm, key, valuestr, flags);
>>  }
>>
>> +int av_dict_pop(AVDictionary **pm, const char *key,
>> +char **out_key, char **out_value, int flags)
>> +{
>> +AVDictionary *m = *pm;
>> +AVDictionaryEntry *entry = NULL;
> Why don't you merge this initialization and the assignment below?
>
>> +entry = (AVDictionaryEntry *)av_dict_get(m, key, NULL, flags);
>> +if (!entry)
>> +return AVERROR(ENOENT);
>> +
>> +if (out_key)
>> +*out_key = entry->key;
>> +else
>> +av_free(entry->key);
>> +
>> +if (out_value)
>> +*out_value = entry->value;
>> +else
>> +av_free(entry->value);
>> +
>> +*entry = m->elems[--m->count];
>> +if (m && !m->count) {
>
> The check for m is completely unnecessary; Coverity will probably
> complain about this (because this check implies that m can be NULL, but
> then the line above the check would crash).
>
>> +av_freep(>elems);
>> +av_freep(pm);
>> +}
>> +return 0;
>> +}
>> +
>>  static int parse_key_value_pair(AVDictionary **pm, const char **buf,
>>  const char *key_val_sep, const char 
>> *pairs_sep,
>>  int flags)
>> diff --git a/libavutil/dict.h b/libavutil/dict.h
>> index 713c9e361a..31d38dabec 100644
>> --- a/libavutil/dict.h
>> +++ b/libavutil/dict.h
>> @@ -172,6 +172,32 @@ int av_dict_set(AVDictionary **pm, const char *key, 
>> const char *value, int flags
>>   */
>>  int av_dict_set_int(AVDictionary **pm, const char *key, int64_t value, int 
>> flags);
>>
>> +/**
>> + * Remove the entry with the given key from the dictionary.
>> + *
>> + * Search for an entry matching @p key and remove it, if found. Optionally
>> + * the found key and/or value can be returned using the @p out_key and
>> + * @p out_value arguments.
>> + *
>> + * If more than one entry matches, only one entry is removed and returned
>> + * on each call. Which entry is returned first in that case is undefined.
>> + *
>> + * @param pmPointer to a pointer to a dictionary struct.
>> + * @param key   Entry key to match.
>> + * @param out_key   Pointer whose pointee will be set to the matched
>> + *  entry key. Must be freed using av_dict_free() by
>
> This is wrong: It must be freed using av_free() (or av_freep()); same below.

Indeed, copy paste mistake, sorry.

>
>> + *  the caller. May be NULL.
>> + * @param out_value Pointer whose pointee will be set to the matched
>> + *  entry value. Must be freed using av_dict_free() by
>> + *  the caller. May be NULL.
>> + *
>> + * @retval 0Success
>> + * @retval AVERROR(ENOENT)  No item for the given key found
>> + * @retval "Other (negative) AVERROR"   Other failure
>> + */
>> +int av_dict_pop(AVDictionary **pm, const char *key,
>> +char **out_key, char **out_value, int flags);
>
> It is possible to store multiple entries with the same value in an
> AVDictionary. This function is not designed to handle this case, as one
> can't tell it which one one wants to pop (IIRC the rest of the API does
> not properly support this either, but that is not a reason to add a new
> API with this limitation).

I honestly can't think of a sensible API design for this,
if you have any idea feel free to share.

If the value is known before, using av_dict_pop is 

Re: [FFmpeg-devel] [PATCH v5] avformat/ivfenc: Set the "number of frames" in IVF header

[myp...@gmail.com]

On Mon, Jul 3, 2023 at 12:25 PM Dai, Jianhui J
 wrote:
>
> Should set "number of frames" to bytes 24-27 of IVF header, not
> duration.
> It is described by [1], and confirmed by parsing all IVF files in [2].
>
> This commit also updates the md5sum of refs to pass fate-cbs.
>
> [1] Duck IVF - MultimediaWiki
> https://wiki.multimedia.cx/index.php/Duck_IVF
>
> [2] webm/vp8-test-vectors
> https://chromium.googlesource.com/webm/vp8-test-vectors
>
> Signed-off-by: Jianhui Dai 
> ---
>  libavformat/ivfdec.c| 13 ++---
>  libavformat/ivfenc.c| 13 +
>  tests/ref/fate/cbs-vp9-vp90-2-03-deltaq |  2 +-
>  tests/ref/fate/cbs-vp9-vp90-2-06-bilinear   |  2 +-
>  tests/ref/fate/cbs-vp9-vp90-2-09-lf_deltas  |  2 +-
>  .../ref/fate/cbs-vp9-vp90-2-10-show-existing-frame  |  2 +-
>  .../ref/fate/cbs-vp9-vp90-2-10-show-existing-frame2 |  2 +-
>  tests/ref/fate/cbs-vp9-vp90-2-segmentation-aq-akiyo |  2 +-
>  tests/ref/fate/cbs-vp9-vp90-2-segmentation-sf-akiyo |  2 +-
>  tests/ref/fate/cbs-vp9-vp90-2-tiling-pedestrian |  2 +-
>  tests/ref/fate/cbs-vp9-vp91-2-04-yuv440 |  2 +-
>  tests/ref/fate/cbs-vp9-vp91-2-04-yuv444 |  2 +-
>  tests/ref/fate/cbs-vp9-vp92-2-20-10bit-yuv420   |  2 +-
>  tests/ref/fate/cbs-vp9-vp93-2-20-10bit-yuv422   |  2 +-
>  tests/ref/fate/cbs-vp9-vp93-2-20-12bit-yuv444   |  2 +-
>  15 files changed, 28 insertions(+), 24 deletions(-)
>
> diff --git a/libavformat/ivfdec.c b/libavformat/ivfdec.c
> index 511f2387ed..141ce4f1be 100644
> --- a/libavformat/ivfdec.c
> +++ b/libavformat/ivfdec.c
> @@ -51,11 +51,18 @@ static int read_header(AVFormatContext *s)
>  st->codecpar->codec_id   = ff_codec_get_id(ff_codec_bmp_tags, 
> st->codecpar->codec_tag);
>  st->codecpar->width  = avio_rl16(s->pb);
>  st->codecpar->height = avio_rl16(s->pb);
> -time_base.den = avio_rl32(s->pb);
> -time_base.num = avio_rl32(s->pb);
> -st->duration  = avio_rl32(s->pb);
> +time_base.den= avio_rl32(s->pb);
> +time_base.num= avio_rl32(s->pb);
 Don't piggyback the coding style formatting part
> +st->nb_frames= avio_rl32(s->pb);
>  avio_skip(s->pb, 4); // unused
>
> +// Infer duration from nb_frames, in order to be backward compatible with
> +// previous IVF demuxer.
> +// It is popular to configure time_base to 1/frame_rate by IVF muxer, 
> that
> +// the duration happens to be the same with nb_frames. See
> +// 
> `https://chromium.googlesource.com/webm/vp8-test-vectors/+/refs/heads/main`
> +st->duration = st->nb_frames;
> +
>  ffstream(st)->need_parsing = AVSTREAM_PARSE_HEADERS;
>
>  if (!time_base.den || !time_base.num) {
> diff --git a/libavformat/ivfenc.c b/libavformat/ivfenc.c
> index 47b4efbcd1..88399099d4 100644
> --- a/libavformat/ivfenc.c
> +++ b/libavformat/ivfenc.c
> @@ -72,7 +72,8 @@ static int ivf_write_header(AVFormatContext *s)
>  avio_wl16(pb, par->height);
>  avio_wl32(pb, s->streams[0]->time_base.den);
>  avio_wl32(pb, s->streams[0]->time_base.num);
> -avio_wl64(pb, 0xULL); // length is overwritten at the 
> end of muxing
> +avio_wl32(pb, 0x); // "number of frames" is overwritten at the 
> end of muxing
> +avio_wl32(pb, 0); // unused
>
>  return 0;
>  }
> @@ -99,16 +100,12 @@ static int ivf_write_trailer(AVFormatContext *s)
>  AVIOContext *pb = s->pb;
>  IVFEncContext *ctx = s->priv_data;
>
> -if ((pb->seekable & AVIO_SEEKABLE_NORMAL) &&
> -(ctx->frame_cnt > 1 || (ctx->frame_cnt == 1 && 
> ctx->last_pkt_duration))) {
> +// overwrite the "number of frames"
> +if ((pb->seekable & AVIO_SEEKABLE_NORMAL)) {
>  int64_t end = avio_tell(pb);
>
>  avio_seek(pb, 24, SEEK_SET);
> -// overwrite the "length" field (duration)
> -avio_wl32(pb, ctx->last_pkt_duration ?
> -  ctx->sum_delta_pts + ctx->last_pkt_duration :
> -  ctx->frame_cnt * ctx->sum_delta_pts / (ctx->frame_cnt - 
> 1));
> -avio_wl32(pb, 0); // zero out unused bytes
> +avio_wl32(pb, ctx->frame_cnt);
>  avio_seek(pb, end, SEEK_SET);
>  }
>
> diff --git a/tests/ref/fate/cbs-vp9-vp90-2-03-deltaq 
> b/tests/ref/fate/cbs-vp9-vp90-2-03-deltaq
> index db09cfd5e0..f621d7a480 100644
> --- a/tests/ref/fate/cbs-vp9-vp90-2-03-deltaq
> +++ b/tests/ref/fate/cbs-vp9-vp90-2-03-deltaq
> @@ -1 +1 @@
> -bb630ef560f83951fa6547a664fdb636
> +fe62460fe28202e0666e628afd8602ca
> diff --git a/tests/ref/fate/cbs-vp9-vp90-2-06-bilinear 
> b/tests/ref/fate/cbs-vp9-vp90-2-06-bilinear
> index f579459179..9359e21e40 100644
> --- a/tests/ref/fate/cbs-vp9-vp90-2-06-bilinear
> +++ b/tests/ref/fate/cbs-vp9-vp90-2-06-bilinear
> @@ -1 +1 @@
> -2ca9d012c7212e38f5e2727ac66ec6c5
> +179e228004c396a301c89f34b6c72f68
> diff --git 

Re: [FFmpeg-devel] [SDR][RFC] libavradio branch changes

[Paul B Mahol]

On Mon, Jul 3, 2023 at 7:48 AM Michael Niedermayer 
wrote:

> Hi
>
> the new libavradio in its new repository needs some changes the problem
> is that maintaining it in a separate repository AND seperate directory is
> not
> so simple
> But let me show this in numbers, this is the stats of the changes related
> to the build
> system that would need to be maintained:
>
> commit e262fd4b85a1a3ddf34c365bb88e54cdc6be53eb
> Author: Michael Niedermayer 
> Date:   Sun Jul 2 14:08:42 2023 +0200
>
> Move sdr to new libavradio
>
> Signed-off-by: Michael Niedermayer 
>
>  Makefile  |   5 +--
>  configure |  36
> --
>  fftools/ffmpeg.c  |   5 +++
>  fftools/ffplay.c  |   4 +++
>  fftools/ffprobe.c |   4 +++
>  fftools/opt_common.c  |  62
> ++---
>  fftools/opt_common.h  |  27 
>  libavdevice/Makefile  |   1 -
>  libavdevice/alldevices.c  |   1 -
>  libavdevice/utils.c   |   2 +-
>  libavformat/allformats.c  |  32
> ++-
>  libavformat/internal.h|   1 +
>  libavradio/Makefile   |  14 +
>  libavradio/allradios.c|  65
> +++
>  libavradio/avradio.c  |  32
> +++
>  libavradio/avradio.h  | 121
> 
>  libavradio/internal.h |  28 +
>  libavdevice/sdrindev.c => libavradio/sdrinradio.c |   2 +-
>  {libavdevice => libavradio}/utils.c   |   4 +--
>  libavradio/version.c  |  45
> +++
>  libavradio/version.h  |  45
> +++
>  libavradio/version_major.h|  36
> ++
>  libavutil/log.h   |   1 +
>  tools/uncoded_frame.c |   4 +++
>  24 files changed, 554 insertions(+), 23 deletions(-)
>
>
>
> I do not know if changes to the build system can be marged in git master or
> if people agree to that at all.
> But if this needs to be maintained in its current form, it will cause bugs
> and alot of extra work over time
>
> the alternative would be to undo the libavradio thing and rather maintain
> sdr as input device and demuxer in the libavradio repository
>
> Of course having the sdr input device and file demuxer in git master would
> be the least amount of work
>

Everyone is against this, pushing for it will not make it happen.


>
> thx
>
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> It is a danger to trust the dream we wish for rather than
> the science we have, -- Dr. Kenneth Brown
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@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 v2 00/15] avfilter/vf_bwdif: Add aarch64 neon functions

[John Cox]

On Mon, 3 Jul 2023 00:09:52 +0300 (EEST), you wrote:

>On Sun, 2 Jul 2023, John Cox wrote:
>
>> Also adds a filter_line3 method which on aarch64 neon yields approx 30%
>> speedup over 2xfilter_line and a memcpy
>>
>> Differences from v1:
>> .align 16 corrected to .balign 16
>> SXTW tolower
>> Mac ABI (hopefully) fixed
>> V register pop/push macroed & prettified
>>
>> John Cox (15):
>>  avfilter/vf_bwdif: Add outline for aarch neon functions
>>  avfilter/vf_bwdif: Add common macros and consts for aarch64 neon
>>  avfilter/vf_bwdif: Export C filter_intra
>>  avfilter/vf_bwdif: Add neon for filter_intra
>>  tests/checkasm: Add test for vf_bwdif filter_intra
>>  avfilter/vf_bwdif: Add clip and spatial macros for aarch64 neon
>>  avfilter/vf_bwdif: Export C filter_edge
>>  avfilter/vf_bwdif: Add neon for filter_edge
>>  tests/checkasm: Add test for vf_bwdif filter_edge
>>  avfilter/vf_bwdif: Export C filter_line
>>  avfilter/vf_bwdif: Add neon for filter_line
>>  avfilter/vf_bwdif: Add a filter_line3 method for optimisation
>>  avfilter/vf_bwdif: Add neon for filter_line3
>>  tests/checkasm: Add test for vf_bwdif filter_line3
>>  avfilter/vf_bwdif: Block filter slices into a multiple of 4 lines
>
>Overall, I'd suggest squashing/reordering the patches like this:
>
>- tests/checkasm: Add test for vf_bwdif filter_intra
>- avfilter/vf_bwdif: Add neon for filter_intra
>   (With the preceding patches squashed. For extra common macros, only add
>   the ones you use in this patch here.)
>- tests/checkasm: Add test for vf_bwdif filter_edge
>- avfilter/vf_bwdif: Add neon for filter_edge (with other dependencies
>   squashed)
>- avfilter/vf_bwdif: Add neon for filter_line
>- avfilter/vf_bwdif: Add a filter_line3 method for optimisation
>   + checkasm test squashed
>- avfilter/vf_bwdif: Add neon for filter_line3

I'm happy with that if everyone else is - it is easy to merge patches -
harder to take them apart.

JC

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

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

Re: [FFmpeg-devel] [PATCH 02/15] avfilter/vf_bwdif: Add common macros and consts for aarch64 neon

[John Cox]

On Mon, 3 Jul 2023 00:02:27 +0300 (EEST), you wrote:

>On Sun, 2 Jul 2023, Martin Storsjö wrote:
>
>> On Sun, 2 Jul 2023, John Cox wrote:
>>
>>> On Sun, 2 Jul 2023 00:35:14 +0300 (EEST), you wrote:
>>> 
 On Thu, 29 Jun 2023, John Cox wrote:
 
> Add macros for dual scalar half->single multiply and accumulate
> Add macro for shift, saturate and shorten single to byte
> Add filter constants
> 
> Signed-off-by: John Cox 
> ---
> libavfilter/aarch64/vf_bwdif_neon.S | 46 +
> 1 file changed, 46 insertions(+)
> 
> +
> +.align 16
 
 Note that .align for arm is power of two; this triggers a 2^16 byte
 alignment here, which certainly isn't intended.
>>> 
>>> Yikes! I'll swap that for a .balign now I've looked that up
>>> 
 But in general, the usual way of defining constants is with a
 const/endconst block, which places them in the right rdata section instead
 of in the text section. But that then requires you to use a movrel macro
 for accessing the data, instead of a plain ldr instruction.
>>> 
>>> Yeah - arm has a history of mixing text & const - I went with the
>>> simpler code. Is this a deal breaker or can I leave it as is?
>>
>> I wouldn't treat it as a deal breaker as long as it works across all 
>> platforms - even if consistency with the code style elsewhere is preferred, 
>> but IIRC there may be issues with MS armasm (after passed through 
>> gas-preprocessor). IIRC there might be issues with starting out with 
>> straight 
>> up content without the full setup made by the function/const macros. OTOH I 
>> might have fixed that in gas-preprocessor too...
>>
>> Last time around, the patchset failed building in that configuration due ot 
>> the out of range alignment, I'll see how it fares now.
>
>I'm sorry, but I'd just recommend you to go with the const macros.
>
>Your current patch fails because gas-preprocessor, 
>https://github.com/ffmpeg/gas-preprocessor, doesn't support the .balign 
>directive, it only recognizes .align and .p2align. (Extending it to 
>support it would be trivial though.)
>
>If I change your code to ".align 4", I get the following warning:
>
>\home\martin\code\ffmpeg-msvc-arm64\libavfilter\aarch64\vf_bwdif_neon.o.asm(1011)
> 
>: warning A4228: Alignment value exceeds AREA alignment; alignment not 
>guaranteed
> ALIGN 16
>
>Since we haven't started any section, apparently armasm defaults to a 
>section with 4 byte alignment.
>
>But anyway, regardless of the alignment, it later fails with this error:
>
>\home\martin\code\ffmpeg-msvc-arm64\libavfilter\aarch64\vf_bwdif_neon.o.asm(1051)
> 
>: error A2504: operand 2: Expected address
> ldr q0, coeffs
>
>
>So I would request you to just go with the macros we use elsewhere. The 
>gas-preprocessor/armasm setup doesn't support/expect any random assembly, 
>but the disciplined subset we normally write. In most cases, we 
>essentially never write bare directives in the code, but only use the 
>macros from asm.S, which are set up to handle portability across all 
>supported platforms and their toolchains.

OK - will do.

JC

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

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

Re: [FFmpeg-devel] [PATCH v2 12/15] avfilter/vf_bwdif: Add a filter_line3 method for optimisation

[John Cox]

On Mon, 3 Jul 2023 00:12:46 +0300 (EEST), you wrote:

>On Sun, 2 Jul 2023, Thomas Mundt wrote:
>
>> Am So., 2. Juli 2023 um 14:34 Uhr schrieb John Cox :
>>   Add an optional filter_line3 to the available optimisations.
>>
>>   filter_line3 is equivalent to filter_line, memcpy, filter_line
>>
>>   filter_line shares quite a number of loads and some calculations
>>   in
>>   common with its next iteration and testing shows that using
>>   aarch64
>>   neon filter_line3s performance is 30% better than two
>>   filter_lines
>>   and a memcpy.
>>
>>   Signed-off-by: John Cox 
>>   ---
>>    libavfilter/bwdif.h    |  7 +++
>>    libavfilter/vf_bwdif.c | 31 +++
>>    2 files changed, 38 insertions(+)
>>
>>   diff --git a/libavfilter/bwdif.h b/libavfilter/bwdif.h
>>   index cce99953f3..496cec72ef 100644
>>   --- a/libavfilter/bwdif.h
>>   +++ b/libavfilter/bwdif.h
>>   @@ -35,6 +35,9 @@ typedef struct BWDIFContext {
>>        void (*filter_edge)(void *dst, void *prev, void *cur, void
>>   *next,
>>                            int w, int prefs, int mrefs, int
>>   prefs2, int mrefs2,
>>                            int parity, int clip_max, int spat);
>>   +    void (*filter_line3)(void *dst, int dstride,
>>   +                         const void *prev, const void *cur,
>>   const void *next, int prefs,
>>   +                         int w, int parity, int clip_max);
>>    } BWDIFContext;
>>
>>    void ff_bwdif_init_filter_line(BWDIFContext *bwdif, int
>>   bit_depth);
>>   @@ -53,4 +56,8 @@ void ff_bwdif_filter_line_c(void *dst1, void
>>   *prev1, void *cur1, void *next1,
>>                                int prefs3, int mrefs3, int prefs4,
>>   int mrefs4,
>>                                int parity, int clip_max);
>>
>>   +void ff_bwdif_filter_line3_c(void * dst1, int d_stride,
>>   +                             const void * prev1, const void *
>>   cur1, const void * next1, int s_stride,
>>   +                             int w, int parity, int clip_max);
>>   +
>>    #endif /* AVFILTER_BWDIF_H */
>>   diff --git a/libavfilter/vf_bwdif.c b/libavfilter/vf_bwdif.c
>>   index 26349da1fd..52bc676cf8 100644
>>   --- a/libavfilter/vf_bwdif.c
>>   +++ b/libavfilter/vf_bwdif.c
>>   @@ -150,6 +150,31 @@ void ff_bwdif_filter_line_c(void *dst1,
>>   void *prev1, void *cur1, void *next1,
>>        FILTER2()
>>    }
>>
>>   +#define NEXT_LINE()\
>>   +    dst += d_stride; \
>>   +    prev += prefs; \
>>   +    cur  += prefs; \
>>   +    next += prefs;
>>   +
>>   +void ff_bwdif_filter_line3_c(void * dst1, int d_stride,
>>   +                             const void * prev1, const void *
>>   cur1, const void * next1, int s_stride,
>>   +                             int w, int parity, int clip_max)
>>   +{
>>   +    const int prefs = s_stride;
>>   +    uint8_t * dst  = dst1;
>>   +    const uint8_t * prev = prev1;
>>   +    const uint8_t * cur  = cur1;
>>   +    const uint8_t * next = next1;
>>   +
>>   +    ff_bwdif_filter_line_c(dst, (void*)prev, (void*)cur,
>>   (void*)next, w,
>>   +                           prefs, -prefs, prefs * 2, - prefs *
>>   2, prefs * 3, -prefs * 3, prefs * 4, -prefs * 4, parity,
>>   clip_max);
>>   +    NEXT_LINE();
>>   +    memcpy(dst, cur, w);
>>   +    NEXT_LINE();
>>   +    ff_bwdif_filter_line_c(dst, (void*)prev, (void*)cur,
>>   (void*)next, w,
>>   +                           prefs, -prefs, prefs * 2, - prefs *
>>   2, prefs * 3, -prefs * 3, prefs * 4, -prefs * 4, parity,
>>   clip_max);
>>   +}
>>   +
>>    void ff_bwdif_filter_edge_c(void *dst1, void *prev1, void
>>   *cur1, void *next1,
>>                                int w, int prefs, int mrefs, int
>>   prefs2, int mrefs2,
>>                                int parity, int clip_max, int spat)
>>   @@ -244,6 +269,11 @@ static int filter_slice(AVFilterContext
>>   *ctx, void *arg, int jobnr, int nb_jobs)
>>                                   refs << 1, -(refs << 1),
>>                                   td->parity ^ td->tff, clip_max,
>>                                   (y < 2) || ((y + 3) > td->h) ? 0
>>   : 1);
>>   +            } else if (s->filter_line3 && y + 2 < slice_end &&
>>   y + 6 < td->h) {
>>   +                s->filter_line3(dst,
>>   td->frame->linesize[td->plane],
>>   +                                prev, cur, next, linesize,
>>   td->w,
>>   +                                td->parity ^ td->tff,
>>   clip_max);
>>   +                y += 2;
>>                } else {
>>                    s->filter_line(dst, prev, cur, next, td->w,
>>                                   

Re: [FFmpeg-devel] [PATCH] libswscale/riscv: Fix syntax of vsetvli

[Rémi Denis-Courmont]

Hi,

The diff is ok. I even have a slight incline in favour thereof for the sake of 
consistency. Yet, I may be vainly pedantic but I do have problems with the 
description.

Le 3 juillet 2023 05:44:12 GMT+03:00, Khem Raj  a écrit :
>Add missing operand

The spec does explicitly make the mask and tail policy mandatory, but I can't 
see any such requirements for the group multiplier. To the contrary, there are 
several examples in the spec _without_ explicit multiplier.

In reality, `vsetvli` (and `vsetivli`) merely transfers an immediate value to 
the vector configuration register. Missing fields are to be left at zero for 
forward compatibility, and `m1` happens to encode as 0b000.

> Which clang complains about but gcc assumes it to be
>'m1' if not specifiied.

The technical term for the RISC-V support in LLVM AS version 15 and earlier is 
"useless junk". If you want to compile FFmpeg on RISC-V with Clang, you *must* 
disable the integrated AS and use binutils GNU/as instead.

The Linux RISC-V kernel altogether gave up on LLVM entirely, requiring GCC for 
RVV, so they're even stricter (and without kernel support, FFmpeg support is 
obviously useless).

*Hopefully* LLVM gets their act together by release 16, and ship a usable 
assembler, rather than tell us to use automatic RVV vectorisation (which *is* a 
release 16 feature, though it was half-baked last time I tried).

>
>Fixes building with clang

More like bug-compatible work-around than fix, AFAIU.

>| src/libswscale/riscv/rgb2rgb_rvv.S:88:25: error: operand must be 
>e[8|16|32|64|128|256|512|1024],m[1|2|4|8|f2|f4|f8],[ta|tu],[ma|mu]

Do you have a reference to the Github RVV spec to validate this, that I 
overlooked, or it's just misled and misleading spew from LLVM?

>| vsetvli t4, t3, e8, ta, ma
>| ^
>
>Signed-off-by: Khem Raj 
>---
> libswscale/riscv/rgb2rgb_rvv.S | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
>diff --git a/libswscale/riscv/rgb2rgb_rvv.S b/libswscale/riscv/rgb2rgb_rvv.S
>index 5626d906eb..bbdfdbebbc 100644
>--- a/libswscale/riscv/rgb2rgb_rvv.S
>+++ b/libswscale/riscv/rgb2rgb_rvv.S
>@@ -85,7 +85,7 @@ func ff_interleave_bytes_rvv, zve32x
> mv  t3, a3
> addia4, a4, -1
> 2:
>-vsetvlit4, t3, e8, ta, ma
>+vsetvlit4, t3, e8, m1, ta, ma
> subt3, t3, t4
> vle8.v v8, (t0)
> addt0, t4, t0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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