Re: [FFmpeg-devel] [PATCH v1] fftools/ffmpeg_dec: Don't keep sending frame to filters in flushing
On So, 2023-06-25 at 06:20 +, Xiang, Haihao wrote: > On Ma, 2023-06-12 at 11:33 +0800, Fei Wang wrote: > > Filter may has a limited frame pool size. Do not always send frame to > > filters without reaping. > > > > Fix the regression of commit 5fa00b38e6. > > > > Example cmd: > > $ ffmpeg -threads 20 -init_hw_device vaapi=hw:/dev/dri/renderD128 \ > > -hwaccel_output_format vaapi -hwaccel vaapi -i avc_1080P.mp4 \ > > -vf 'scale_vaapi=w=720:h=480' -f null - > > > > Signed-off-by: Fei Wang > > --- > > fftools/ffmpeg_dec.c | 6 ++ > > 1 file changed, 6 insertions(+) > > > > diff --git a/fftools/ffmpeg_dec.c b/fftools/ffmpeg_dec.c > > index 799be63215..d6b34402f8 100644 > > --- a/fftools/ffmpeg_dec.c > > +++ b/fftools/ffmpeg_dec.c > > @@ -531,6 +531,12 @@ int dec_packet(InputStream *ist, const AVPacket *pkt, > > int > > no_eof) > > av_frame_unref(frame); > > if (ret < 0) > > exit_program(1); > > + > > + // During flushing, break out to reap filter once send a frame to > > filters to > > + // avoid drain out filter's output frame pool. Especially for HW > > filters which > > + // always have a limited frame pool size. > > + if (!pkt) > > + return 0; > > Looks good and it works well for me. I'm going to push it if no objection > There is a conflict when applying your patch to the latest FFmpeg, could you rebase the patch ? 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 v2] avformat: add Software Defined Radio support
On Sat, Jun 24, 2023 at 10:27:13PM +0200, Rémi Denis-Courmont wrote: > > > Le 23 juin 2023 20:12:41 GMT+02:00, Michael Niedermayer > a écrit : > >Hi > > > >On Fri, Jun 23, 2023 at 06:37:18PM +0200, Rémi Denis-Courmont wrote: > >> Hi, > >> > >> Le 23 juin 2023 13:17:28 GMT+02:00, Michael Niedermayer > >> a écrit : > >> >On Fri, Jun 23, 2023 at 10:34:10AM +0800, Kieran Kunhya wrote: > >> >> FFmpeg is not the place for SDR. SDR is as large and complex as the > >> >> entirety of multimedia. > >> >> > >> >> What next, is FFmpeg going to implement TCP in userspace, Wifi, > >> >> Ethernet, > >> >> an entire 4G and 5G stack? > >> > > >> >https://en.wikipedia.org/wiki/Straw_man > >> > > >> >What my patch is doing is adding support for AM demodulation, the AM > >> >specific code is like 2 pages. The future plan for FM demodulation will > >> >not add alot of code either. DAB/DVB should also not be anything big > >> >(if that is implemented at all by anyone) > >> > >> Literally every one of those layer-2 protocols has a lower-level API > >> already on Linux, and typically they are, or would be, backends to > >> libavdevice. > >> > >> (Specifically AM and FM are supported by V4L radio+ALSA; DAB and DVB by > >> Linux-DVB. 4G and 5G are network devices.) > > > >4 problems > >* FFmpeg is not "linux only". > > And then what? Whether you like it or not, radio signal processing sits on > top of OS-specific APIs to access whatever bus or hardware. You can't make > this OS-independent whether it's in FFmpeg or elsewhere. > > At best you can write or reuse platform abstraction layers (such as libusb). > Maybe. > > In other words, whether this ends up in FFmpeg or not has absolutely no > bearing on this "problem" as you call it. > > But it doesn't end here. Audio input on Linux is normally exposed with ALSA > modules (hw/plughw if the driver is in kernel, but it doesn't have to be), > and other OSes have equivalent APIs. A sound (pun unintended) implementation > of AM or FM would actually be an ALSA module, and *maybe* also PA and PW > modules. (They don't have to be kernel mode drivers.) > > ...Not an FFmpeg device or demux. > speaking of layers. IMHO the kernel and driver layer should end with the IQ data for SDR. Thats OS specific. After that the whole chain should be largely OS and HW independent turning IQ data to a decoded video and audio stream for DVB is the same on every OS as complex as it may be. We could feed this back into ALSA on linux but i doubt that would be used alot more likely players would link to the library directly that turns IQ -> video+audio even more so because for the player it would be the same on every platform otherwise the player would have to support platform specific interfaces and not just one per platform either i think 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] avformat: add Software Defined Radio support
On Sun, Jun 25, 2023 at 12:19:04AM +0200, Nicolas George wrote: > Michael Niedermayer (12023-06-23): > > * What iam interrested in was working with the signals at a low level, why > > because i find it interresting and fun. > > Then this is what you should be spending your time on, and to hell with > anybody who says otherwise. > > Unless you have commitments that we are not privy of, nobody can tell > you how you are supposed to be spending your time and skills. Nobody can > force you to manage releases and fix fuzzing bugs and do all the things > you do that are necessary to the project. Necessary to a conception of > the good of the project that is not even your own I think. > > Nobody can prevent you from hacking the things that motivate you. At > worst, they can prevent you from committing the resulting code into > official FFmpeg. That would be the project's loss, and you can still > publish it on a private branch. But they do not have the power to block > you from pushing. It is not even clear they have the authority do block > you, more so if the code is really good and fits FFmpeg well. The only > thing that can block you is your desire to play nice and not harm the > project. I would like to emphasize that some of the frequent naysayers > do not have an excellent track record when it comes to playing nice and > especially not harming the project. > > I am especially annoyed by the “it's too hard” naysayers — the same I > have been getting when I say that I want to write a XML suited to our > needs to replace our use of libxml. They do not realize they reveal more > about their own skills than anybody else. You know if you can write a > radio, so ignore them and go ahead. And if they were right, if it is too > hard and you fail… well, you would just have wasted your own time; and > you would have had fun and learned things on the occasion, which means > the time was not even wasted. you are very spot on with all this. anyway i will not push anything to master without the community agreeing, that would do no good. > > But the whole attitude who wants FFmpeg to be a Serious OpenSource TM > Project, who needs to make releases and worry above all about ABI > stability, is really the attitude who is killing all the fun in working > on FFmpeg. > > Hey, people, realize FFmpeg does not exist to be a Serious OpenSource TM > Project, FFmpeg does not exist to serve other projects, to serve > companies who benefit from it give the bare minimum back. > > FFmpeg exists because some day a dude thought it would be fun to write a > MPEG decoder. And everybody else told him it would be too hard, > everybody else told him to use an existing library and to leave it to > the professionals. He did not believe them and proved them utterly > wrong, and the rest, as the saying goes, is history. yes, also in the early days FFmpeg was inovative and pushing the boundaries i mean i could have pushed a cpu emulator and compiler IF there was need for that, noone would have had an issue with that. But nowadays FFmpeg is established and theres tradition. Any breach of that tradition leads to opposition. > > So I will say it explicitly. We — me, and everybody who agrees with me — > do not want to just maintain a bunch of wrappers for the convenience of > others, we want to have fun writing interesting code, trying new ways of > doing things, inventing original optimizations. We can find a balance > and work on useful things too. But if you want us to work only on the > boring useful things, if you want to bar us from working on fun things, > then just fork you. Well, first question really is if we can move forward in the established system. It seems this is at least a bit cumbersome. But we will see where it ends with that sdr feature. It doesnt need to be in a demuxer (IF there was another way, it just seems there is not), it can be in a seperate library (IF there is more than 1 developer interrested in working on it), theres alot of things that can be adjusted to reach a consensus. Then the question is if we have a consensus to push the sdr code in whatever form that would be to git master. If not the code goes elsewhere and that elsewhere should really then be open to everyone else who wants to do inovative work. I think every possible outcome here really has its upsides. Its just a more cumbersome path than what i had envissioned thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Frequently ignored answer#1 FFmpeg bugs should be sent to our bugtracker. User questions about the command line tools should be sent to the ffmpeg-user ML. And questions about how to use libav* should be sent to the libav-user ML. 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 wi
Re: [FFmpeg-devel] [PATCH v2] avformat: add Software Defined Radio support
On Sat, Jun 24, 2023 at 10:27:13PM +0200, Rémi Denis-Courmont wrote: > > > Le 23 juin 2023 20:12:41 GMT+02:00, Michael Niedermayer > a écrit : > >Hi > > > >On Fri, Jun 23, 2023 at 06:37:18PM +0200, Rémi Denis-Courmont wrote: > >> Hi, > >> > >> Le 23 juin 2023 13:17:28 GMT+02:00, Michael Niedermayer > >> a écrit : > >> >On Fri, Jun 23, 2023 at 10:34:10AM +0800, Kieran Kunhya wrote: > >> >> FFmpeg is not the place for SDR. SDR is as large and complex as the > >> >> entirety of multimedia. > >> >> > >> >> What next, is FFmpeg going to implement TCP in userspace, Wifi, > >> >> Ethernet, > >> >> an entire 4G and 5G stack? > >> > > >> >https://en.wikipedia.org/wiki/Straw_man > >> > > >> >What my patch is doing is adding support for AM demodulation, the AM > >> >specific code is like 2 pages. The future plan for FM demodulation will > >> >not add alot of code either. DAB/DVB should also not be anything big > >> >(if that is implemented at all by anyone) > >> > >> Literally every one of those layer-2 protocols has a lower-level API > >> already on Linux, and typically they are, or would be, backends to > >> libavdevice. > >> > >> (Specifically AM and FM are supported by V4L radio+ALSA; DAB and DVB by > >> Linux-DVB. 4G and 5G are network devices.) > > > >4 problems > >* FFmpeg is not "linux only". > > And then what? Whether you like it or not, radio signal processing sits on > top of OS-specific APIs to access whatever bus or hardware. You can't make > this OS-independent whether it's in FFmpeg or elsewhere. > > At best you can write or reuse platform abstraction layers (such as libusb). > Maybe. > > In other words, whether this ends up in FFmpeg or not has absolutely no > bearing on this "problem" as you call it. > > But it doesn't end here. Audio input on Linux is normally exposed with ALSA > modules (hw/plughw if the driver is in kernel, but it doesn't have to be), > and other OSes have equivalent APIs. A sound (pun unintended) implementation > of AM or FM would actually be an ALSA module, and *maybe* also PA and PW > modules. (They don't have to be kernel mode drivers.) > > ...Not an FFmpeg device or demux. This is interresting. I never tried but there should be a way to pipe ffmpeg output back into alsa to make it available as an alsa module This could actually be usefull as is with no sdr. but that tought i have here is 100% off topic > > >* No software i tried or was suggested to me used V4L or Linux-DVB. > > That would be because audio input is done with ALSA (in combination with V4L > for *hardware* radio tuning). > > The point was that this is lower layer stuff that belongs in a lower level > library or module, rather than FFmpeg. I never *literally* said that you > should (or even could) use V4L or Linux-DVB here. Those APIs are rather for > the *hardware* equivalent of what you're doing in *software*. > > So again, no "problem" here. ok, i misunderstood you somewhat here thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Old school: Use the lowest level language in which you can solve the problem conveniently. New school: Use the highest level language in which the latest supercomputer can solve the problem without the user falling asleep waiting. signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 2/3] avformat/tee: use av_dict_pop
> On May 1, 2023, at 19:44, Marvin Scholz wrote:
>
> This is a well-defined way to "steal" the value of the dict entry.
> ---
> libavformat/tee.c | 9 +
> 1 file changed, 5 insertions(+), 4 deletions(-)
>
> diff --git a/libavformat/tee.c b/libavformat/tee.c
> index cb555f52fd..70f3f2eb29 100644
> --- a/libavformat/tee.c
> +++ b/libavformat/tee.c
> @@ -157,6 +157,7 @@ static int open_slave(AVFormatContext *avf, char *slave,
> TeeSlave *tee_slave)
> {
> int i, ret;
> AVDictionary *options = NULL, *bsf_options = NULL;
> +char *entry_val = NULL;
> AVDictionaryEntry *entry;
> char *filename;
> char *format = NULL, *select = NULL, *on_fail = NULL;
> @@ -171,15 +172,15 @@ static int open_slave(AVFormatContext *avf, char
> *slave, TeeSlave *tee_slave)
> return ret;
>
> #define CONSUME_OPTION(option, field, action) do { \
> -if ((entry = av_dict_get(options, option, NULL, 0))) { \
> -field = entry->value; \
> +if ((!av_dict_pop(&options, option, NULL, &entry_val, 0))) {\
> +field = entry_val; \
Nit: You can remove the extra level of parentheses now.
> { action } \
> -av_dict_set(&options, option, NULL, 0); \
> +av_freep(&entry_val); \
> } \
> } while (0)
> #define STEAL_OPTION(option, field) \
> CONSUME_OPTION(option, field, \
> - entry->value = NULL; /* prevent it from being freed */)
> + entry_val = NULL; /* prevent it from being freed */)
> #define PROCESS_OPTION(option, field, function, on_error) \
> CONSUME_OPTION(option, field, if ((ret = function) < 0) { { on_error }
> goto end; })
>
> --
> 2.37.0 (Apple Git-136)
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v2 3/3] avutil/dict: constify av_dict_get return
---
doc/examples/qsv_transcode.c | 2 +-
libavcodec/libaomenc.c | 2 +-
libavcodec/libkvazaar.c| 2 +-
libavcodec/libsvtav1.c | 2 +-
libavcodec/libvpxenc.c | 2 +-
libavcodec/libx264.c | 2 +-
libavcodec/libx265.c | 2 +-
libavcodec/mjpegdec.c | 2 +-
libavcodec/qsvenc.c| 2 +-
libavfilter/avfilter.c | 2 +-
libavfilter/f_bench.c | 2 +-
libavfilter/f_drawgraph.c | 2 +-
libavfilter/f_select.c | 4 +--
libavfilter/vf_cover_rect.c| 2 +-
libavfilter/vf_drawtext.c | 2 +-
libavformat/aiffenc.c | 2 +-
libavformat/argo_asf.c | 2 +-
libavformat/asfenc.c | 6 ++--
libavformat/au.c | 2 +-
libavformat/avformat.h | 2 +-
libavformat/avidec.c | 2 +-
libavformat/avienc.c | 2 +-
libavformat/avio.c | 4 +--
libavformat/dashenc.c | 6 ++--
libavformat/dvenc.c| 2 +-
libavformat/flacdec.c | 2 +-
libavformat/flacenc.c | 6 ++--
libavformat/flvdec.c | 2 +-
libavformat/gxfenc.c | 2 +-
libavformat/http.c | 8 +++---
libavformat/id3v2.c| 6 ++--
libavformat/id3v2enc.c | 2 +-
libavformat/imfdec.c | 2 +-
libavformat/matroskadec.c | 2 +-
libavformat/mov.c | 6 ++--
libavformat/movenc.c | 46 +++---
libavformat/mp3enc.c | 6 ++--
libavformat/mpegtsenc.c| 6 ++--
libavformat/mux.c | 2 +-
libavformat/mux_utils.c| 2 +-
libavformat/mxfenc.c | 14 -
libavformat/riffenc.c | 2 +-
libavformat/rmenc.c| 2 +-
libavformat/sapenc.c | 2 +-
libavformat/sdp.c | 2 +-
libavformat/segment.c | 4 +--
libavformat/soxenc.c | 2 +-
libavformat/tee.c | 2 +-
libavformat/ttmlenc.c | 4 +--
libavformat/wavenc.c | 4 +--
libavformat/webmdashenc.c | 30 +--
libavutil/dict.c | 9 +-
libavutil/dict.h | 5
libavutil/hwcontext_cuda.c | 2 +-
libavutil/hwcontext_qsv.c | 2 +-
libavutil/hwcontext_vulkan.c | 8 +++---
libavutil/version.h| 1 +
tests/api/api-threadmessage-test.c | 2 +-
58 files changed, 136 insertions(+), 123 deletions(-)
diff --git a/doc/examples/qsv_transcode.c b/doc/examples/qsv_transcode.c
index 48128b200c..cc4c203d94 100644
--- a/doc/examples/qsv_transcode.c
+++ b/doc/examples/qsv_transcode.c
@@ -87,7 +87,7 @@ static int dynamic_set_parameter(AVCodecContext *avctx)
frame_number++;
if (current_setting_number < setting_number &&
frame_number == dynamic_setting[current_setting_number].frame_number) {
-AVDictionaryEntry *e = NULL;
+const AVDictionaryEntry *e = NULL;
ret = str_to_dict(dynamic_setting[current_setting_number++].optstr,
&opts);
if (ret < 0) {
fprintf(stderr, "The dynamic parameter is wrong\n");
diff --git a/libavcodec/libaomenc.c b/libavcodec/libaomenc.c
index 16747e7e92..af6d50f9e3 100644
--- a/libavcodec/libaomenc.c
+++ b/libavcodec/libaomenc.c
@@ -999,7 +999,7 @@ static av_cold int aom_init(AVCodecContext *avctx,
#if AOM_ENCODER_ABI_VERSION >= 23
{
-AVDictionaryEntry *en = NULL;
+const AVDictionaryEntry *en = NULL;
while ((en = av_dict_get(ctx->aom_params, "", en,
AV_DICT_IGNORE_SUFFIX))) {
int ret = aom_codec_set_option(&ctx->encoder, en->key, en->value);
diff --git a/libavcodec/libkvazaar.c b/libavcodec/libkvazaar.c
index 2ef34dd82e..2178f7ec45 100644
--- a/libavcodec/libkvazaar.c
+++ b/libavcodec/libkvazaar.c
@@ -104,7 +104,7 @@ FF_ENABLE_DEPRECATION_WARNINGS
if (ctx->kvz_params) {
AVDictionary *dict = NULL;
if (!av_dict_parse_string(&dict, ctx->kvz_params, "=", ",", 0)) {
-AVDictionaryEntry *entry = NULL;
+const AVDictionaryEntry *entry = NULL;
while ((entry = av_dict_get(dict, "", entry,
AV_DICT_IGNORE_SUFFIX))) {
if (!api->config_parse(cfg, entry->key, entry->value)) {
av_log(avctx, AV_LOG_WARNING, "Invalid option: %s=%s.\n",
diff --git a/libavcodec/libsvtav1.c b/libavcodec/libsvtav1.c
index 718a04d221..0f423cdbb8 100644
--- a/libavcodec/libsvtav1.c
+++ b/libavcodec/libsvtav1.c
@@ -151,7 +151,7 @@ static int config_enc_params(EbSvtAv1EncConfiguration
*param,
{
SvtContext *svt_enc = avctx->priv_data;
const AVPixFmtDescriptor *desc;
-AVDictionaryEntry *en = NULL;
+const AVDictionaryEntry *en = NULL;
// Update param from op
[FFmpeg-devel] [PATCH v2 2/3] avformat/tee: use av_dict_pop
This is a well-defined way to "steal" the value of the dict entry.
---
libavformat/tee.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/libavformat/tee.c b/libavformat/tee.c
index cb555f52fd..70f3f2eb29 100644
--- a/libavformat/tee.c
+++ b/libavformat/tee.c
@@ -157,6 +157,7 @@ static int open_slave(AVFormatContext *avf, char *slave,
TeeSlave *tee_slave)
{
int i, ret;
AVDictionary *options = NULL, *bsf_options = NULL;
+char *entry_val = NULL;
AVDictionaryEntry *entry;
char *filename;
char *format = NULL, *select = NULL, *on_fail = NULL;
@@ -171,15 +172,15 @@ static int open_slave(AVFormatContext *avf, char *slave,
TeeSlave *tee_slave)
return ret;
#define CONSUME_OPTION(option, field, action) do { \
-if ((entry = av_dict_get(options, option, NULL, 0))) { \
-field = entry->value; \
+if ((!av_dict_pop(&options, option, NULL, &entry_val, 0))) {\
+field = entry_val; \
{ action } \
-av_dict_set(&options, option, NULL, 0); \
+av_freep(&entry_val); \
} \
} while (0)
#define STEAL_OPTION(option, field) \
CONSUME_OPTION(option, field, \
- entry->value = NULL; /* prevent it from being freed */)
+ entry_val = NULL; /* prevent it from being freed */)
#define PROCESS_OPTION(option, field, function, on_error) \
CONSUME_OPTION(option, field, if ((ret = function) < 0) { { on_error }
goto end; })
--
2.37.0 (Apple Git-136)
___
ffmpeg-devel mailing list
ffmpeg-devel@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/3] avutil/dict: add av_dict_pop
This new API allows to remove an entry and obtain ownership of the
key/value that was associated with the removed entry.
---
Changes since v1:
- Clarify documentation about av_free having to be used.
- Fix fate test to not rely on specific error code value
doc/APIchanges | 4
libavutil/dict.c | 27 +++
libavutil/dict.h | 26 ++
libavutil/tests/dict.c | 38 ++
libavutil/version.h| 4 ++--
tests/ref/fate/dict| 12
6 files changed, 109 insertions(+), 2 deletions(-)
diff --git a/doc/APIchanges b/doc/APIchanges
index f040211f7d..d55821f682 100644
--- a/doc/APIchanges
+++ b/doc/APIchanges
@@ -2,6 +2,10 @@ The last version increases of all libraries were on 2023-02-09
API changes, most recent first:
+2023-06-02 - xx - lavu 58.14.100 - dict.h
+ Add av_dict_pop() to remove an entry from a dict
+ and get ownership of the removed key/value.
+
2023-05-29 - xx - lavc 60.16.100 - avcodec.h codec_id.h
Add AV_CODEC_ID_EVC, FF_PROFILE_EVC_BASELINE, and FF_PROFILE_EVC_MAIN.
diff --git a/libavutil/dict.c b/libavutil/dict.c
index f673977a98..ac41771994 100644
--- a/libavutil/dict.c
+++ b/libavutil/dict.c
@@ -173,6 +173,33 @@ int av_dict_set_int(AVDictionary **pm, const char *key,
int64_t value,
return av_dict_set(pm, key, valuestr, flags);
}
+int av_dict_pop(AVDictionary **pm, const char *key,
+char **out_key, char **out_value, int flags)
+{
+AVDictionary *m = *pm;
+AVDictionaryEntry *entry = NULL;
+entry = (AVDictionaryEntry *)av_dict_get(m, key, NULL, flags);
+if (!entry)
+return AVERROR(ENOENT);
+
+if (out_key)
+*out_key = entry->key;
+else
+av_free(entry->key);
+
+if (out_value)
+*out_value = entry->value;
+else
+av_free(entry->value);
+
+*entry = m->elems[--m->count];
+if (m && !m->count) {
+av_freep(&m->elems);
+av_freep(pm);
+}
+return 0;
+}
+
static int parse_key_value_pair(AVDictionary **pm, const char **buf,
const char *key_val_sep, const char *pairs_sep,
int flags)
diff --git a/libavutil/dict.h b/libavutil/dict.h
index 713c9e361a..31d38dabec 100644
--- a/libavutil/dict.h
+++ b/libavutil/dict.h
@@ -172,6 +172,32 @@ int av_dict_set(AVDictionary **pm, const char *key, const
char *value, int flags
*/
int av_dict_set_int(AVDictionary **pm, const char *key, int64_t value, int
flags);
+/**
+ * Remove the entry with the given key from the dictionary.
+ *
+ * Search for an entry matching @p key and remove it, if found. Optionally
+ * the found key and/or value can be returned using the @p out_key and
+ * @p out_value arguments.
+ *
+ * If more than one entry matches, only one entry is removed and returned
+ * on each call. Which entry is returned first in that case is undefined.
+ *
+ * @param pmPointer to a pointer to a dictionary struct.
+ * @param key Entry key to match.
+ * @param out_key Pointer whose pointee will be set to the matched
+ * entry key. Must be freed using av_dict_free() by
+ * the caller. May be NULL.
+ * @param out_value Pointer whose pointee will be set to the matched
+ * entry value. Must be freed using av_dict_free() by
+ * the caller. May be NULL.
+ *
+ * @retval 0Success
+ * @retval AVERROR(ENOENT) No item for the given key found
+ * @retval "Other (negative) AVERROR" Other failure
+ */
+int av_dict_pop(AVDictionary **pm, const char *key,
+char **out_key, char **out_value, int flags);
+
/**
* Parse the key/value pairs list and add the parsed entries to a dictionary.
*
diff --git a/libavutil/tests/dict.c b/libavutil/tests/dict.c
index bececefb31..06d94ecc9a 100644
--- a/libavutil/tests/dict.c
+++ b/libavutil/tests/dict.c
@@ -158,5 +158,43 @@ int main(void)
printf("%s\n", e->value);
av_dict_free(&dict);
+char *key, *val = NULL;
+int ret;
+printf("\nTesting av_dict_pop() with existing AVDictionaryEntry.key as
key\n");
+av_dict_set(&dict, "test-key", "test-value", 0);
+ret = av_dict_pop(&dict, "test-key", &key, &val, 0);
+printf("%s: %s (Return code: %i)\n",
+(key) ? key : "(null)",
+(val) ? val : "(null)", ret);
+e = av_dict_get(dict, "test-key", NULL, 0);
+printf("%s\n", (e) ? e->value : "(null)");
+av_freep(&key);
+av_freep(&val);
+
+printf("\nTesting av_dict_pop() with nonexistent key\n");
+ret = av_dict_pop(&dict, "test-key", &key, &val, 0);
+printf("%s: %s ",
+(key) ? key : "(null)",
+(val) ? val : "(null)");
+if (ret == AVERROR(ENOENT))
+printf("(Return code: ENOENT)\n");
+else
+printf("(Return code: Unexpected error: %i)\n", ret);
+e = av_dict_get(dict, "test-key",
Re: [FFmpeg-devel] [PATCH v2] avformat: add Software Defined Radio support
> > > 3. as a fun excercise about SDR, modulations and related math. > > There is no reason why your own personal experiments should contaminate > master. > Agreed, there's nothing wrong with writing an SDR library around FFmpeg programming paradigms (C, handwritten asm and not intrinsics etc). B But this should be in a separate library related to SDR and not FFmpeg. Kieran ___ ffmpeg-devel mailing list ffmpeg-devel@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] avformat: add Software Defined Radio support
On Sun, Jun 25, 2023 at 12:01:07AM +0200, Tomas Härdin wrote: > lör 2023-06-24 klockan 23:01 +0200 skrev Michael Niedermayer: > > On Sat, Jun 24, 2023 at 11:51:57AM +0200, Tomas Härdin wrote: > > > fre 2023-06-23 klockan 23:18 +0200 skrev Michael Niedermayer: > > > > > > > > Are you planing to add SDR support through some library like GNU > > > > radio > > > > to FFmpeg ? > > > > > > This is begging the question. I don't care what you think is fun, > > > this > > > is outside the scope of the project. Not everything needs to be > > > shoveled into FFmpeg master. The UNIX pipe was invented for a > > > reason. > > > Use radio tools to do radio stuff, then pipe the resulting > > > bitstream or > > > audio stream into FFmpeg if you need to say transcode DAB to Opus > > > for > > > streaming on the Web or something. > > > > We will have to agree to disagree here. > > all other sources of audio and video work conveniently in FFmpeg > > I can also play a video and switch subtitle and audio streams with a > > button not have to use a external demultiplxer and choose the streams > > before starting the player. > > If you want to listen to AM broadcasts then there are already plenty of > programs to do that. If you want to skim the bands for interesting > broadcasts there are tools for that as well. Have you even done basic > research to see what is out there? Ive looked a bit, i found CubicSDR and SDR++ i like these tools they are cool. But they dont seem to do many demodulations, just analog also they are very manual which is cool sure but what iam missing is a "iphone" like experience. Something with 2 buttons as in next station, previous station, hold one to record, hold both to record everything, double click to switch between audio and viddeo ;) not exacty like that of course but the idea of simple convenient and 99.99% working, no tool i saw or heared of does this. you know, not i have to select the frequency i have to select the demodulation i have to figure out what the song name is. Something when i hear a song i like i press record and it figures out what song this is (RDS has the info) figures out when the song started and goes back in some cache and stores that from the past Thats one use case like i said. Theres surely a lot more. like dumping everything from the whole DAB or FM band into a properly sorted "mp3/aac" library or maybe record all the air traffic control stuff (not that i care) but i suspect some people would care and for that i wouldnt be surpised if software exists already > > > > > I think GNU radio is a poor choice, even just the base package > > > > has > > > > "Installed-Size: 407 MB" that would be huge dependancy to avoid > > > > ATM 2 > > > > pages > > > > of modem code > > > > > > Ridiculous justification for increasing technical debt in the > > > project. > > > Modern computers have more than enough disk. GNU Radio supports > > > offloading processing to on-board FPGAs among other very useful > > > features for radio work. > > > > somehow you swing between extreems here > > first its pipes or nothing now we need FPGAs > > Yeah because different applications call for different tools. You > cannot do RADAR or WiFi on the CPU. we are drifting off topic. But "You cannot do" triggers me a bit reminds be of "you cannot break videocrypt without FFTs on FPGAs" I did that on the CPU of my average desktop in 1997 https://guru.multimedia.cx/index.php?s=videocrypt so now we cannot do RADAR on the CPU ? why exactly would that be so ? RADAR is not one thing btw, theres alot of different RADAR systems some i do belive worked with vaccuum tubes i do guess you dont mean these with wifi theres also different iterations. I guess as bandwidth increases we need more processing > Hence why there's a sophisticated > set of tools for doing radio stuff already. Tools that could use more > developer effort. > > > where ATM its just 2 pages of modem related code > > All the better reason to nip it in the bud. > > > > There are more light-weight options if you > > > just want AM/FM, that can then be piped to FFmpeg by various means > > > (jack or named pipes). gqrx for example, which in Debian (gqrx-sdr) > > > comes to 25 megs of downloads (152 megs on disk) including all > > > dependencies, which includes gnuradio, gnuradio-dev, gr-osmosdr etc > > > > I think we somehow are not talking on the same frequency ;) > > if i want just AM/FM i need 10 pages of code max and writing these > > pages is a fun thing to do for me. > > Fun for you is technical debt for everyone else. how is a self contained module affecting anyone excpet who works on it? [...] > > > > Not that i personally have anything against GPL, I like GPL > > > > but thats not the preferred license in FFmpeg > > > > > > > > do you suggest we should create a libavradio ? > > > > or can you suggest an existing library that would fit the C + > > > > clean > > > > ASM > > > > LGPL style that FFmpeg tends to prefer ? > > >
