[FFmpeg-devel] Modifying mpegts.c to add support for JPEGXS - how to inject video descriptor from PMT into stream

[ffmpeg]

Hi Folks

I am trying to add decode support for VSF TR-07 (JPEGXS in transport stream),  
using the intel JPEGXS project for the codec part.  The Intel code gets JPEGXS 
working fine in FFMPEG via mkv or mp4 files but it doesnt implement transport 
stream support for the new codec so TR07 doesnt work yet

JPEGXS TR07 requires a video descriptor block in the PMT entry for the JPEGXS 
pid. feeding in a known good T07 stream,  I have successfully parsed that data 
in the call parse_stream_identifier_desc() made from pmt_cb() function in 
mpegts.c, but its unclear how to connect this metadata I have extracted to the 
internal stream which has been created.

Can I inject that newly found video description data into the stream from 
inside pmt_cb() ? or does this happen somewhere else ?

As it stands (since I am not actually doing anything with the parsed 
descriptor), I still get the error : 

mpegts @ 0x7fac96104440] Could not find codec parameters for stream 0 (Video: 
jpegxs, 1 reference frame (2[0][0][0] / 0x0032), none): unspecified 
sizeConsider increasing the value for the 'analyzeduration' (0) and 'probesize' 
(500) options

and as you can see, it doesn't get things like the dimensions when summarising 
the stream.

INPUT FMT: Video: jpegxs, 1 reference frame (2[0][0][0] / 0x0032), none
  Stream #0:0[0x100], 34, 1/9: Video: jpegxs, 1 reference frame (2[0][0][0] 
/ 0x0032), none, 60 fps, 60 tbr, 90k tbn
Metadata:
  SRCPID  : 256

Could anyone advise how to connect the dots between parsing the PMT and getting 
that data into the streams parameters  ?

Thanks !!!


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

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

Re: [FFmpeg-devel] [PATCH v2] lavu/opt: Clarify that AVOptions is not indended for general use

[Michael Niedermayer]

On Tue, Apr 23, 2024 at 12:54:53PM +0100, Andrew Sayers wrote:
> On Tue, Apr 23, 2024 at 01:18:28PM +0200, Michael Niedermayer wrote:
> > On Tue, Apr 23, 2024 at 01:15:52PM +0200, Michael Niedermayer wrote:
> > > On Tue, Apr 23, 2024 at 11:10:43AM +0100, Andrew Sayers wrote:
> > > > On Tue, Apr 23, 2024 at 12:04:34PM +0200, Anton Khirnov wrote:
> > > > > Quoting Andrew Sayers (2024-04-23 11:51:00)
> > > > > > On Tue, Apr 23, 2024 at 11:21:27AM +0200, Anton Khirnov wrote:
> > > > > > > > lavu/opt: Clarify that AVOptions is not indended for general use
> > > > > > > 
> > > > > > > They _are_ intended for general use though.
> > > > > > 
> > > > > > In that case I'm confused...
> > > > > > 
> > > > > > Let's say I make a desktop app to transcode videos.  Obviously I 
> > > > > > would use
> > > > > > AVOptions to display configuration options for different encoders.  
> > > > > > And it's
> > > > > > possible to create AVOptions objects for my UI.  But how strongly 
> > > > > > is that use
> > > > > > case recommended?
> > > > > > 
> > > > > > To provide a particularly difficult example - let's say I want to 
> > > > > > let the user
> > > > > > choose between interface themes, and I want to show both some text 
> > > > > > and a
> > > > > > picture of the theme.  AVOption doesn't include a "text + picture" 
> > > > > > option,
> > > > > > so how would I extend it to meet my needs?
> > > > > 
> > > > > If they fit your use case, then use them, otherwise don't - that's 
> > > > > true
> > > > > for pretty much all APIs we provide.
> > > > 
> > > > Ah ok, so how about if I changed "intended" to "optimized" in the 
> > > > subject?
> > > 
> > > If FFmpeg which is a multimedia tool in no place needs or wants to store
> > > pictures through its option API in a way not curently supported.
> > > I would say thats not going to qualify as "general use" outside 
> > > specialized
> > > software thats already dealing with a lot of pictures
> > > 
> > > still you certainly can handle binary data (like a bitmap picture) through
> > > AVOption
> > 
> > And if you disagree, which you probably do :)
> > send a patch to improve AVOption to cover more general use
> 
> Not sure if that's aimed at the real me, or the hypothetical me that wants to
> make a desktop app.  The hypothetical me wants not to throw away a week's work
> because he did everything through AVOptions then came across some edge case
> that doesn't fit into the AVOptions model.  The real me doesn't want to throw
> away a week's work because I avoided AVOptions then found some bit of 
> interface
> that needs me to express my program in an AVOptions-compatible way.  Neither 
> of
> us mind what the answer is, so long as it's written down somewhere we would
> spot during the design stage.
> 
> It sounds like the consensus is that people are *allowed* to implement their
> own AVOption interfaces if they want to, but that there's no expectation for
> them to do so unless they're working on FFmpeg itself.  That suggests the body
> of the patch is fine, but the subject needs improvement?
> 
> How about 'Clarify that "Implementing AVOptions" is addressed to people 
> working
> on FFmpeg itself'?

I think the way i would put it is:
AVOption is intended for general use.
If you have a use case that it cannot be used for, a clean patch to improve it 
is welcome.

What i do not like is, taking a limitation (noone seems to have hit before)
and documenting it as if it was intended.

thx

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

While the State exists there can be no freedom; when there is freedom there
will be no State. -- Vladimir Lenin


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

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

[FFmpeg-devel] [PATCH] avcodec/mediacodecenc: Flush bsf after create extradata

[Zhao Zhili]

From: Zhao Zhili 

Avoid leaving any data inside bsf while also avoid keep bsf in
EOF state.
---
 libavcodec/mediacodecenc.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/libavcodec/mediacodecenc.c b/libavcodec/mediacodecenc.c
index c87a0d86c5..bbf570e7be 100644
--- a/libavcodec/mediacodecenc.c
+++ b/libavcodec/mediacodecenc.c
@@ -681,6 +681,7 @@ bailout:
 s->eof_sent = 0;
 ff_AMediaCodec_flush(s->codec);
 }
+av_bsf_flush(s->bsf);
 av_packet_free();
 return ret;
 }
-- 
2.25.1

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

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

Re: [FFmpeg-devel] [PATCH v2] lavu/opt: Clarify that AVOptions is not indended for general use

[Vittorio Giovara]

On Tue, Apr 23, 2024 at 4:55 AM Andrew Sayers 
wrote:

> The hypothetical me wants not to throw away a week's work
> because he did everything through AVOptions then came across some edge case
> that doesn't fit into the AVOptions model.


Out of curiosity, what are those edge cases?
-- 
Vittorio
___
ffmpeg-devel mailing list
ffmpeg-devel@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] [PATCHSET] AAC decoder refactor

[Lynne]

Apr 22, 2024, 09:20 by d...@lynne.ee:

> Apr 22, 2024, 00:19 by mich...@niedermayer.cc:
>
>> On Fri, Apr 12, 2024 at 11:11:53AM +0200, Lynne wrote:
>>
>>> Apr 12, 2024, 00:45 by mich...@niedermayer.cc:
>>>
>>> > On Thu, Apr 11, 2024 at 07:42:37AM +0200, Lynne wrote:
>>> >
>>> >> Apr 10, 2024, 23:57 by mich...@niedermayer.cc:
>>> >>
>>> >> > On Wed, Apr 10, 2024 at 08:18:11PM +0200, Michael Niedermayer wrote:
>>> >> >
>>> >> >> On Wed, Apr 10, 2024 at 06:48:26PM +0200, Lynne wrote:
>>> >> >> > Apr 8, 2024, 09:36 by d...@lynne.ee:
>>> >> >> > 
>>> >> >> > > The following patchset refactors the AAC decoder step by step,
>>> >> >> > > removing all large-scale templating and abstracting away typed
>>> >> >> > > DSP functions from symbol parsing.
>>> >> >> > >
>>> >> >> > > This series saves 110Kib of binary data from libavcodec.so
>>> >> >> > > when compiled with Clang 18 with -O3, after stripping.
>>> >> >> > >
>>> >> >> > > The patchset can also be viewed here:
>>> >> >> > > https://github.com/cyanreg/FFmpeg/tree/aac_cleanup
>>> >> >> > >
>>> >> >> > > Fate passes on each step, and I've been running this patchset for
>>> >> >> > > a week with no issues.
>>> >> >> > >
>>> >> >> > > This also prepares the decoder for USAC support.
>>> >> >> > >
>>> >> >> > 
>>> >> >> > I've rebased the linked repo to current git master if anyone
>>> >> >> > wants to test.
>>> >> >>
>>> >> >> thanks, i will try to test it
>>> >> >>
>>> >> >
>>> >> > make fate-source
>>> >> >
>>> >> > TESTsource
>>> >> > --- ./tests/ref/fate/source2024-04-08 18:26:00.670129617 +0200
>>> >> > +++ tests/data/fate/source 2024-04-10 23:56:18.032896853 +0200
>>> >> > @@ -22,6 +22,13 @@
>>> >> >  compat/djgpp/math.h
>>> >> >  compat/float/float.h
>>> >> >  compat/float/limits.h
>>> >> > +libavcodec/aac/aacdec.h
>>> >> > +libavcodec/aac/aacdec_fixed_coupling.h
>>> >> > +libavcodec/aac/aacdec_fixed_dequant.h
>>> >> > +libavcodec/aac/aacdec_fixed_prediction.h
>>> >> > +libavcodec/aac/aacdec_float_coupling.h
>>> >> > +libavcodec/aac/aacdec_float_prediction.h
>>> >> > +libavcodec/aac/aacdec_latm.h
>>> >> >  libavcodec/bitstream_template.h
>>> >> >  tools/decode_simple.h
>>> >> >  Use of av_clip() where av_clip_uintp2() could be used:
>>> >> > Test source failed. Look at tests/data/fate/source.err for details.
>>> >> > tests/Makefile:310: recipe for target 'fate-source' failed
>>> >> > make: *** [fate-source] Error 1
>>> >> >
>>> >>
>>> >> Thanks for testing. Fixed both issues in the repo.
>>> >> Was only testing with fate-aac while developing.
>>> >>
>>> >
>>> > mips:
>>> >
>>> > make  -k
>>> > LDffmpeg_g
>>> > libavcodec/libavcodec.a(aacsbr.o): In function 
>>> > `ff_aac_sbr_ctx_alloc_init':
>>> > aacsbr.c:(.text.unlikely+0x1d4): undefined reference to 
>>> > `ff_aacsbr_func_ptr_init_mips'
>>> > aacsbr.c:(.text.unlikely+0x200): undefined reference to 
>>> > `ff_aacsbr_func_ptr_init_mips'
>>> > libavcodec/libavcodec.a(sbrdsp.o): In function `ff_sbrdsp_init':
>>> > sbrdsp.c:(.text.unlikely+0x10): undefined reference to 
>>> > `ff_sbrdsp_init_mips'
>>> > sbrdsp.c:(.text.unlikely+0xb4): undefined reference to 
>>> > `ff_sbrdsp_init_mips'
>>> > libavcodec/libavcodec.a(aacpsdsp_float.o): In function `ff_psdsp_init':
>>> > aacpsdsp_float.c:(.text.unlikely+0x10): undefined reference to 
>>> > `ff_psdsp_init_mips'
>>> > aacpsdsp_float.c:(.text.unlikely+0x6c): undefined reference to 
>>> > `ff_psdsp_init_mips'
>>> > collect2: error: ld returned 1 exit status
>>> > Makefile:136: recipe for target 'ffmpeg_g' failed
>>> > make: *** [ffmpeg_g] Error 1
>>> > LDffprobe_g
>>> > libavcodec/libavcodec.a(aacsbr.o): In function 
>>> > `ff_aac_sbr_ctx_alloc_init':
>>> > aacsbr.c:(.text.unlikely+0x1d4): undefined reference to 
>>> > `ff_aacsbr_func_ptr_init_mips'
>>> > aacsbr.c:(.text.unlikely+0x200): undefined reference to 
>>> > `ff_aacsbr_func_ptr_init_mips'
>>> > libavcodec/libavcodec.a(sbrdsp.o): In function `ff_sbrdsp_init':
>>> > sbrdsp.c:(.text.unlikely+0x10): undefined reference to 
>>> > `ff_sbrdsp_init_mips'
>>> > sbrdsp.c:(.text.unlikely+0xb4): undefined reference to 
>>> > `ff_sbrdsp_init_mips'
>>> > libavcodec/libavcodec.a(aacpsdsp_float.o): In function `ff_psdsp_init':
>>> > aacpsdsp_float.c:(.text.unlikely+0x10): undefined reference to 
>>> > `ff_psdsp_init_mips'
>>> > aacpsdsp_float.c:(.text.unlikely+0x6c): undefined reference to 
>>> > `ff_psdsp_init_mips'
>>> > collect2: error: ld returned 1 exit status
>>> > Makefile:136: recipe for target 'ffprobe_g' failed
>>> > make: *** [ffprobe_g] Error 1
>>> > make: Target 'all' not remade because of errors.
>>> >
>>>
>>> Fixed. This should be all.
>>> On the Loongson machine I have access to, I can't compile FFmpeg
>>> due to missing asm/errno.h kernel header, while on the standard MIPS64
>>> machine I can access, compilation worked either way.
>>>
>>> Would you mind testing again the new version in the repo?
>>>
>>
>> it works on my qemu based mips. I did give the loongson to anton 2 years 

[FFmpeg-devel] Request for Official GitHub Mirror of rtmpdump for Enhanced Security

[Javier Matos Denizac via ffmpeg-devel]

Dear FFmpeg team,


My name is Javier Matos, and I am part of the vcpkg team at Microsoft. vcpkg is 
an open-source package manager designed to help developers manage C++ libraries 
across platforms in a consistent manner.

I am reaching out to inquire if FFmpeg could host an official GitHub mirror for 
the `rtmpdump` repository on `github.com/FFmpeg`.

Currently, vcpkg uses a mirrored version from `github.com/mirror/rtmpdump`, 
which is not maintained by the original authors, posing a significant supply 
chain risk due to potential unauthorized modifications.

Alternatively, while we could switch to using the repository at 
`git://git.ffmpeg.org/rtmpdump.git`, this source lacks support for SHA512 
checksums, complicating asset caching and security verification crucial for 
ensuring the integrity of the code during downloads.

An official GitHub mirror hosted by FFmpeg would address these issues by 
providing a secure, verifiable source that we can integrate with vcpkg. Thank 
you for considering this request. I look forward to your feedback.

Best regards,

Javier Matos
___
ffmpeg-devel mailing list
ffmpeg-devel@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] lavu/opt: Clarify that AVOptions is not indended for general use

[James Almer]

On 4/23/2024 8:15 AM, Michael Niedermayer wrote:

On Tue, Apr 23, 2024 at 11:10:43AM +0100, Andrew Sayers wrote:

On Tue, Apr 23, 2024 at 12:04:34PM +0200, Anton Khirnov wrote:

Quoting Andrew Sayers (2024-04-23 11:51:00)

On Tue, Apr 23, 2024 at 11:21:27AM +0200, Anton Khirnov wrote:

lavu/opt: Clarify that AVOptions is not indended for general use


They _are_ intended for general use though.


In that case I'm confused...

Let's say I make a desktop app to transcode videos.  Obviously I would use
AVOptions to display configuration options for different encoders.  And it's
possible to create AVOptions objects for my UI.  But how strongly is that use
case recommended?

To provide a particularly difficult example - let's say I want to let the user
choose between interface themes, and I want to show both some text and a
picture of the theme.  AVOption doesn't include a "text + picture" option,
so how would I extend it to meet my needs?


If they fit your use case, then use them, otherwise don't - that's true
for pretty much all APIs we provide.


Ah ok, so how about if I changed "intended" to "optimized" in the subject?


If FFmpeg which is a multimedia tool in no place needs or wants to store
pictures through its option API in a way not curently supported.
I would say thats not going to qualify as "general use" outside specialized
software thats already dealing with a lot of pictures

still you certainly can handle binary data (like a bitmap picture) through
AVOption

thx


Take for example AVIAMFReconGain.recon_gain in libavutil/iamf.h, which 
is currently the only field not covered by an AVOption (And thus not 
currently configurable from the CLI). How could it be supported? Binary 
type doesn't work because it expects a pointer + size field and 
allocates the former.

___
ffmpeg-devel mailing list
ffmpeg-devel@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] lavu/opt: Clarify that AVOptions is not indended for general use

[Michael Niedermayer]

On Tue, Apr 23, 2024 at 05:24:03PM -0300, James Almer wrote:
> On 4/23/2024 8:15 AM, Michael Niedermayer wrote:
> > On Tue, Apr 23, 2024 at 11:10:43AM +0100, Andrew Sayers wrote:
> > > On Tue, Apr 23, 2024 at 12:04:34PM +0200, Anton Khirnov wrote:
> > > > Quoting Andrew Sayers (2024-04-23 11:51:00)
> > > > > On Tue, Apr 23, 2024 at 11:21:27AM +0200, Anton Khirnov wrote:
> > > > > > > lavu/opt: Clarify that AVOptions is not indended for general use
> > > > > > 
> > > > > > They _are_ intended for general use though.
> > > > > 
> > > > > In that case I'm confused...
> > > > > 
> > > > > Let's say I make a desktop app to transcode videos.  Obviously I 
> > > > > would use
> > > > > AVOptions to display configuration options for different encoders.  
> > > > > And it's
> > > > > possible to create AVOptions objects for my UI.  But how strongly is 
> > > > > that use
> > > > > case recommended?
> > > > > 
> > > > > To provide a particularly difficult example - let's say I want to let 
> > > > > the user
> > > > > choose between interface themes, and I want to show both some text 
> > > > > and a
> > > > > picture of the theme.  AVOption doesn't include a "text + picture" 
> > > > > option,
> > > > > so how would I extend it to meet my needs?
> > > > 
> > > > If they fit your use case, then use them, otherwise don't - that's true
> > > > for pretty much all APIs we provide.
> > > 
> > > Ah ok, so how about if I changed "intended" to "optimized" in the subject?
> > 
> > If FFmpeg which is a multimedia tool in no place needs or wants to store
> > pictures through its option API in a way not curently supported.
> > I would say thats not going to qualify as "general use" outside specialized
> > software thats already dealing with a lot of pictures
> > 
> > still you certainly can handle binary data (like a bitmap picture) through
> > AVOption
> > 
> > thx
> 
> Take for example AVIAMFReconGain.recon_gain in libavutil/iamf.h, which is
> currently the only field not covered by an AVOption (And thus not currently
> configurable from the CLI). How could it be supported? Binary type doesn't
> work because it expects a pointer + size field and allocates the former.

i would guess some form of AV_OPT_TYPE_FLAG_ARRAY

we have similar arrays like intra_matrix in mpeg codecs

thx

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Its not that you shouldnt use gotos but rather that you should write
readable code and code with gotos often but not always is less readable


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] lavu/opt: Clarify that AVOptions is not indended for general use

[Andrew Sayers]

On Tue, Apr 23, 2024 at 10:28:38AM -0700, Vittorio Giovara wrote:
> On Tue, Apr 23, 2024 at 4:55 AM Andrew Sayers 
> wrote:
> 
> > The hypothetical me wants not to throw away a week's work
> > because he did everything through AVOptions then came across some edge case
> > that doesn't fit into the AVOptions model.
> 
> 
> Out of curiosity, what are those edge cases?

It's really more a question of how to recover from the thing you didn't think
of, which makes it hard to think of good examples ;)

But since you ask, it might be worth looking at SANE option descriptors[0].
They perform a very similar function to AVOptions (providing a flexible
configuration API for a C codebase), and have a 90% overlap in features.  But
for example, SANE doesn't have an equivalent of AVRational, while AVOptions
doesn't have an equivalent of option groups.  More importantly, some things are
technically compatible but perform unobviously different jobs, like how SANE's
"description" text seems to do the same as FFmpeg's "help" text, but if memory
serves descriptions are usually several paragraphs while help is usually a
sentence or two.  It would waste a lot of time if I coded up a whole program
only to discover the SANE config screen had nicely-grouped options with
novel-length tooltips, while the FFmpeg config screen had a flat list of
well-described options that would have looked good if I'd picked an interface
with a search bar.

In a situation like that, it would be very helpful to know that FFmpeg's
position is "have a go and send us a patch if it works" rather than e.g. "we
never got round to making that private" or "we're in the middle of spinning
that off as a standalone library".  I'll have a think overnight and submit an
updated patch tomorrow based on everyone's feedback (thanks!).

[0] http://www.sane-project.org/html/doc011.html#s4.2.9
___
ffmpeg-devel mailing list
ffmpeg-devel@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] lavu/opt: Clarify that AVOptions is not indended for general use

[Andrew Sayers]

On Tue, Apr 23, 2024 at 07:52:49PM +0100, Andrew Sayers wrote:
> On Tue, Apr 23, 2024 at 10:28:38AM -0700, Vittorio Giovara wrote:
> > On Tue, Apr 23, 2024 at 4:55 AM Andrew Sayers 
> > wrote:
> > 
> > > The hypothetical me wants not to throw away a week's work
> > > because he did everything through AVOptions then came across some edge 
> > > case
> > > that doesn't fit into the AVOptions model.
> > 
> > 
> > Out of curiosity, what are those edge cases?
> 
> It's really more a question of how to recover from the thing you didn't think
> of, which makes it hard to think of good examples ;)
> 
> But since you ask, it might be worth looking at SANE option descriptors[0].
> They perform a very similar function to AVOptions (providing a flexible
> configuration API for a C codebase), and have a 90% overlap in features.  But
> for example, SANE doesn't have an equivalent of AVRational, while AVOptions
> doesn't have an equivalent of option groups.  More importantly, some things 
> are
> technically compatible but perform unobviously different jobs, like how SANE's
> "description" text seems to do the same as FFmpeg's "help" text, but if memory
> serves descriptions are usually several paragraphs while help is usually a
> sentence or two.  It would waste a lot of time if I coded up a whole program
> only to discover the SANE config screen had nicely-grouped options with
> novel-length tooltips, while the FFmpeg config screen had a flat list of
> well-described options that would have looked good if I'd picked an interface
> with a search bar.
> 
> In a situation like that, it would be very helpful to know that FFmpeg's
> position is "have a go and send us a patch if it works" rather than e.g. "we
> never got round to making that private" or "we're in the middle of spinning
> that off as a standalone library".  I'll have a think overnight and submit an
> updated patch tomorrow based on everyone's feedback (thanks!).
> 
> [0] http://www.sane-project.org/html/doc011.html#s4.2.9

At the risk of further complicating a conversation that's already drifting
off-topic, a better example might be Video4Linux2 configuration.  Not only does
it have data types unsupported by AVOptions (like "menu"), but also does things
like making some options constant depending on the value of others (e.g. you
can't change the frame rate if you've selected "automatic frame rate").  A
quick look at v4l2_m2m_enc.c suggests that FFmpeg has decided to just put up
with limited configurability, rather than do something crazy like dynamically
allocate new AVClasses at runtime.  That's a limitation I'd need to know about
if I made a chat app, but also a guarantee that helps me understand how
AVOptions works.

Looping back to a point from before, I can work with either answer, the value
is simply in *having* an answer.
___
ffmpeg-devel mailing list
ffmpeg-devel@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] avutil/opt: add support for children objects in av_opt_serialize

[James Almer]

On 4/15/2024 9:51 AM, James Almer wrote:

On 4/12/2024 8:16 PM, James Almer wrote:

Signed-off-by: James Almer 
---
  libavutil/opt.c   | 65 +--
  libavutil/opt.h   |  1 +
  libavutil/tests/opt.c | 47 +--
  tests/ref/fate/opt    |  2 +-
  4 files changed, 90 insertions(+), 25 deletions(-)


Ping.


Will apply the set (four 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 v2] lavu/opt: Clarify that AVOptions is not indended for general use

[Stefano Sabatini]

Il mar 23 apr 2024, 13:18 Michael Niedermayer  ha
scritto:

> On Tue, Apr 23, 2024 at 01:15:52PM +0200, Michael Niedermayer wrote:
> > On Tue, Apr 23, 2024 at 11:10:43AM +0100, Andrew Sayers wrote:
> > > On Tue, Apr 23, 2024 at 12:04:34PM +0200, Anton Khirnov wrote:
> > > > Quoting Andrew Sayers (2024-04-23 11:51:00)
> > > > > On Tue, Apr 23, 2024 at 11:21:27AM +0200, Anton Khirnov wrote:
> > > > > > > lavu/opt: Clarify that AVOptions is not indended for general
> use
> > > > > >
> > > > > > They _are_ intended for general use though.
> > > > >
> > > > > In that case I'm confused...
> > > > >
> [...]
> > still you certainly can handle binary data (like a bitmap picture)
> through
> > AVOption
>
> And if you disagree, which you probably do :)
> send a patch to improve AVOption to cover more general use
>

I think the real point is not that AVOptions/AVClass cannot be used in a
generic application, but that using them is not the point of employing
libav* libraries. In fact, if only part of your application is about
multimedia, probably you will be using the encoding or muxing or filtering
API but it's unlikely you will use AVOptions for generic non-multimedia
code, and you will be already using some other generic toolkit for handling
struct properties. This entails that practically AVOptions/AVClass is
mostly used to develop FFmpeg internals.

So even if the AVOptions API is generic, its use is not really the selling
point of the FFmpeg libraries, and therefore the user is not really
*expected* to use directly them to extend his generic structs, even if that
might be possible.

>
___
ffmpeg-devel mailing list
ffmpeg-devel@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: use HOSTEXESUF when calling binary

[Timo Rothenpieler]

On 24.04.2024 00:01, James Almer wrote:

On 4/23/2024 6:57 PM, Timo Rothenpieler wrote:

This is neccesary on WSL, and has no averse effects in normal
environments.
---
  doc/Makefile | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/doc/Makefile b/doc/Makefile
index 67586e4b74..98d29f1c66 100644
--- a/doc/Makefile
+++ b/doc/Makefile
@@ -60,7 +60,7 @@ GENTEXI := $(GENTEXI:%=doc/avoptions_%.texi)
  $(GENTEXI): TAG = GENTEXI
  $(GENTEXI): doc/avoptions_%.texi: doc/print_options$(HOSTEXESUF)
-    $(M)doc/print_options $* > $@
+    $(M)doc/print_options$(HOSTEXESUF) $* > $@
  doc/%.html: TAG = HTML
  doc/%-all.html: TAG = HTML


LGTM. It's even how it's named in the dependency on the line above.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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


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

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

[FFmpeg-devel] Fw: Your GSoC Org has 0 Contributors ranked - deadline is 1800 UTC April 24

[Michael Niedermayer]

Hi all

I just got the mail below. I assume the other admins are going to rank them
before the deadline like they did last year. (but i can of course not assume
that because there is no time if that doesnt happen)
I have not followed GSoC last year or this year much ...

Either way, if you are a mentor and want your student to receive a slot
tell me privatly (with thilo and reynaldo in CC) ASAP how you would
rank your student. And i will rank him/her accordingly if i see noone
else starting to assign ranks

thx

- Forwarded message from Stephanie Taylor  -

Date: Tue, 23 Apr 2024 15:55:36 -0700
From: Stephanie Taylor 
To: undisclosed-recipients: ;
Subject: Your GSoC Org has 0 Contributors ranked - deadline is 1800 UTC April 24

Hello GSoC Org Admin,


You are receiving this email because you are an Org Admin and your org
currently has 0 (zero) GSoC 2024 proposals ranked and thus have not
requested any GSoC contributors.

If your org would like to accept GSoC contributors this year, an Org Admin
must rank proposals before tomorrow, Wednesday April 24 at 1800 UTC.

Org Admins should verify they have Ranked all the proposals their Org
wishes to select for GSoC 2024 before the deadline this Wednesday, April 24
at 18:00 UTC. You must have proposals ranked with at least one assigned
mentor in order for Google Admins to consider your request. If your org
does not rank your requested proposals and assign mentors we will not be
able to grant you any GSoC 2024 contributors.

As of right now (2238 UTC), you have less than 20 hours to complete this
task. Please refer back to the email we sent you on Sunday, April 21st for
further instructions on this task or read that email in the GSoC 2024
Mentor and Org Admin email archive.
Not planning to accept any GSoC Contributors this year?

If your org does not plan to accept any GSoC Contributors for GSoC 2024
that is fine, please send a quick email to gsoc-supp...@google.com saying
as much so we know this was your intention and we won’t email you to ask
what happened.

Please contact us at gsoc-supp...@google.com with any questions.

Best,

Stephanie



Stephanie Taylor  |  Program Manager

Celebrating *20 years* of

*Google Summer of Code* in 2024!

g.co/gsoc  

- End forwarded message -

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

When the tyrant has disposed of foreign enemies by conquest or treaty, and
there is nothing more to fear from them, then he is always stirring up
some war or other, in order that the people may require a leader. -- Plato


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

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

Re: [FFmpeg-devel] [PATCH v2] lavu/opt: Clarify that AVOptions is not indended for general use

[James Almer]

On 4/23/2024 5:53 PM, Michael Niedermayer wrote:

On Tue, Apr 23, 2024 at 05:24:03PM -0300, James Almer wrote:

On 4/23/2024 8:15 AM, Michael Niedermayer wrote:

On Tue, Apr 23, 2024 at 11:10:43AM +0100, Andrew Sayers wrote:

On Tue, Apr 23, 2024 at 12:04:34PM +0200, Anton Khirnov wrote:

Quoting Andrew Sayers (2024-04-23 11:51:00)

On Tue, Apr 23, 2024 at 11:21:27AM +0200, Anton Khirnov wrote:

lavu/opt: Clarify that AVOptions is not indended for general use


They _are_ intended for general use though.


In that case I'm confused...

Let's say I make a desktop app to transcode videos.  Obviously I would use
AVOptions to display configuration options for different encoders.  And it's
possible to create AVOptions objects for my UI.  But how strongly is that use
case recommended?

To provide a particularly difficult example - let's say I want to let the user
choose between interface themes, and I want to show both some text and a
picture of the theme.  AVOption doesn't include a "text + picture" option,
so how would I extend it to meet my needs?


If they fit your use case, then use them, otherwise don't - that's true
for pretty much all APIs we provide.


Ah ok, so how about if I changed "intended" to "optimized" in the subject?


If FFmpeg which is a multimedia tool in no place needs or wants to store
pictures through its option API in a way not curently supported.
I would say thats not going to qualify as "general use" outside specialized
software thats already dealing with a lot of pictures

still you certainly can handle binary data (like a bitmap picture) through
AVOption

thx


Take for example AVIAMFReconGain.recon_gain in libavutil/iamf.h, which is
currently the only field not covered by an AVOption (And thus not currently
configurable from the CLI). How could it be supported? Binary type doesn't
work because it expects a pointer + size field and allocates the former.


i would guess some form of AV_OPT_TYPE_FLAG_ARRAY

we have similar arrays like intra_matrix in mpeg codecs


Same situation it seems, it expects a pointer + size field.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [PATCH] doc: use HOSTEXESUF when calling binary

[James Almer]

On 4/23/2024 6:57 PM, Timo Rothenpieler wrote:

This is neccesary on WSL, and has no averse effects in normal
environments.
---
  doc/Makefile | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/doc/Makefile b/doc/Makefile
index 67586e4b74..98d29f1c66 100644
--- a/doc/Makefile
+++ b/doc/Makefile
@@ -60,7 +60,7 @@ GENTEXI := $(GENTEXI:%=doc/avoptions_%.texi)
  
  $(GENTEXI): TAG = GENTEXI

  $(GENTEXI): doc/avoptions_%.texi: doc/print_options$(HOSTEXESUF)
-   $(M)doc/print_options $* > $@
+   $(M)doc/print_options$(HOSTEXESUF) $* > $@
  
  doc/%.html: TAG = HTML

  doc/%-all.html: TAG = HTML


LGTM. It's even how it's named in the dependency on the line above.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

[FFmpeg-devel] [PATCH 3/5] doc/examples/vaapi_transcode: Simplify loop

[Michael Niedermayer]

Fixes: CID1428858(1/2) Logically dead code

Sponsored-by: Sovereign Tech Fund
Signed-off-by: Michael Niedermayer 
---
 doc/examples/vaapi_transcode.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/doc/examples/vaapi_transcode.c b/doc/examples/vaapi_transcode.c
index 8367cb30404..e1b7a438836 100644
--- a/doc/examples/vaapi_transcode.c
+++ b/doc/examples/vaapi_transcode.c
@@ -215,10 +215,8 @@ static int dec_enc(AVPacket *pkt, const AVCodec *enc_codec)
 
 fail:
 av_frame_free();
-if (ret < 0)
-return ret;
 }
-return 0;
+return ret;
 }
 
 int main(int argc, char **argv)
-- 
2.43.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 2/5] doc/examples/qsv_transcode: Simplify loop

[Michael Niedermayer]

Fixes: CID1428858(2/2) Logically dead code

Sponsored-by: Sovereign Tech Fund
Signed-off-by: Michael Niedermayer 
---
 doc/examples/qsv_transcode.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/doc/examples/qsv_transcode.c b/doc/examples/qsv_transcode.c
index 8e7d2899f12..a4440a3403f 100644
--- a/doc/examples/qsv_transcode.c
+++ b/doc/examples/qsv_transcode.c
@@ -335,10 +335,8 @@ static int dec_enc(AVPacket *pkt, const AVCodec 
*enc_codec, char *optstr)
 
 fail:
 av_frame_free();
-if (ret < 0)
-return ret;
 }
-return 0;
+return ret;
 }
 
 int main(int argc, char **argv)
-- 
2.43.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 5/5] doc/examples/qsv_transcode: Initialize pointer before free

[Michael Niedermayer]

Fixees: CID1517023 Uninitialized pointer read

Sponsored-by: Sovereign Tech Fund
Signed-off-by: Michael Niedermayer 
---
 doc/examples/qsv_transcode.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/doc/examples/qsv_transcode.c b/doc/examples/qsv_transcode.c
index 8e843ddd84c..665a76af2ed 100644
--- a/doc/examples/qsv_transcode.c
+++ b/doc/examples/qsv_transcode.c
@@ -342,7 +342,7 @@ int main(int argc, char **argv)
 {
 const AVCodec *enc_codec;
 int ret = 0;
-AVPacket *dec_pkt;
+AVPacket *dec_pkt = NULL;
 
 if (argc < 5 || (argc - 5) % 2) {
 av_log(NULL, AV_LOG_ERROR, "Usage: %s   "
-- 
2.43.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 4/5] doc/examples/qsv_transcode: Simplify str_to_dict() loop

[Michael Niedermayer]

Fixes: CID1517022 Logically dead code

Sponsored-by: Sovereign Tech Fund
Signed-off-by: Michael Niedermayer 
---
 doc/examples/qsv_transcode.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/doc/examples/qsv_transcode.c b/doc/examples/qsv_transcode.c
index a4440a3403f..8e843ddd84c 100644
--- a/doc/examples/qsv_transcode.c
+++ b/doc/examples/qsv_transcode.c
@@ -76,8 +76,7 @@ static int str_to_dict(char* optstr, AVDictionary **opt)
 if (value == NULL)
 return AVERROR(EINVAL);
 av_dict_set(opt, key, value, 0);
-} while(key != NULL);
-return 0;
+} while(1);
 }
 
 static int dynamic_set_parameter(AVCodecContext *avctx)
-- 
2.43.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 1/5] doc/examples/demux_decode: Simplify loop

[Michael Niedermayer]

Fixes: CID1463550 Logically dead code

Sponsored-by: Sovereign Tech Fund
Signed-off-by: Michael Niedermayer 
---
 doc/examples/demux_decode.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/doc/examples/demux_decode.c b/doc/examples/demux_decode.c
index f26611d8f4f..64f5547bc43 100644
--- a/doc/examples/demux_decode.c
+++ b/doc/examples/demux_decode.c
@@ -138,11 +138,9 @@ static int decode_packet(AVCodecContext *dec, const 
AVPacket *pkt)
 ret = output_audio_frame(frame);
 
 av_frame_unref(frame);
-if (ret < 0)
-return ret;
 }
 
-return 0;
+return ret;
 }
 
 static int open_codec_context(int *stream_idx,
-- 
2.43.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] lavu/opt: Clarify that AVOptions is not indended for general use

[Michael Niedermayer]

On Tue, Apr 23, 2024 at 06:23:04PM -0300, James Almer wrote:
> On 4/23/2024 5:53 PM, Michael Niedermayer wrote:
> > On Tue, Apr 23, 2024 at 05:24:03PM -0300, James Almer wrote:
> > > On 4/23/2024 8:15 AM, Michael Niedermayer wrote:
> > > > On Tue, Apr 23, 2024 at 11:10:43AM +0100, Andrew Sayers wrote:
> > > > > On Tue, Apr 23, 2024 at 12:04:34PM +0200, Anton Khirnov wrote:
> > > > > > Quoting Andrew Sayers (2024-04-23 11:51:00)
> > > > > > > On Tue, Apr 23, 2024 at 11:21:27AM +0200, Anton Khirnov wrote:
> > > > > > > > > lavu/opt: Clarify that AVOptions is not indended for general 
> > > > > > > > > use
> > > > > > > > 
> > > > > > > > They _are_ intended for general use though.
> > > > > > > 
> > > > > > > In that case I'm confused...
> > > > > > > 
> > > > > > > Let's say I make a desktop app to transcode videos.  Obviously I 
> > > > > > > would use
> > > > > > > AVOptions to display configuration options for different 
> > > > > > > encoders.  And it's
> > > > > > > possible to create AVOptions objects for my UI.  But how strongly 
> > > > > > > is that use
> > > > > > > case recommended?
> > > > > > > 
> > > > > > > To provide a particularly difficult example - let's say I want to 
> > > > > > > let the user
> > > > > > > choose between interface themes, and I want to show both some 
> > > > > > > text and a
> > > > > > > picture of the theme.  AVOption doesn't include a "text + 
> > > > > > > picture" option,
> > > > > > > so how would I extend it to meet my needs?
> > > > > > 
> > > > > > If they fit your use case, then use them, otherwise don't - that's 
> > > > > > true
> > > > > > for pretty much all APIs we provide.
> > > > > 
> > > > > Ah ok, so how about if I changed "intended" to "optimized" in the 
> > > > > subject?
> > > > 
> > > > If FFmpeg which is a multimedia tool in no place needs or wants to store
> > > > pictures through its option API in a way not curently supported.
> > > > I would say thats not going to qualify as "general use" outside 
> > > > specialized
> > > > software thats already dealing with a lot of pictures
> > > > 
> > > > still you certainly can handle binary data (like a bitmap picture) 
> > > > through
> > > > AVOption
> > > > 
> > > > thx
> > > 
> > > Take for example AVIAMFReconGain.recon_gain in libavutil/iamf.h, which is
> > > currently the only field not covered by an AVOption (And thus not 
> > > currently
> > > configurable from the CLI). How could it be supported? Binary type doesn't
> > > work because it expects a pointer + size field and allocates the former.
> > 
> > i would guess some form of AV_OPT_TYPE_FLAG_ARRAY
> > 
> > we have similar arrays like intra_matrix in mpeg codecs
> 
> Same situation it seems, it expects a pointer + size field.

So someone needs to add support for a fixed size or
dim size0,size1,sizeDIM

thx

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

It is what and why we do it that matters, not just one of them.


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] Fw: Your GSoC Org has 0 Contributors ranked - deadline is 1800 UTC April 24

[Michael Niedermayer]

Hi

adding people who "want to mentor" to CC

thx

On Wed, Apr 24, 2024 at 01:50:31AM +0200, Michael Niedermayer wrote:
> Hi all
> 
> I just got the mail below. I assume the other admins are going to rank them
> before the deadline like they did last year. (but i can of course not assume
> that because there is no time if that doesnt happen)
> I have not followed GSoC last year or this year much ...
> 
> Either way, if you are a mentor and want your student to receive a slot
> tell me privatly (with thilo and reynaldo in CC) ASAP how you would
> rank your student. And i will rank him/her accordingly if i see noone
> else starting to assign ranks
> 
> thx
> 
> - Forwarded message from Stephanie Taylor  -
> 
> Date: Tue, 23 Apr 2024 15:55:36 -0700
> From: Stephanie Taylor 
> To: undisclosed-recipients: ;
> Subject: Your GSoC Org has 0 Contributors ranked - deadline is 1800 UTC April 
> 24
> 
> Hello GSoC Org Admin,
> 
> 
> You are receiving this email because you are an Org Admin and your org
> currently has 0 (zero) GSoC 2024 proposals ranked and thus have not
> requested any GSoC contributors.
> 
> If your org would like to accept GSoC contributors this year, an Org Admin
> must rank proposals before tomorrow, Wednesday April 24 at 1800 UTC.
> 
> Org Admins should verify they have Ranked all the proposals their Org
> wishes to select for GSoC 2024 before the deadline this Wednesday, April 24
> at 18:00 UTC. You must have proposals ranked with at least one assigned
> mentor in order for Google Admins to consider your request. If your org
> does not rank your requested proposals and assign mentors we will not be
> able to grant you any GSoC 2024 contributors.
> 
> As of right now (2238 UTC), you have less than 20 hours to complete this
> task. Please refer back to the email we sent you on Sunday, April 21st for
> further instructions on this task or read that email in the GSoC 2024
> Mentor and Org Admin email archive.
> Not planning to accept any GSoC Contributors this year?
> 
> If your org does not plan to accept any GSoC Contributors for GSoC 2024
> that is fine, please send a quick email to gsoc-supp...@google.com saying
> as much so we know this was your intention and we won’t email you to ask
> what happened.
> 
> Please contact us at gsoc-supp...@google.com with any questions.
> 
> Best,
> 
> Stephanie
> 
> 
> 
> Stephanie Taylor  |  Program Manager
> 
> Celebrating *20 years* of
> 
> *Google Summer of Code* in 2024!
> 
> g.co/gsoc  
> 
> - End forwarded message -
> 
> -- 
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
> 
> When the tyrant has disposed of foreign enemies by conquest or treaty, and
> there is nothing more to fear from them, then he is always stirring up
> some war or other, in order that the people may require a leader. -- Plato



> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".


-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

If you fake or manipulate statistics in a paper in physics you will never
get a job again.
If you fake or manipulate statistics in a paper in medicin you will get
a job for life at the pharma industry.


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

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

Re: [FFmpeg-devel] [PATCH 3/3] avfilter/signature_lookup: Dont copy uninitialized stuff around

[Michael Niedermayer]

On Mon, Apr 22, 2024 at 01:07:01AM +0200, Michael Niedermayer wrote:
> Fixes: CID1403238 Uninitialized pointer read
> Fixes: CID1403239 Uninitialized pointer read
> 
> Sponsored-by: Sovereign Tech Fund
> Signed-off-by: Michael Niedermayer 
> ---
>  libavfilter/signature_lookup.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)

will apply

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

While the State exists there can be no freedom; when there is freedom there
will be no State. -- Vladimir Lenin


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

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

Re: [FFmpeg-devel] [PATCH 1/3] avfilter/signature_lookup: Fix 2 differences to the refernce SW

[Michael Niedermayer]

On Mon, Apr 22, 2024 at 01:06:59AM +0200, Michael Niedermayer wrote:
> Fixes: CID1403227 Division or modulo by float zero
> 
> Sponsored-by: Sovereign Tech Fund
> Signed-off-by: Michael Niedermayer 
> ---
>  libavfilter/signature_lookup.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)

will apply

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

"You are 36 times more likely to die in a bathtub than at the hands of a
terrorist. Also, you are 2.5 times more likely to become a president and
2 times more likely to become an astronaut, than to die in a terrorist
attack." -- Thoughty2



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

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

Re: [FFmpeg-devel] Request for Official GitHub Mirror of rtmpdump for Enhanced Security

[Michael Niedermayer]

Hi


On Tue, Apr 23, 2024 at 07:04:08PM +, Javier Matos Denizac via ffmpeg-devel 
wrote:
> Dear FFmpeg team,
> 
> 
> My name is Javier Matos, and I am part of the vcpkg team at Microsoft. vcpkg 
> is an open-source package manager designed to help developers manage C++ 
> libraries across platforms in a consistent manner.
> 
> I am reaching out to inquire if FFmpeg could host an official GitHub mirror 
> for the `rtmpdump` repository on `github.com/FFmpeg`.
> 
> Currently, vcpkg uses a mirrored version from `github.com/mirror/rtmpdump`, 
> which is not maintained by the original authors, posing a significant supply 
> chain risk due to potential unauthorized modifications.
> 

> Alternatively, while we could switch to using the repository at 
> `git://git.ffmpeg.org/rtmpdump.git`, this source lacks support for SHA512 
> checksums, complicating asset caching and security verification crucial for 
> ensuring the integrity of the code during downloads.

Can you elaborate what the problem is ?
I would have thought https://git.ffmpeg.org/rtmpdump.git
is secure

thx

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

In a rich man's house there is no place to spit but his face.
-- Diogenes of Sinope


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

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

[FFmpeg-devel] [PATCH] doc: use HOSTEXESUF when calling binary

[Timo Rothenpieler]

This is neccesary on WSL, and has no averse effects in normal
environments.
---
 doc/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/doc/Makefile b/doc/Makefile
index 67586e4b74..98d29f1c66 100644
--- a/doc/Makefile
+++ b/doc/Makefile
@@ -60,7 +60,7 @@ GENTEXI := $(GENTEXI:%=doc/avoptions_%.texi)
 
 $(GENTEXI): TAG = GENTEXI
 $(GENTEXI): doc/avoptions_%.texi: doc/print_options$(HOSTEXESUF)
-   $(M)doc/print_options $* > $@
+   $(M)doc/print_options$(HOSTEXESUF) $* > $@
 
 doc/%.html: TAG = HTML
 doc/%-all.html: TAG = HTML
-- 
2.43.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] libavutil/hwcontext_qsv: Make qsv hardware transfers thread safe

[Xiang, Haihao]

On Wo, 2024-04-17 at 09:46 -0500, Mark Samuelson wrote:
> The QSV hardware context currently uses pthreads to lock initilization,
> which is not available on windows builds.  Instead, use the AVMutex
> object.  Also lock uses of the realigned_upload_frame and
> realigned_download_frame objects, so multiple threads do not attempt
> to write to them at the same time.
> ---
>  
> Here is a new patch addressing your comments
> Fixed the nested calls to ff_mutex_lock
> Fixed the two accidental tabs
> Fixed the two violations of K style
> Fixed the two incidents of mixing declaration and code
> 
> 
>  libavutil/hwcontext_qsv.c | 93 +++
>  1 file changed, 56 insertions(+), 37 deletions(-)
> 
> diff --git a/libavutil/hwcontext_qsv.c b/libavutil/hwcontext_qsv.c
> index c7c7878644..ed462d440a 100644
> --- a/libavutil/hwcontext_qsv.c
> +++ b/libavutil/hwcontext_qsv.c
> @@ -23,10 +23,7 @@
>  #include 
>  
>  #include "config.h"
> -
> -#if HAVE_PTHREADS
> -#include 
> -#endif
> +#include "thread.h"
>  
>  #define COBJMACROS
>  #if CONFIG_VAAPI
> @@ -98,9 +95,7 @@ typedef struct QSVFramesContext {
>  atomic_int session_download_init;
>  mfxSession session_upload;
>  atomic_int session_upload_init;
> -#if HAVE_PTHREADS
> -    pthread_mutex_t session_lock;
> -#endif
> +    AVMutex session_lock;
>  
>  AVBufferRef *child_frames_ref;
>  mfxFrameSurface1 *surfaces_internal;
> @@ -354,9 +349,7 @@ static void qsv_frames_uninit(AVHWFramesContext *ctx)
>  s->session_upload = NULL;
>  s->session_upload_init = 0;
>  
> -#if HAVE_PTHREADS
> -    pthread_mutex_destroy(>session_lock);
> -#endif
> +    ff_mutex_destroy(>session_lock);
>  
>  av_freep(>mem_ids);
>  #if QSV_HAVE_OPAQUE
> @@ -1302,9 +1295,7 @@ static int qsv_frames_init(AVHWFramesContext *ctx)
>  s->session_download_init = 0;
>  s->session_upload_init   = 0;
>  
> -#if HAVE_PTHREADS
> -    pthread_mutex_init(>session_lock, NULL);
> -#endif
> +    ff_mutex_init(>session_lock, NULL);
>  
>  return 0;
>  }
> @@ -1629,24 +1620,20 @@ static int
> qsv_internal_session_check_init(AVHWFramesContext *ctx, int upload)
>  if (atomic_load(inited))
>  return 0;
>  
> -#if HAVE_PTHREADS
> -    pthread_mutex_lock(>session_lock);
> -#endif
> +    ff_mutex_lock(>session_lock);
>  
>  if (!atomic_load(inited)) {
>  ret = qsv_init_internal_session(ctx, session, upload);
>  atomic_store(inited, 1);
>  }
>  
> -#if HAVE_PTHREADS
> -    pthread_mutex_unlock(>session_lock);
> -#endif
> +    ff_mutex_unlock(>session_lock);
>  
>  return ret;
>  }
>  
> -static int qsv_transfer_data_from(AVHWFramesContext *ctx, AVFrame *dst,
> -  const AVFrame *src)
> +static int qsv_transfer_data_from_internal(AVHWFramesContext *ctx, AVFrame
> *dst,
> +   const AVFrame *src, int realigned)
>  {
>  QSVFramesContext  *s = ctx->hwctx;
>  mfxFrameSurface1 out = {{ 0 }};
> @@ -1658,17 +1645,11 @@ static int qsv_transfer_data_from(AVHWFramesContext
> *ctx, AVFrame *dst,
>  /* download to temp frame if the output is not padded as libmfx requires
> */
>  AVFrame *tmp_frame = >realigned_download_frame;
>  AVFrame *dst_frame;
> -    int realigned = 0;
> -
> -    ret = qsv_internal_session_check_init(ctx, 0);
> -    if (ret < 0)
> -    return ret;
>  
>  /* According to MSDK spec for mfxframeinfo, "Width must be a multiple of
> 16.
>   * Height must be a multiple of 16 for progressive frame sequence and a
>   * multiple of 32 otherwise.", so allign all frames to 16 before
> downloading. */
> -    if (dst->height & 15 || dst->linesize[0] & 15) {
> -    realigned = 1;
> +    if (realigned) {
>  if (tmp_frame->format != dst->format ||
>  tmp_frame->width  != FFALIGN(dst->linesize[0], 16) ||
>  tmp_frame->height != FFALIGN(dst->height, 16)) {
> @@ -1728,8 +1709,30 @@ static int qsv_transfer_data_from(AVHWFramesContext
> *ctx, AVFrame *dst,
>  return 0;
>  }
>  
> -static int qsv_transfer_data_to(AVHWFramesContext *ctx, AVFrame *dst,
> -    const AVFrame *src)
> +static int qsv_transfer_data_from(AVHWFramesContext *ctx, AVFrame *dst,
> +  const AVFrame *src)
> +{
> +    QSVFramesContext *s = ctx->hwctx;
> +    int realigned = 0;
> +    int ret = 0;
> +
> +    ret = qsv_internal_session_check_init(ctx, 0);
> +    if (ret < 0)
> +    return ret;
> +
> +    if (dst->height & 15 || dst->linesize[0] & 15) {
> +    realigned = 1;
> +    ff_mutex_lock(>session_lock);

Needn't lock the use if changing realigned_upload_frame and
realigned_download_frame to local variables.

Thanks
Haihao

> +    }
> +    ret = qsv_transfer_data_from_internal(ctx, dst, src, realigned);
> +    if (realigned)
> +    ff_mutex_unlock(>session_lock);
> +
> +    return ret;
> +}
> +
> +static int 

Re: [FFmpeg-devel] [PATCH 4/5] doc/examples/qsv_transcode: Simplify str_to_dict() loop

[Xiang, Haihao]

On Wo, 2024-04-24 at 03:45 +0200, Michael Niedermayer wrote:
> Fixes: CID1517022 Logically dead code
> 
> Sponsored-by: Sovereign Tech Fund
> Signed-off-by: Michael Niedermayer 
> ---
>  doc/examples/qsv_transcode.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/doc/examples/qsv_transcode.c b/doc/examples/qsv_transcode.c
> index a4440a3403f..8e843ddd84c 100644
> --- a/doc/examples/qsv_transcode.c
> +++ b/doc/examples/qsv_transcode.c
> @@ -76,8 +76,7 @@ static int str_to_dict(char* optstr, AVDictionary **opt)
>  if (value == NULL)
>  return AVERROR(EINVAL);
>  av_dict_set(opt, key, value, 0);
> -    } while(key != NULL);
> -    return 0;
> +    } while(1);
>  }
>  
>  static int dynamic_set_parameter(AVCodecContext *avctx)

LGTM, thanks for catching & fixing this.

- Haihao


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

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

Re: [FFmpeg-devel] [PATCH 5/5] doc/examples/qsv_transcode: Initialize pointer before free

[Xiang, Haihao]

On Wo, 2024-04-24 at 03:45 +0200, Michael Niedermayer wrote:
> Fixees: CID1517023 Uninitialized pointer read
> 
> Sponsored-by: Sovereign Tech Fund
> Signed-off-by: Michael Niedermayer 
> ---
>  doc/examples/qsv_transcode.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/doc/examples/qsv_transcode.c b/doc/examples/qsv_transcode.c
> index 8e843ddd84c..665a76af2ed 100644
> --- a/doc/examples/qsv_transcode.c
> +++ b/doc/examples/qsv_transcode.c
> @@ -342,7 +342,7 @@ int main(int argc, char **argv)
>  {
>  const AVCodec *enc_codec;
>  int ret = 0;
> -    AVPacket *dec_pkt;
> +    AVPacket *dec_pkt = NULL;
>  
>  if (argc < 5 || (argc - 5) % 2) {
>  av_log(NULL, AV_LOG_ERROR, "Usage: %sfile>"

LGTM,

- Haihao

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

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

Re: [FFmpeg-devel] [PATCH 2/5] doc/examples/qsv_transcode: Simplify loop

[Xiang, Haihao]

On Wo, 2024-04-24 at 03:45 +0200, Michael Niedermayer wrote:
> Fixes: CID1428858(2/2) Logically dead code
> 
> Sponsored-by: Sovereign Tech Fund
> Signed-off-by: Michael Niedermayer 
> ---
>  doc/examples/qsv_transcode.c | 4 +---
>  1 file changed, 1 insertion(+), 3 deletions(-)
> 
> diff --git a/doc/examples/qsv_transcode.c b/doc/examples/qsv_transcode.c
> index 8e7d2899f12..a4440a3403f 100644
> --- a/doc/examples/qsv_transcode.c
> +++ b/doc/examples/qsv_transcode.c
> @@ -335,10 +335,8 @@ static int dec_enc(AVPacket *pkt, const AVCodec
> *enc_codec, char *optstr)
>  
>  fail:
>  av_frame_free();
> -    if (ret < 0)
> -    return ret;
>  }
> -    return 0;
> +    return ret;
>  }
>  
>  int main(int argc, char **argv)

LGTM

Thanks
Haihao





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

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

Re: [FFmpeg-devel] [PATCH] lavc/vp9: Fix regression introduced in 0ba05857

[Xiang, Haihao]

On Di, 2024-04-23 at 14:14 +0200, Andreas Rheinhardt wrote:
> Xiang, Haihao:
> > From: Haihao Xiang 
> > 
> > It is possible that ff_progress_frame_await() is called but
> > ff_progress_frame_report() isn't called when a hardware acceleration
> > method is used, so a thread for vp9 decoding might get stuck.
> > 
> > Signed-off-by: Haihao Xiang 
> > ---
> >  libavcodec/vp9.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/libavcodec/vp9.c b/libavcodec/vp9.c
> > index 3adfb98f2d..6e2d18bf95 100644
> > --- a/libavcodec/vp9.c
> > +++ b/libavcodec/vp9.c
> > @@ -1735,9 +1735,9 @@ static int vp9_decode_frame(AVCodecContext *avctx,
> > AVFrame *frame,
> >  if (ret < 0)
> >  goto fail;
> >  }
> > -    ff_progress_frame_report(>s.frames[CUR_FRAME].tf, INT_MAX);
> >  
> >  finish:
> > +    ff_progress_frame_report(>s.frames[CUR_FRAME].tf, INT_MAX);
> >  // ref frame setup
> >  for (int i = 0; i < 8; i++)
> >  ff_progress_frame_replace(>s.refs[i], >next_refs[i]);
> 
> LGTM. Sorry for the breakage.
> 

Thanks for reviewing the patch, I pushed the patch.

BRs
Haihao

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

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

Re: [FFmpeg-devel] [PATCH v1] lavc/qsvdec: Use FFmpeg default 1/25 framerate if can't derive it from bitstream

[Xiang, Haihao]

On Do, 2024-04-18 at 16:15 +0800, fei.w.wang-at-intel@ffmpeg.org wrote:
> From: Fei Wang 
> 
> Fix error:
> $ ffmpeg -hwaccel qsv -i input.h265 -f null -
> ...
> [null @ 0x55da1a629200] Application provided invalid, non monotonically
> increasing dts to muxer in stream 0: 3 >= 3
> 
> Signed-off-by: Fei Wang 
> ---
>  libavcodec/qsvdec.c | 5 +
>  1 file changed, 5 insertions(+)
> 
> diff --git a/libavcodec/qsvdec.c b/libavcodec/qsvdec.c
> index fd9267c6f4..218ca59e08 100644
> --- a/libavcodec/qsvdec.c
> +++ b/libavcodec/qsvdec.c
> @@ -440,6 +440,11 @@ static int qsv_decode_header(AVCodecContext *avctx,
> QSVContext *q,
>  param->ExtParam    = q->ext_buffers;
>  param->NumExtParam = q->nb_ext_buffers;
>  
> +    if (param->mfx.FrameInfo.FrameRateExtN == 0 || param-
> >mfx.FrameInfo.FrameRateExtD == 0) {
> +    param->mfx.FrameInfo.FrameRateExtN = 25;
> +    param->mfx.FrameInfo.FrameRateExtD = 1;
> +    }
> +
>  #if QSV_VERSION_ATLEAST(1, 34)
>  if (QSV_RUNTIME_VERSION_ATLEAST(q->ver, 1, 34) && avctx->codec_id ==
> AV_CODEC_ID_AV1)
>  param->mfx.FilmGrain = (avctx->export_side_data &
> AV_CODEC_EXPORT_DATA_FILM_GRAIN) ? 0 : param->mfx.FilmGrain;

LGTM, will apply

Thanks
Haihao




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

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

Re: [FFmpeg-devel] Fw: Your GSoC Org has 0 Contributors ranked - deadline is 1800 UTC April 24

[Thilo Borgmann via ffmpeg-devel]

Hi,


adding people who "want to mentor" to CC

thx

On Wed, Apr 24, 2024 at 01:50:31AM +0200, Michael Niedermayer wrote:

Hi all

I just got the mail below. I assume the other admins are going to rank them
before the deadline like they did last year. (but i can of course not assume
that because there is no time if that doesnt happen)
I have not followed GSoC last year or this year much ...

Either way, if you are a mentor and want your student to receive a slot
tell me privatly (with thilo and reynaldo in CC) ASAP how you would
rank your student. And i will rank him/her accordingly if i see noone
else starting to assign ranks


sorry for delay, just got home after NAB.
All proposals now ranked, all admins/mentors should be able to see that on the 
dashboard.

-Thilo




- Forwarded message from Stephanie Taylor  -

Date: Tue, 23 Apr 2024 15:55:36 -0700
From: Stephanie Taylor 
To: undisclosed-recipients: ;
Subject: Your GSoC Org has 0 Contributors ranked - deadline is 1800 UTC April 24

Hello GSoC Org Admin,


You are receiving this email because you are an Org Admin and your org
currently has 0 (zero) GSoC 2024 proposals ranked and thus have not
requested any GSoC contributors.

If your org would like to accept GSoC contributors this year, an Org Admin
must rank proposals before tomorrow, Wednesday April 24 at 1800 UTC.

Org Admins should verify they have Ranked all the proposals their Org
wishes to select for GSoC 2024 before the deadline this Wednesday, April 24
at 18:00 UTC. You must have proposals ranked with at least one assigned
mentor in order for Google Admins to consider your request. If your org
does not rank your requested proposals and assign mentors we will not be
able to grant you any GSoC 2024 contributors.

As of right now (2238 UTC), you have less than 20 hours to complete this
task. Please refer back to the email we sent you on Sunday, April 21st for
further instructions on this task or read that email in the GSoC 2024
Mentor and Org Admin email archive.
Not planning to accept any GSoC Contributors this year?

If your org does not plan to accept any GSoC Contributors for GSoC 2024
that is fine, please send a quick email to gsoc-supp...@google.com saying
as much so we know this was your intention and we won’t email you to ask
what happened.

Please contact us at gsoc-supp...@google.com with any questions.

Best,

Stephanie



Stephanie Taylor  |  Program Manager

Celebrating *20 years* of

*Google Summer of Code* in 2024!

g.co/gsoc  

- End forwarded message -

--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

When the tyrant has disposed of foreign enemies by conquest or treaty, and
there is nothing more to fear from them, then he is always stirring up
some war or other, in order that the people may require a leader. -- Plato





___
ffmpeg-devel mailing list
ffmpeg-devel@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] [RFC] 5 year plan & Inovation

[Rémi Denis-Courmont]

Le 21 avril 2024 23:40:08 GMT+03:00, Michael Niedermayer 
 a écrit :
>On Sun, Apr 21, 2024 at 05:11:36PM +0800, Rémi Denis-Courmont wrote:
>> 
>> 
>> Le 17 avril 2024 21:58:32 GMT+08:00, Michael Niedermayer 
>>  a écrit :
>> >Hi all
>> >
>> >The pace of inovation in FFmpeg has been slowing down.
>> >Most work is concentarted nowadays on code refactoring, and adding
>> >support for new codecs and formats.
>> 
>> OSS projects of age similar to FFmpeg are either mature (like FFmpeg), or 
>> more or less dead. Besides, FFmpeg is an established brand, which means that 
>> it's expected to be good at what it's been doing... and not expected to be 
>> good at anything else.
>> 
>> Of course there are also specific aspects: back then, every company made up 
>> its own codecs. Nowadays, there's at most three tracks (for video): H.26x, 
>> Chinese AVSx and AV-x, while AVC or HEVC have become "good enough" for most 
>> applications.
>> 
>> If (generic) you want to work on radical innovation, I think you will be 
>> better served by creating a new project. Both the FFmpeg project structure 
>> and brand would probably do you a disservice otherwise.
>
>I will disagree on this a bit
>
>If we for a moment look at the commerical world (but its not fundamentally 
>different in OSS)
>
>Projects/Companies are created to fill some need, initially they
>often need to concentarte on a narrow market because they dont have the
>resources to do "everything" and if they try they go bankrupt.
>Once they are established and have the resources they grow or they die
>
>Microsoft started with a OS in 1985, added an office suite in 1990
>internet explorer in 1995, xbox in 2001, Microsoft Azure in 2008
>and you can fill in more.
>Today Microsoft is one of the largest companies in teh world.

Microsoft expanded into new fields with Xbox and Azure, yes. But Windows is 
still an OS, and Office is still a (un)productivity suite.

Accordingly, maybe you can innovate with a new project within the same legal 
entity as FFmpeg (be it SPI, FFlabs or whatever).

But FFmpeg as a software project is not a suitable venue for radical new 
innovation.

>You can do the same with apple, google, or others.

Sure but you can't do the same with iPhone or Google Search.
___
ffmpeg-devel mailing list
ffmpeg-devel@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] lavc/vp9: Fix regression introduced in 0ba05857

[Andreas Rheinhardt]

Xiang, Haihao:
> From: Haihao Xiang 
> 
> It is possible that ff_progress_frame_await() is called but
> ff_progress_frame_report() isn't called when a hardware acceleration
> method is used, so a thread for vp9 decoding might get stuck.
> 
> Signed-off-by: Haihao Xiang 
> ---
>  libavcodec/vp9.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/libavcodec/vp9.c b/libavcodec/vp9.c
> index 3adfb98f2d..6e2d18bf95 100644
> --- a/libavcodec/vp9.c
> +++ b/libavcodec/vp9.c
> @@ -1735,9 +1735,9 @@ static int vp9_decode_frame(AVCodecContext *avctx, 
> AVFrame *frame,
>  if (ret < 0)
>  goto fail;
>  }
> -ff_progress_frame_report(>s.frames[CUR_FRAME].tf, INT_MAX);
>  
>  finish:
> +ff_progress_frame_report(>s.frames[CUR_FRAME].tf, INT_MAX);
>  // ref frame setup
>  for (int i = 0; i < 8; i++)
>  ff_progress_frame_replace(>s.refs[i], >next_refs[i]);

LGTM. Sorry for the breakage.

- Andreas

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

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

[FFmpeg-devel] [PATCH] avfilter/f_sidedata: synchronize with side data list

[Niklas Haas]

From: Niklas Haas 

Add all recently added frame data types, as well as the new name for
DETECTION_BBOXES as an alias to the older DETECTION_BOUNDING_BOXES.
---
 libavfilter/f_sidedata.c | 10 +-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/libavfilter/f_sidedata.c b/libavfilter/f_sidedata.c
index fe9607ed52..616fd0750c 100644
--- a/libavfilter/f_sidedata.c
+++ b/libavfilter/f_sidedata.c
@@ -71,8 +71,16 @@ static const AVOption filt_name##_options[] = { \
 {   "S12M_TIMECOD",   "", 0, AV_OPT_TYPE_CONST,  
{.i64 = AV_FRAME_DATA_S12M_TIMECODE  }, 0, 0, FLAGS, .unit = "type" 
}, \
 {   "DYNAMIC_HDR_PLUS",   "", 0, AV_OPT_TYPE_CONST,  
{.i64 = AV_FRAME_DATA_DYNAMIC_HDR_PLUS   }, 0, 0, FLAGS, .unit = "type" 
}, \
 {   "REGIONS_OF_INTEREST","", 0, AV_OPT_TYPE_CONST,  
{.i64 = AV_FRAME_DATA_REGIONS_OF_INTEREST}, 0, 0, FLAGS, .unit = "type" 
}, \
-{   "DETECTION_BOUNDING_BOXES",   "", 0, AV_OPT_TYPE_CONST,  
{.i64 = AV_FRAME_DATA_DETECTION_BBOXES   }, 0, 0, FLAGS, .unit = "type" 
}, \
+{   "VIDEO_ENC_PARAMS",   "", 0, AV_OPT_TYPE_CONST,  
{.i64 = AV_FRAME_DATA_VIDEO_ENC_PARAMS   }, 0, 0, FLAGS, .unit = "type" 
}, \
 {   "SEI_UNREGISTERED",   "", 0, AV_OPT_TYPE_CONST,  
{.i64 = AV_FRAME_DATA_SEI_UNREGISTERED   }, 0, 0, FLAGS, .unit = "type" 
}, \
+{   "FILM_GRAIN_PARAMS",  "", 0, AV_OPT_TYPE_CONST,  
{.i64 = AV_FRAME_DATA_FILM_GRAIN_PARAMS  }, 0, 0, FLAGS, .unit = "type" 
}, \
+{   "DETECTION_BOUNDING_BOXES",   "", 0, AV_OPT_TYPE_CONST,  
{.i64 = AV_FRAME_DATA_DETECTION_BBOXES   }, 0, 0, FLAGS, .unit = "type" 
}, \
+{   "DETECTION_BBOXES",   "", 0, AV_OPT_TYPE_CONST,  
{.i64 = AV_FRAME_DATA_DETECTION_BBOXES   }, 0, 0, FLAGS, .unit = "type" 
}, \
+{   "DOVI_RPU_BUFFER","", 0, AV_OPT_TYPE_CONST,  
{.i64 = AV_FRAME_DATA_DOVI_RPU_BUFFER}, 0, 0, FLAGS, .unit = "type" 
}, \
+{   "DOVI_METADATA",  "", 0, AV_OPT_TYPE_CONST,  
{.i64 = AV_FRAME_DATA_DOVI_METADATA  }, 0, 0, FLAGS, .unit = "type" 
}, \
+{   "DYNAMIC_HDR_VIVID",  "", 0, AV_OPT_TYPE_CONST,  
{.i64 = AV_FRAME_DATA_DYNAMIC_HDR_VIVID  }, 0, 0, FLAGS, .unit = "type" 
}, \
+{   "AMBIENT_VIEWING_ENVIRONMENT","", 0, AV_OPT_TYPE_CONST,  
{.i64 = AV_FRAME_DATA_AMBIENT_VIEWING_ENVIRONMENT}, 0, 0, FLAGS, .unit = "type" 
}, \
+{   "VIDEO_HINT", "", 0, AV_OPT_TYPE_CONST,  
{.i64 = AV_FRAME_DATA_VIDEO_HINT }, 0, 0, FLAGS, .unit = "type" 
}, \
 { NULL } \
 }
 
-- 
2.44.0

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

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

Re: [FFmpeg-devel] [RFC] 5 year plan & Inovation

[Andrew Sayers]

On Tue, Apr 23, 2024 at 02:20:51AM +0200, Michael Niedermayer wrote:
> On Thu, Apr 18, 2024 at 10:46:35AM +0200, Stefano Sabatini wrote:
> > On date Wednesday 2024-04-17 15:58:32 +0200, Michael Niedermayer wrote:
> > > Hi all
> > > 
> > > The pace of inovation in FFmpeg has been slowing down.
> > > Most work is concentarted nowadays on code refactoring, and adding
> > > support for new codecs and formats.
> > > 
> > > Should we
> > > * make a list of longer term goals
> > > * vote on them
> > > * and then together work towards implementing them
> > > ?
> > > 
> > > (The idea here is to increase the success of larger efforts
> > >  than adding codecs and refactoring code)
> > > It would then also not be possible for individuals to object
> > > to a previously agreed goal.
> > > And it would add ideas for which we can try to get funding/grants for
> > > 
> > > (larger scale changes need consensus first that we as a whole want
> > >  them before we would be able to ask for funding/grants for them)
> > > 
> > > Some ideas and why they would help FFmpeg:
> > > 
> > [...]
> > > * client side / in browser support
> > > (expand towards webapps, webpages using ffmpeg client side in the 
> > > browser)
> > > bring in more users and developers, and it will be costly for us
> > > if we let others take this area as its important and significant
> > 
> > There are already several projects on github, the most prominent one:
> > https://github.com/ffmpegwasm/ffmpeg.wasm/
> > 
> > In general it would be useful to provide libav* bindings to other
> > languages, for example:
> > https://github.com/PyAV-Org/PyAV
> > https://github.com/zmwangx/rust-ffmpeg
> > 
> > Not sure these should be really moved to FFmpeg though.
> 
> From a user PoV it would be nice if there was a official
> python, rust and wasm binding
> 
> It also would draw in more developers and users to FFmpeg.
> test coverage might also improve
> 
> I think the 2 questions are.
>  1. is there a binding for some language that wants to become the official
> FFmpeg binding for that language ?
>  2. does the FFmpeg community want that too ?
> 
> thx

I've thought about this a lot while trying to learn FFmpeg.
IMHO there are two big hurdles to good other-language bindings:

First, FFmpeg's interface is full of C idioms that are unintuitive to
programmers from other languages.  For example, Stefano Sabatini is
patiently explaining to me in anoher thread how contexts are a central
concept in FFmpeg's design.  Even where I understood the code on a
mechanical level, I had drastically underestimated their importance
because I didn't have a mental model to understand them.  Binding
FFmpeg functionality in another language is only half the problem -
the interface needs to be explained in terms they can understand,
or rewritten in terms they already know.

Second, the interface is full of special cases that make translation
to other languages burdensome.  For example, C errors are based on
returning a value and requiring the caller to check it explicitly;
whereas most other languages throw an error and allow the caller to
catch it or not.  A translator needs to convert every one of those,
but FFmpeg functions don't have a standard mechanism to signal the
correct behaviour for a given function.  Even the documentation isn't
reliably helpful, sometimes saying a variant of "returns an AVERROR",
sometimes "returns a negative number", and sometimes it just
returns an int and expects the reader to dig through the source.
That eats up a huge amount of programmer time, and has to be done for
every language that wants a binding.

Solving those problems would make it far more practical for translators
to make bindings in other languages, and for new people to learn FFmpeg
even in C.  For example, creating an `enum AVERROR` and rewriting
functions to return it would make the code easier to read and drastically
cut translator time.

- Andrew Sayers
___
ffmpeg-devel mailing list
ffmpeg-devel@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] lavu/opt: Clarify that AVOptions is not indended for general use

[Michael Niedermayer]

On Tue, Apr 23, 2024 at 11:10:43AM +0100, Andrew Sayers wrote:
> On Tue, Apr 23, 2024 at 12:04:34PM +0200, Anton Khirnov wrote:
> > Quoting Andrew Sayers (2024-04-23 11:51:00)
> > > On Tue, Apr 23, 2024 at 11:21:27AM +0200, Anton Khirnov wrote:
> > > > > lavu/opt: Clarify that AVOptions is not indended for general use
> > > > 
> > > > They _are_ intended for general use though.
> > > 
> > > In that case I'm confused...
> > > 
> > > Let's say I make a desktop app to transcode videos.  Obviously I would use
> > > AVOptions to display configuration options for different encoders.  And 
> > > it's
> > > possible to create AVOptions objects for my UI.  But how strongly is that 
> > > use
> > > case recommended?
> > > 
> > > To provide a particularly difficult example - let's say I want to let the 
> > > user
> > > choose between interface themes, and I want to show both some text and a
> > > picture of the theme.  AVOption doesn't include a "text + picture" option,
> > > so how would I extend it to meet my needs?
> > 
> > If they fit your use case, then use them, otherwise don't - that's true
> > for pretty much all APIs we provide.
> 
> Ah ok, so how about if I changed "intended" to "optimized" in the subject?

If FFmpeg which is a multimedia tool in no place needs or wants to store
pictures through its option API in a way not curently supported.
I would say thats not going to qualify as "general use" outside specialized
software thats already dealing with a lot of pictures

still you certainly can handle binary data (like a bitmap picture) through
AVOption

thx

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

Those who are too smart to engage in politics are punished by being
governed by those who are dumber. -- Plato 


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

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

Re: [FFmpeg-devel] [PATCH v2] lavu/opt: Clarify that AVOptions is not indended for general use

[Michael Niedermayer]

On Tue, Apr 23, 2024 at 01:15:52PM +0200, Michael Niedermayer wrote:
> On Tue, Apr 23, 2024 at 11:10:43AM +0100, Andrew Sayers wrote:
> > On Tue, Apr 23, 2024 at 12:04:34PM +0200, Anton Khirnov wrote:
> > > Quoting Andrew Sayers (2024-04-23 11:51:00)
> > > > On Tue, Apr 23, 2024 at 11:21:27AM +0200, Anton Khirnov wrote:
> > > > > > lavu/opt: Clarify that AVOptions is not indended for general use
> > > > > 
> > > > > They _are_ intended for general use though.
> > > > 
> > > > In that case I'm confused...
> > > > 
> > > > Let's say I make a desktop app to transcode videos.  Obviously I would 
> > > > use
> > > > AVOptions to display configuration options for different encoders.  And 
> > > > it's
> > > > possible to create AVOptions objects for my UI.  But how strongly is 
> > > > that use
> > > > case recommended?
> > > > 
> > > > To provide a particularly difficult example - let's say I want to let 
> > > > the user
> > > > choose between interface themes, and I want to show both some text and a
> > > > picture of the theme.  AVOption doesn't include a "text + picture" 
> > > > option,
> > > > so how would I extend it to meet my needs?
> > > 
> > > If they fit your use case, then use them, otherwise don't - that's true
> > > for pretty much all APIs we provide.
> > 
> > Ah ok, so how about if I changed "intended" to "optimized" in the subject?
> 
> If FFmpeg which is a multimedia tool in no place needs or wants to store
> pictures through its option API in a way not curently supported.
> I would say thats not going to qualify as "general use" outside specialized
> software thats already dealing with a lot of pictures
> 
> still you certainly can handle binary data (like a bitmap picture) through
> AVOption

And if you disagree, which you probably do :)
send a patch to improve AVOption to cover more general use

thx

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

He who knows, does not speak. He who speaks, does not know. -- Lao Tsu


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] lavu/opt: Clarify that AVOptions is not indended for general use

[Andrew Sayers]

On Tue, Apr 23, 2024 at 01:18:28PM +0200, Michael Niedermayer wrote:
> On Tue, Apr 23, 2024 at 01:15:52PM +0200, Michael Niedermayer wrote:
> > On Tue, Apr 23, 2024 at 11:10:43AM +0100, Andrew Sayers wrote:
> > > On Tue, Apr 23, 2024 at 12:04:34PM +0200, Anton Khirnov wrote:
> > > > Quoting Andrew Sayers (2024-04-23 11:51:00)
> > > > > On Tue, Apr 23, 2024 at 11:21:27AM +0200, Anton Khirnov wrote:
> > > > > > > lavu/opt: Clarify that AVOptions is not indended for general use
> > > > > > 
> > > > > > They _are_ intended for general use though.
> > > > > 
> > > > > In that case I'm confused...
> > > > > 
> > > > > Let's say I make a desktop app to transcode videos.  Obviously I 
> > > > > would use
> > > > > AVOptions to display configuration options for different encoders.  
> > > > > And it's
> > > > > possible to create AVOptions objects for my UI.  But how strongly is 
> > > > > that use
> > > > > case recommended?
> > > > > 
> > > > > To provide a particularly difficult example - let's say I want to let 
> > > > > the user
> > > > > choose between interface themes, and I want to show both some text 
> > > > > and a
> > > > > picture of the theme.  AVOption doesn't include a "text + picture" 
> > > > > option,
> > > > > so how would I extend it to meet my needs?
> > > > 
> > > > If they fit your use case, then use them, otherwise don't - that's true
> > > > for pretty much all APIs we provide.
> > > 
> > > Ah ok, so how about if I changed "intended" to "optimized" in the subject?
> > 
> > If FFmpeg which is a multimedia tool in no place needs or wants to store
> > pictures through its option API in a way not curently supported.
> > I would say thats not going to qualify as "general use" outside specialized
> > software thats already dealing with a lot of pictures
> > 
> > still you certainly can handle binary data (like a bitmap picture) through
> > AVOption
> 
> And if you disagree, which you probably do :)
> send a patch to improve AVOption to cover more general use

Not sure if that's aimed at the real me, or the hypothetical me that wants to
make a desktop app.  The hypothetical me wants not to throw away a week's work
because he did everything through AVOptions then came across some edge case
that doesn't fit into the AVOptions model.  The real me doesn't want to throw
away a week's work because I avoided AVOptions then found some bit of interface
that needs me to express my program in an AVOptions-compatible way.  Neither of
us mind what the answer is, so long as it's written down somewhere we would
spot during the design stage.

It sounds like the consensus is that people are *allowed* to implement their
own AVOption interfaces if they want to, but that there's no expectation for
them to do so unless they're working on FFmpeg itself.  That suggests the body
of the patch is fine, but the subject needs improvement?

How about 'Clarify that "Implementing AVOptions" is addressed to people working
on FFmpeg itself'?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [RFC] 5 year plan & Inovation

[Lynne]

Apr 23, 2024, 09:47 by ffmpeg-de...@pileofstuff.org:

> On Tue, Apr 23, 2024 at 02:20:51AM +0200, Michael Niedermayer wrote:
>
>> On Thu, Apr 18, 2024 at 10:46:35AM +0200, Stefano Sabatini wrote:
>> > On date Wednesday 2024-04-17 15:58:32 +0200, Michael Niedermayer wrote:
>> > > Hi all
>> > > 
>> > > The pace of inovation in FFmpeg has been slowing down.
>> > > Most work is concentarted nowadays on code refactoring, and adding
>> > > support for new codecs and formats.
>> > > 
>> > > Should we
>> > > * make a list of longer term goals
>> > > * vote on them
>> > > * and then together work towards implementing them
>> > > ?
>> > > 
>> > > (The idea here is to increase the success of larger efforts
>> > >  than adding codecs and refactoring code)
>> > > It would then also not be possible for individuals to object
>> > > to a previously agreed goal.
>> > > And it would add ideas for which we can try to get funding/grants for
>> > > 
>> > > (larger scale changes need consensus first that we as a whole want
>> > >  them before we would be able to ask for funding/grants for them)
>> > > 
>> > > Some ideas and why they would help FFmpeg:
>> > > 
>> > [...]
>> > > * client side / in browser support
>> > > (expand towards webapps, webpages using ffmpeg client side in the 
>> > > browser)
>> > > bring in more users and developers, and it will be costly for us
>> > > if we let others take this area as its important and significant
>> > 
>> > There are already several projects on github, the most prominent one:
>> > https://github.com/ffmpegwasm/ffmpeg.wasm/
>> > 
>> > In general it would be useful to provide libav* bindings to other
>> > languages, for example:
>> > https://github.com/PyAV-Org/PyAV
>> > https://github.com/zmwangx/rust-ffmpeg
>> > 
>> > Not sure these should be really moved to FFmpeg though.
>>
>> From a user PoV it would be nice if there was a official
>> python, rust and wasm binding
>>
>> It also would draw in more developers and users to FFmpeg.
>> test coverage might also improve
>>
>> I think the 2 questions are.
>>  1. is there a binding for some language that wants to become the official
>>  FFmpeg binding for that language ?
>>  2. does the FFmpeg community want that too ?
>>
>> thx
>>
>
> I've thought about this a lot while trying to learn FFmpeg.
> IMHO there are two big hurdles to good other-language bindings:
>
> First, FFmpeg's interface is full of C idioms that are unintuitive to
> programmers from other languages.  For example, Stefano Sabatini is
> patiently explaining to me in anoher thread how contexts are a central
> concept in FFmpeg's design.  Even where I understood the code on a
> mechanical level, I had drastically underestimated their importance
> because I didn't have a mental model to understand them.  Binding
> FFmpeg functionality in another language is only half the problem -
> the interface needs to be explained in terms they can understand,
> or rewritten in terms they already know.
>
> Second, the interface is full of special cases that make translation
> to other languages burdensome.  For example, C errors are based on
> returning a value and requiring the caller to check it explicitly;
> whereas most other languages throw an error and allow the caller to
> catch it or not.  A translator needs to convert every one of those,
> but FFmpeg functions don't have a standard mechanism to signal the
> correct behaviour for a given function.  Even the documentation isn't
> reliably helpful, sometimes saying a variant of "returns an AVERROR",
> sometimes "returns a negative number", and sometimes it just
> returns an int and expects the reader to dig through the source.
> That eats up a huge amount of programmer time, and has to be done for
> every language that wants a binding.
>
> Solving those problems would make it far more practical for translators
> to make bindings in other languages, and for new people to learn FFmpeg
> even in C.  For example, creating an `enum AVERROR` and rewriting
> functions to return it would make the code easier to read and drastically
> cut translator time.
>

We always return a negative number for error. 
___
ffmpeg-devel mailing list
ffmpeg-devel@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] lavu/opt: Clarify that AVOptions is not indended for general use

[Andrew Sayers]

On Tue, Apr 23, 2024 at 11:21:27AM +0200, Anton Khirnov wrote:
> > lavu/opt: Clarify that AVOptions is not indended for general use
> 
> They _are_ intended for general use though.

In that case I'm confused...

Let's say I make a desktop app to transcode videos.  Obviously I would use
AVOptions to display configuration options for different encoders.  And it's
possible to create AVOptions objects for my UI.  But how strongly is that use
case recommended?

To provide a particularly difficult example - let's say I want to let the user
choose between interface themes, and I want to show both some text and a
picture of the theme.  AVOption doesn't include a "text + picture" option,
so how would I extend it to meet my needs?
___
ffmpeg-devel mailing list
ffmpeg-devel@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/1] Updated decklink patch

[Michael Riedl]

Hi,

This patch adds the possibility to specify an action to be taken when a signal 
loss is detected on a decklink device.
I have updated the patch from September 2023 to latest master branch (as of 
today).
I would be grateful if this patch could be reviewed and merged.

Kind regards,
Michael


Michael Riedl (1):
  libavdevice/decklink: extend available actions on signal loss

 doc/indevs.texi | 16 
 libavdevice/decklink_common.h   |  1 +
 libavdevice/decklink_common_c.h |  7 +++
 libavdevice/decklink_dec.cpp| 23 ++-
 libavdevice/decklink_dec_c.c|  6 +-
 5 files changed, 51 insertions(+), 2 deletions(-)

--
2.43.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 v2 1/1] libavdevice/decklink: extend available actions on signal loss

[Michael Riedl]

Deprecate the option 'draw_bars' in favor of the new option 
'signal_loss_action',
which controls the behavior when the input signal is not available
(including the behavior previously available through draw_bars).
The default behavior remains unchanged to be backwards compatible.
The new option is more flexible for extending now and in the future.

The new value 'repeat' repeats the last video frame.
This is useful for very short dropouts and was not available before.

Signed-off-by: Michael Riedl 
---
 doc/indevs.texi | 16 
 libavdevice/decklink_common.h   |  1 +
 libavdevice/decklink_common_c.h |  7 +++
 libavdevice/decklink_dec.cpp| 23 ++-
 libavdevice/decklink_dec_c.c|  6 +-
 5 files changed, 51 insertions(+), 2 deletions(-)

diff --git a/doc/indevs.texi b/doc/indevs.texi
index 734fc657523..cdf44a66382 100644
--- a/doc/indevs.texi
+++ b/doc/indevs.texi
@@ -396,6 +396,22 @@ Defaults to @samp{audio}.
 @item draw_bars
 If set to @samp{true}, color bars are drawn in the event of a signal loss.
 Defaults to @samp{true}.
+This option is deprecated, please use the @code{signal_loss_action} option.
+
+@item signal_loss_action
+Sets the action to take in the event of a signal loss. Accepts one of the
+following values:
+
+@table @option
+@item 1, none
+Do nothing on signal loss. This usually results in black frames.
+@item 2, bars
+Draw color bars on signal loss. Only supported for 8-bit input signals.
+@item 3, repeat
+Repeat the last video frame on signal loss.
+@end table
+
+Defaults to @samp{bars}.
 
 @item queue_size
 Sets maximum input buffer size in bytes. If the buffering reaches this value,
diff --git a/libavdevice/decklink_common.h b/libavdevice/decklink_common.h
index c54a635876c..6b32dc2d09c 100644
--- a/libavdevice/decklink_common.h
+++ b/libavdevice/decklink_common.h
@@ -147,6 +147,7 @@ struct decklink_ctx {
 DecklinkPtsSource video_pts_source;
 int draw_bars;
 BMDPixelFormat raw_format;
+DecklinkSignalLossAction signal_loss_action;
 
 int frames_preroll;
 int frames_buffer;
diff --git a/libavdevice/decklink_common_c.h b/libavdevice/decklink_common_c.h
index 9c55d891494..53d2c583e7e 100644
--- a/libavdevice/decklink_common_c.h
+++ b/libavdevice/decklink_common_c.h
@@ -37,6 +37,12 @@ typedef enum DecklinkPtsSource {
 PTS_SRC_NB
 } DecklinkPtsSource;
 
+typedef enum DecklinkSignalLossAction {
+SIGNAL_LOSS_NONE= 1,
+SIGNAL_LOSS_REPEAT  = 2,
+SIGNAL_LOSS_BARS= 3
+} DecklinkSignalLossAction;
+
 struct decklink_cctx {
 const AVClass *cclass;
 
@@ -68,6 +74,7 @@ struct decklink_cctx {
 int64_t timestamp_align;
 int timing_offset;
 int wait_for_tc;
+DecklinkSignalLossAction signal_loss_action;
 };
 
 #endif /* AVDEVICE_DECKLINK_COMMON_C_H */
diff --git a/libavdevice/decklink_dec.cpp b/libavdevice/decklink_dec.cpp
index 671573853ba..1c2d08ea9fc 100644
--- a/libavdevice/decklink_dec.cpp
+++ b/libavdevice/decklink_dec.cpp
@@ -593,6 +593,7 @@ private:
 int no_video;
 int64_t initial_video_pts;
 int64_t initial_audio_pts;
+IDeckLinkVideoInputFrame* last_video_frame;
 };
 
 decklink_input_callback::decklink_input_callback(AVFormatContext *_avctx) : 
_refs(1)
@@ -602,10 +603,13 @@ 
decklink_input_callback::decklink_input_callback(AVFormatContext *_avctx) : _ref
 ctx = (struct decklink_ctx *)cctx->ctx;
 no_video = 0;
 initial_audio_pts = initial_video_pts = AV_NOPTS_VALUE;
+last_video_frame = nullptr;
 }
 
 decklink_input_callback::~decklink_input_callback()
 {
+if (last_video_frame)
+last_video_frame->Release();
 }
 
 ULONG decklink_input_callback::AddRef(void)
@@ -773,7 +777,7 @@ HRESULT decklink_input_callback::VideoInputFrameArrived(
   ctx->video_st->time_base.den);
 
 if (videoFrame->GetFlags() & bmdFrameHasNoInputSource) {
-if (ctx->draw_bars && videoFrame->GetPixelFormat() == 
bmdFormat8BitYUV) {
+if (ctx->signal_loss_action == SIGNAL_LOSS_BARS && 
videoFrame->GetPixelFormat() == bmdFormat8BitYUV) {
 unsigned bars[8] = {
 0xEA80EA80, 0xD292D210, 0xA910A9A5, 0x90229035,
 0x6ADD6ACA, 0x51EF515A, 0x286D28EF, 0x10801080 };
@@ -785,6 +789,8 @@ HRESULT decklink_input_callback::VideoInputFrameArrived(
 for (int x = 0; x < width; x += 2)
 *p++ = bars[(x * 8) / width];
 }
+} else if (ctx->signal_loss_action == SIGNAL_LOSS_REPEAT) {
+last_video_frame->GetBytes();
 }
 
 if (!no_video) {
@@ -793,6 +799,12 @@ HRESULT decklink_input_callback::VideoInputFrameArrived(
 }
 no_video = 1;
 } else {
+if (ctx->signal_loss_action == SIGNAL_LOSS_REPEAT) {
+if (last_video_frame)
+last_video_frame->Release();
+

Re: [FFmpeg-devel] [PATCH v2] lavu/opt: Clarify that AVOptions is not indended for general use

[Anton Khirnov]

> lavu/opt: Clarify that AVOptions is not indended for general use

They _are_ intended for general use though.

-- 
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] lavu/opt: Clarify that AVOptions is not indended for general use

[Anton Khirnov]

Quoting Andrew Sayers (2024-04-23 11:51:00)
> On Tue, Apr 23, 2024 at 11:21:27AM +0200, Anton Khirnov wrote:
> > > lavu/opt: Clarify that AVOptions is not indended for general use
> > 
> > They _are_ intended for general use though.
> 
> In that case I'm confused...
> 
> Let's say I make a desktop app to transcode videos.  Obviously I would use
> AVOptions to display configuration options for different encoders.  And it's
> possible to create AVOptions objects for my UI.  But how strongly is that use
> case recommended?
> 
> To provide a particularly difficult example - let's say I want to let the user
> choose between interface themes, and I want to show both some text and a
> picture of the theme.  AVOption doesn't include a "text + picture" option,
> so how would I extend it to meet my needs?

If they fit your use case, then use them, otherwise don't - that's true
for pretty much all APIs we provide.

-- 
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] lavu/opt: Clarify that AVOptions is not indended for general use

[Andrew Sayers]

On Tue, Apr 23, 2024 at 12:04:34PM +0200, Anton Khirnov wrote:
> Quoting Andrew Sayers (2024-04-23 11:51:00)
> > On Tue, Apr 23, 2024 at 11:21:27AM +0200, Anton Khirnov wrote:
> > > > lavu/opt: Clarify that AVOptions is not indended for general use
> > > 
> > > They _are_ intended for general use though.
> > 
> > In that case I'm confused...
> > 
> > Let's say I make a desktop app to transcode videos.  Obviously I would use
> > AVOptions to display configuration options for different encoders.  And it's
> > possible to create AVOptions objects for my UI.  But how strongly is that 
> > use
> > case recommended?
> > 
> > To provide a particularly difficult example - let's say I want to let the 
> > user
> > choose between interface themes, and I want to show both some text and a
> > picture of the theme.  AVOption doesn't include a "text + picture" option,
> > so how would I extend it to meet my needs?
> 
> If they fit your use case, then use them, otherwise don't - that's true
> for pretty much all APIs we provide.

Ah ok, so how about if I changed "intended" to "optimized" in the subject?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [RFC] 5 year plan & Inovation

[Andrew Sayers]

On Tue, Apr 23, 2024 at 10:02:58AM +0200, Lynne wrote:
> Apr 23, 2024, 09:47 by ffmpeg-de...@pileofstuff.org:
> 
> > On Tue, Apr 23, 2024 at 02:20:51AM +0200, Michael Niedermayer wrote:
> >
> >> On Thu, Apr 18, 2024 at 10:46:35AM +0200, Stefano Sabatini wrote:
> >> > On date Wednesday 2024-04-17 15:58:32 +0200, Michael Niedermayer wrote:
> >> > > Hi all
> >> > > 
> >> > > The pace of inovation in FFmpeg has been slowing down.
> >> > > Most work is concentarted nowadays on code refactoring, and adding
> >> > > support for new codecs and formats.
> >> > > 
> >> > > Should we
> >> > > * make a list of longer term goals
> >> > > * vote on them
> >> > > * and then together work towards implementing them
> >> > > ?
> >> > > 
> >> > > (The idea here is to increase the success of larger efforts
> >> > >  than adding codecs and refactoring code)
> >> > > It would then also not be possible for individuals to object
> >> > > to a previously agreed goal.
> >> > > And it would add ideas for which we can try to get funding/grants for
> >> > > 
> >> > > (larger scale changes need consensus first that we as a whole want
> >> > >  them before we would be able to ask for funding/grants for them)
> >> > > 
> >> > > Some ideas and why they would help FFmpeg:
> >> > > 
> >> > [...]
> >> > > * client side / in browser support
> >> > > (expand towards webapps, webpages using ffmpeg client side in the 
> >> > > browser)
> >> > > bring in more users and developers, and it will be costly for us
> >> > > if we let others take this area as its important and significant
> >> > 
> >> > There are already several projects on github, the most prominent one:
> >> > https://github.com/ffmpegwasm/ffmpeg.wasm/
> >> > 
> >> > In general it would be useful to provide libav* bindings to other
> >> > languages, for example:
> >> > https://github.com/PyAV-Org/PyAV
> >> > https://github.com/zmwangx/rust-ffmpeg
> >> > 
> >> > Not sure these should be really moved to FFmpeg though.
> >>
> >> From a user PoV it would be nice if there was a official
> >> python, rust and wasm binding
> >>
> >> It also would draw in more developers and users to FFmpeg.
> >> test coverage might also improve
> >>
> >> I think the 2 questions are.
> >>  1. is there a binding for some language that wants to become the official
> >>  FFmpeg binding for that language ?
> >>  2. does the FFmpeg community want that too ?
> >>
> >> thx
> >>
> >
> > I've thought about this a lot while trying to learn FFmpeg.
> > IMHO there are two big hurdles to good other-language bindings:
> >
> > First, FFmpeg's interface is full of C idioms that are unintuitive to
> > programmers from other languages.  For example, Stefano Sabatini is
> > patiently explaining to me in anoher thread how contexts are a central
> > concept in FFmpeg's design.  Even where I understood the code on a
> > mechanical level, I had drastically underestimated their importance
> > because I didn't have a mental model to understand them.  Binding
> > FFmpeg functionality in another language is only half the problem -
> > the interface needs to be explained in terms they can understand,
> > or rewritten in terms they already know.
> >
> > Second, the interface is full of special cases that make translation
> > to other languages burdensome.  For example, C errors are based on
> > returning a value and requiring the caller to check it explicitly;
> > whereas most other languages throw an error and allow the caller to
> > catch it or not.  A translator needs to convert every one of those,
> > but FFmpeg functions don't have a standard mechanism to signal the
> > correct behaviour for a given function.  Even the documentation isn't
> > reliably helpful, sometimes saying a variant of "returns an AVERROR",
> > sometimes "returns a negative number", and sometimes it just
> > returns an int and expects the reader to dig through the source.
> > That eats up a huge amount of programmer time, and has to be done for
> > every language that wants a binding.
> >
> > Solving those problems would make it far more practical for translators
> > to make bindings in other languages, and for new people to learn FFmpeg
> > even in C.  For example, creating an `enum AVERROR` and rewriting
> > functions to return it would make the code easier to read and drastically
> > cut translator time.
> >
> 
> We always return a negative number for error. 

This is going to be a lot of detail for a specific example, but I think it
illuminates the general point...

Signalling an error with "a negative number" vs. "an AVERROR" is all-but
synonymous in C - in both cases, you just do `if ( ret < 0 ) return ret;`.  But
the equivalent idiom in most languages involves throwing different data types.
For example, a Python programmer would likely expect the former to throw an
"Exception", but the latter to throw some library-specific "AVErrorException"
type.  A function that "returns a negative number on error" might return `-1`
in all cases, or a 

Re: [FFmpeg-devel] [PATCH 1/2] avcodec/codec_par: always clear extradata_size in avcodec_parameters_to_context()

[James Almer]

On 4/20/2024 8:43 PM, James Almer wrote:

Missed in d383ae43c266b160348db04f2fd17ccf30286784.

Signed-off-by: James Almer 
---
  libavcodec/codec_par.c | 1 +
  1 file changed, 1 insertion(+)

diff --git a/libavcodec/codec_par.c b/libavcodec/codec_par.c
index 212cb97d77..790ea01d10 100644
--- a/libavcodec/codec_par.c
+++ b/libavcodec/codec_par.c
@@ -250,6 +250,7 @@ int avcodec_parameters_to_context(AVCodecContext *codec,
  }
  
  av_freep(>extradata);

+codec->extradata_size = 0;
  if (par->extradata) {
  codec->extradata = av_mallocz(par->extradata_size + 
AV_INPUT_BUFFER_PADDING_SIZE);
  if (!codec->extradata)


Will apply the set.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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