Re: [FFmpeg-devel] [PATCH v2] avformat: add Software Defined Radio support
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) If the code grows beyond that it could be split out into a seperate library outside FFmpeg. The size of all of SDR really has as much bearing on FFmpeg as the size of all of mathematics has on the use of mathematics in FFmpeg. > All without any separation of layers (the problem you currently have)? Lets see where the review process leads to. It is possible iam missing some things, its possible others are missing some factors. Ultimately sdr is more similar than it is different from existing input devices and demuxers. The review process may identify possible solutions that benefit other input devices too. It might identify shortcommings in FFmpeg that could lead to improvments. I dont really enjoy the review process ATM, no ;) but lets see where it leads to. Thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Dictatorship naturally arises out of democracy, and the most aggravated form of tyranny and slavery out of the most extreme liberty. -- Plato signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC] SDR
On 6/22/2023 1:09 PM, Anton Khirnov wrote: Hi, I'm sorry to say, the patch at its current state is quite far from something I'd consider acceptable for git master. 1) Given that there are sdr and sdrfile demuxers, it seems to me that the transport layer should be split into a protocol rather than be inside the demuxer I disagree. It's not a protocol. I can't get a Matroska bitstream out of this like i could from an actual protocol like http, smb, etc. This is a capture device. 2) Threading inside the demuxer, with pthread calls randomly sprinkled throughout is particularly ugly and dangerous. Demuxers should not do their own threading. 3) sdr_read_header() and sdr_read_packet() are giant, hideous, and unreadable. 4) Why does there seem to be drawing code in a demuxer? ___ 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 Fri, 23 Jun 2023, 19:17 Michael Niedermayer, wrote: > 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 It's not a straw man, I'm asking why you want to add layers far below multimedia to ffmpeg. All of those examples are similar examples of physical layers. > 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) > If the code grows beyond that it could be split out into a seperate > library outside FFmpeg. > Then just put it in a library outside of FFmpeg to begin with. DVB-T2 and S2 are very complex to implement well. AM and FM are toys in comparison. > The size of all of SDR really has as much bearing on FFmpeg as the size > of all of mathematics has on the use of mathematics in FFmpeg. > I have no idea what this means, mathematics is needed in multimedia, SDR is not. > > All without any separation of layers (the problem you currently have)? > > Lets see where the review process leads to. > It is possible iam missing some things, its possible others are missing > some factors. > Ultimately sdr is more similar than it is different from existing input > devices and demuxers. > The review process may identify possible solutions that benefit other > input devices too. It might identify shortcommings in FFmpeg that > could lead to improvments. > I dont really enjoy the review process ATM, no ;) but lets see where it > leads to. > No input device needs to do active mathematical processing on the data at a analogue layer. SDR isn't similar at all. 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 1/5] avcodec/evc_frame_merge: ensure the assembled buffer fits in an AVPacket
On 6/22/2023 4:29 PM, James Almer wrote: Signed-off-by: James Almer --- libavcodec/evc_frame_merge_bsf.c | 12 ++-- 1 file changed, 10 insertions(+), 2 deletions(-) Will apply 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".
Re: [FFmpeg-devel] [PATCH] lavfi/vf_libplacebo: simplify SAR normalization
On Tue, 20 Jun 2023 17:12:48 +0200 Niklas Haas wrote:
> From: Niklas Haas
>
> The old logic was trying to be excessively clever in "deducing" that the
> user wanted to stretch/scale the image when ow/oh differed from iw/ih
> aspect ratio. But this is almost surely unintended except in
> pathological cases, and in those cases users should simply disable
> normalize_sar and do all the stretching/scaling logic themselves. This
> is especially important in multi-input mode, where the canvas may be
> vastly different from the input dimensions of any stream. Also, passing
> through input 0 SAR in multi-input mode is arbitrary and nearly useless,
> so again force output SAR to 1:1 here.
> ---
> libavfilter/vf_libplacebo.c | 19 ++-
> 1 file changed, 6 insertions(+), 13 deletions(-)
>
> diff --git a/libavfilter/vf_libplacebo.c b/libavfilter/vf_libplacebo.c
> index 0f7c6481925..e58183a5caa 100644
> --- a/libavfilter/vf_libplacebo.c
> +++ b/libavfilter/vf_libplacebo.c
> @@ -160,7 +160,6 @@ typedef struct LibplaceboContext {
> // Parsed expressions for input/output crop
> AVExpr *crop_x_pexpr, *crop_y_pexpr, *crop_w_pexpr, *crop_h_pexpr;
> AVExpr *pos_x_pexpr, *pos_y_pexpr, *pos_w_pexpr, *pos_h_pexpr;
> -AVRational target_sar;
> float pad_crop_ratio;
> float corner_rounding;
> int force_original_aspect_ratio;
> @@ -795,9 +794,9 @@ static void update_crops(AVFilterContext *ctx,
> LibplaceboInput *in,
> target->crop.y0 = av_expr_eval(s->pos_y_pexpr, s->var_values,
> NULL);
> target->crop.x1 = target->crop.x0 + s->var_values[VAR_POS_W];
> target->crop.y1 = target->crop.y0 + s->var_values[VAR_POS_H];
> -
> -if (s->target_sar.num) {
> -float aspect = pl_rect2df_aspect(&target->crop) *
> av_q2d(s->target_sar);
> +if (s->normalize_sar) {
> +float aspect = pl_rect2df_aspect(&image->crop);
> +aspect *= av_q2d(in->link->sample_aspect_ratio);
> pl_rect2df_aspect_set(&target->crop, aspect,
> s->pad_crop_ratio);
> }
> }
> @@ -1188,7 +1187,6 @@ static int libplacebo_config_output(AVFilterLink
> *outlink)
> const AVPixFmtDescriptor *out_desc =
> av_pix_fmt_desc_get(outlink->format);
> AVHWFramesContext *hwfc;
> AVVulkanFramesContext *vkfc;
> -AVRational scale_sar;
>
> /* Frame dimensions */
> RET(ff_scale_eval_dimensions(s, s->w_expr, s->h_expr, inlink, outlink,
> @@ -1198,20 +1196,15 @@ static int libplacebo_config_output(AVFilterLink
> *outlink)
> s->force_original_aspect_ratio,
> s->force_divisible_by);
>
> -scale_sar = (AVRational){outlink->h * inlink->w, outlink->w * inlink->h};
> -if (inlink->sample_aspect_ratio.num)
> -scale_sar = av_mul_q(scale_sar, inlink->sample_aspect_ratio);
> -
> -if (s->normalize_sar) {
> -/* Apply all SAR during scaling, so we don't need to set the out SAR
> */
> +if (s->normalize_sar || s->nb_inputs > 1) {
> +/* SAR is normalized, or we have multiple inputs, set out to 1:1 */
> outlink->sample_aspect_ratio = (AVRational){ 1, 1 };
> -s->target_sar = scale_sar;
> } else {
> /* This is consistent with other scale_* filters, which only
> * set the outlink SAR to be equal to the scale SAR iff the input SAR
> * was set to something nonzero */
> if (inlink->sample_aspect_ratio.num)
> -outlink->sample_aspect_ratio = scale_sar;
> +outlink->sample_aspect_ratio = inlink->sample_aspect_ratio;
> }
>
> /* Frame rate */
> --
> 2.41.0
>
Merged as 5fdb12d6a06.
___
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/2] lavu/tests/cpu: stop processing the thread count
Just print it as it is.
Needed by the following commit.
---
libavutil/tests/cpu.c | 8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/libavutil/tests/cpu.c b/libavutil/tests/cpu.c
index a52637339d..200f20388a 100644
--- a/libavutil/tests/cpu.c
+++ b/libavutil/tests/cpu.c
@@ -106,7 +106,7 @@ int main(int argc, char **argv)
int cpu_flags_raw = av_get_cpu_flags();
int cpu_flags_eff;
int cpu_count = av_cpu_count();
-char threads[5] = "auto";
+const char *threads = "auto";
int i;
for(i = 0; cpu_flag_tab[i].flag; i++) {
@@ -136,11 +136,7 @@ int main(int argc, char **argv)
}
case 't':
{
-int len = av_strlcpy(threads, optarg, sizeof(threads));
-if (len >= sizeof(threads)) {
-fprintf(stderr, "Invalid thread count '%s'\n", optarg);
-return 2;
-}
+threads = optarg;
}
}
}
--
2.40.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 2/2] tests/fate-run: add testing with a random number of threads
Useful for discovering bugs that depend on a specific thread count.
Uses a simple PRNG copied from random() from libavutil/eval.c
Use like THREADS=randomX for a random thread count from 1 to X, with
X=16 when not specified.
---
doc/fate.texi | 5 +
tests/fate-run.sh | 9 +
2 files changed, 14 insertions(+)
diff --git a/doc/fate.texi b/doc/fate.texi
index 8450856015..13aea7a21f 100644
--- a/doc/fate.texi
+++ b/doc/fate.texi
@@ -223,6 +223,11 @@ meaning only while running the regression tests.
Specify how many threads to use while running regression tests, it is
quite useful to detect thread-related regressions.
+This variable may be set to the string "random", optionally followed by a
+number, like "random99", This will cause each test to use a random number of
+threads. If a number is specified, it is used as a maximum number of threads,
+otherwise 16 is the maximum.
+
@item THREAD_TYPE
Specify which threading strategy test, either @samp{slice} or @samp{frame},
by default @samp{slice+frame}
diff --git a/tests/fate-run.sh b/tests/fate-run.sh
index e12279e4cf..55c579f84e 100755
--- a/tests/fate-run.sh
+++ b/tests/fate-run.sh
@@ -33,6 +33,15 @@ errfile="${outdir}/${test}.err"
cmpfile="${outdir}/${test}.diff"
repfile="${outdir}/${test}.rep"
+case $threads in
+random*)
+threads_max=${threads#random}
+[ -z "$threads_max" ] && threads_max=16
+threads="mod(time(0)*1664525+1013904223,$threads_max)+1"
+;;
+esac
+
+
target_path(){
test ${1} = ${1#/} && p=${target_path}/
echo ${p}${1}
--
2.40.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2] avformat: add Software Defined Radio support
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.) So I can only agree with Kieran that these are *lower* layers, that don't really look like they belong in FFmpeg. >If the code grows beyond that it could be split out into a seperate >library outside FFmpeg. I think that the point is, that that code should be up-front in a separate FFmpeg-independent library. And it's not just a technical argument with layering. It's also that it's too far outside what FFmpeg typically works with, so it really should not be put under the purview of FFmpeg-devel. In other words, it's also a social problem. The flip side of that argument is that this may be of interest to other higher-level projects than FFmpeg, including projects that (rightfully) don't depend on FFmpeg, and that this may interest people who wouldn't contribute or participate in FFmpeg. >The size of all of SDR really has as much bearing on FFmpeg as the size >of all of mathematics has on the use of mathematics in FFmpeg. On an empirical basis, I'd argue that FFmpeg mathematics are so fine-tuned to specific algorithmic use cases, that you will anyway end up writing custom algorithms and optimisations here. And thus you won't be sharing much code with (the rest of) FFmpeg down the line. > > >> All without any separation of layers (the problem you currently have)? > >Lets see where the review process leads to. >It is possible iam missing some things, its possible others are missing >some factors. >Ultimately sdr is more similar than it is different from existing input >devices and demuxers. >The review process may identify possible solutions that benefit other >input devices too. It might identify shortcommings in FFmpeg that >could lead to improvments. >I dont really enjoy the review process ATM, no ;) but lets see where it >leads to. > >Thx > >[...] ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2] avformat: add Software Defined Radio support
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". * No software i tried or was suggested to me used V4L or Linux-DVB. * iam not sure the RSP1A i have has linux drivers for these interfaces * What iam interrested in was working with the signals at a low level, why because i find it interresting and fun. Accessing AM/FM through some high level API is not something iam interrested in. This is also because any issues are likely unsolvable at that level. If probing didnt find a station, or demodulation doesnt work, a high level API likely wont allow doing anything about that. > > So I can only agree with Kieran that these are *lower* layers, that don't > really look like they belong in FFmpeg. FFmpeg has been always very low level. We stoped at where the OS provides support that works, not at some academic "level". If every OS provides a great SDR API than i missed that, which is possible because that was never something i was interrested in. > > >If the code grows beyond that it could be split out into a seperate > >library outside FFmpeg. > > I think that the point is, that that code should be up-front in a separate > FFmpeg-independent library. And it's not just a technical argument with > layering. It's also that it's too far outside what FFmpeg typically works > with, so it really should not be put under the purview of FFmpeg-devel. In > other words, it's also a social problem. > > The flip side of that argument is that this may be of interest to other > higher-level projects than FFmpeg, including projects that (rightfully) don't > depend on FFmpeg, and that this may interest people who wouldn't contribute > or participate in FFmpeg. The issue i have with this view is it comes from people who want nothing to do with this SDR work. I would see this argument very differntly if it would come from people who want to work on that external SDR library. I mean this is more a "go away" than a "lets work together on SDR (for FFmpeg)" > > >The size of all of SDR really has as much bearing on FFmpeg as the size > >of all of mathematics has on the use of mathematics in FFmpeg. > > On an empirical basis, I'd argue that FFmpeg mathematics are so fine-tuned to > specific algorithmic use cases, that you will anyway end up writing custom > algorithms and optimisations here. And thus you won't be sharing much code > with (the rest of) FFmpeg down the line. Iam not sure iam drifting off topic maybe but I frequently use code from libavutil outside multimedia thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The misfortune of the wise is better than the prosperity of the fool. -- Epicurus 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 Fri, Jun 23, 2023 at 8:12 PM Michael Niedermayer wrote: > 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 < > mich...@niedermayer.cc> 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". > * No software i tried or was suggested to me used V4L or Linux-DVB. > * iam not sure the RSP1A i have has linux drivers for these interfaces > * What iam interrested in was working with the signals at a low level, why > because i find it interresting and fun. Accessing AM/FM through some high > level API is not something iam interrested in. This is also because any > issues are likely unsolvable at that level. > If probing didnt find a station, or demodulation doesnt work, a high > level API likely wont allow doing anything about that. > > > > > > So I can only agree with Kieran that these are *lower* layers, that > don't really look like they belong in FFmpeg. > > FFmpeg has been always very low level. We stoped at where the OS provides > support that works, not at some academic "level". If every OS provides a > great > SDR API than i missed that, which is possible because that was never > something > i was interrested in. > > > > > > >If the code grows beyond that it could be split out into a seperate > > >library outside FFmpeg. > > > > I think that the point is, that that code should be up-front in a > separate FFmpeg-independent library. And it's not just a technical argument > with layering. It's also that it's too far outside what FFmpeg typically > works with, so it really should not be put under the purview of > FFmpeg-devel. In other words, it's also a social problem. > > > > The flip side of that argument is that this may be of interest to other > higher-level projects than FFmpeg, including projects that (rightfully) > don't depend on FFmpeg, and that this may interest people who wouldn't > contribute or participate in FFmpeg. > > The issue i have with this view is it comes from people who want nothing to > do with this SDR work. > I would see this argument very differntly if it would come from people who > want to work on that external SDR library. > > I mean this is more a "go away" than a "lets work together on SDR (for > FFmpeg)" > > > > > > >The size of all of SDR really has as much bearing on FFmpeg as the size > > >of all of mathematics has on the use of mathematics in FFmpeg. > > > > On an empirical basis, I'd argue that FFmpeg mathematics are so > fine-tuned to specific algorithmic use cases, that you will anyway end up > writing custom algorithms and optimisations here. And thus you won't be > sharing much code with (the rest of) FFmpeg down the line. > > Iam not sure iam drifting off topic maybe but > I frequently use code from libavutil outside multimedia > > thx > > > If you are not willing to listen to reviews than you can not collaborate on FFmpeg project. I tried to tell you that using this code inside libavformat is mistake. But you keep ignoring that. [...] > -- > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > The misfortune of the wise is better than the prosperity of the fool. > -- Epicurus > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2] avformat: add Software Defined Radio support
On Fri, Jun 23, 2023 at 08:17:16PM +0200, Paul B Mahol wrote: > On Fri, Jun 23, 2023 at 8:12 PM Michael Niedermayer > wrote: > > > 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 < > > mich...@niedermayer.cc> 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". > > * No software i tried or was suggested to me used V4L or Linux-DVB. > > * iam not sure the RSP1A i have has linux drivers for these interfaces > > * What iam interrested in was working with the signals at a low level, why > > because i find it interresting and fun. Accessing AM/FM through some high > > level API is not something iam interrested in. This is also because any > > issues are likely unsolvable at that level. > > If probing didnt find a station, or demodulation doesnt work, a high > > level API likely wont allow doing anything about that. > > > > > > > > > > So I can only agree with Kieran that these are *lower* layers, that > > don't really look like they belong in FFmpeg. > > > > FFmpeg has been always very low level. We stoped at where the OS provides > > support that works, not at some academic "level". If every OS provides a > > great > > SDR API than i missed that, which is possible because that was never > > something > > i was interrested in. > > > > > > > > > > >If the code grows beyond that it could be split out into a seperate > > > >library outside FFmpeg. > > > > > > I think that the point is, that that code should be up-front in a > > separate FFmpeg-independent library. And it's not just a technical argument > > with layering. It's also that it's too far outside what FFmpeg typically > > works with, so it really should not be put under the purview of > > FFmpeg-devel. In other words, it's also a social problem. > > > > > > The flip side of that argument is that this may be of interest to other > > higher-level projects than FFmpeg, including projects that (rightfully) > > don't depend on FFmpeg, and that this may interest people who wouldn't > > contribute or participate in FFmpeg. > > > > The issue i have with this view is it comes from people who want nothing to > > do with this SDR work. > > I would see this argument very differntly if it would come from people who > > want to work on that external SDR library. > > > > I mean this is more a "go away" than a "lets work together on SDR (for > > FFmpeg)" > > > > > > > > > > >The size of all of SDR really has as much bearing on FFmpeg as the size > > > >of all of mathematics has on the use of mathematics in FFmpeg. > > > > > > On an empirical basis, I'd argue that FFmpeg mathematics are so > > fine-tuned to specific algorithmic use cases, that you will anyway end up > > writing custom algorithms and optimisations here. And thus you won't be > > sharing much code with (the rest of) FFmpeg down the line. > > > > Iam not sure iam drifting off topic maybe but > > I frequently use code from libavutil outside multimedia > > > > thx > > > > > > > If you are not willing to listen to reviews than you can not collaborate on > FFmpeg project. > > I tried to tell you that using this code inside libavformat is mistake. But > you keep ignoring that. You called me a liar. Which is unacceptable libavformat is open source code, anyone can add any feature that he wants. Iam in no way insisting to implement this in libavformat, but sofar its really the only place (even if the active code would be moved outside, its still interfacing in libavformat) Also iam not ignoring anyone. I just move forward and try to implement all suggestions that i can and that i agree with. Once thats done, we will look if we have a consensus what to do. That could be git master, it could be another place, it could include an external lib IF others want to work on this lib too. Maybe someone has an entirly different suggestion that we all prefer, i dont know. We will see But ATM i find this sdr stuff a bit interresting and so i will continu
Re: [FFmpeg-devel] [PATCH v2] avformat: add Software Defined Radio support
On Fri, Jun 23, 2023 at 8:56 PM Michael Niedermayer wrote: > On Fri, Jun 23, 2023 at 08:17:16PM +0200, Paul B Mahol wrote: > > On Fri, Jun 23, 2023 at 8:12 PM Michael Niedermayer < > mich...@niedermayer.cc> > > wrote: > > > > > 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 < > > > mich...@niedermayer.cc> 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". > > > * No software i tried or was suggested to me used V4L or Linux-DVB. > > > * iam not sure the RSP1A i have has linux drivers for these interfaces > > > * What iam interrested in was working with the signals at a low level, > why > > > because i find it interresting and fun. Accessing AM/FM through some > high > > > level API is not something iam interrested in. This is also because > any > > > issues are likely unsolvable at that level. > > > If probing didnt find a station, or demodulation doesnt work, a high > > > level API likely wont allow doing anything about that. > > > > > > > > > > > > > > So I can only agree with Kieran that these are *lower* layers, that > > > don't really look like they belong in FFmpeg. > > > > > > FFmpeg has been always very low level. We stoped at where the OS > provides > > > support that works, not at some academic "level". If every OS provides > a > > > great > > > SDR API than i missed that, which is possible because that was never > > > something > > > i was interrested in. > > > > > > > > > > > > > > >If the code grows beyond that it could be split out into a seperate > > > > >library outside FFmpeg. > > > > > > > > I think that the point is, that that code should be up-front in a > > > separate FFmpeg-independent library. And it's not just a technical > argument > > > with layering. It's also that it's too far outside what FFmpeg > typically > > > works with, so it really should not be put under the purview of > > > FFmpeg-devel. In other words, it's also a social problem. > > > > > > > > The flip side of that argument is that this may be of interest to > other > > > higher-level projects than FFmpeg, including projects that (rightfully) > > > don't depend on FFmpeg, and that this may interest people who wouldn't > > > contribute or participate in FFmpeg. > > > > > > The issue i have with this view is it comes from people who want > nothing to > > > do with this SDR work. > > > I would see this argument very differntly if it would come from people > who > > > want to work on that external SDR library. > > > > > > I mean this is more a "go away" than a "lets work together on SDR (for > > > FFmpeg)" > > > > > > > > > > > > > > >The size of all of SDR really has as much bearing on FFmpeg as the > size > > > > >of all of mathematics has on the use of mathematics in FFmpeg. > > > > > > > > On an empirical basis, I'd argue that FFmpeg mathematics are so > > > fine-tuned to specific algorithmic use cases, that you will anyway end > up > > > writing custom algorithms and optimisations here. And thus you won't be > > > sharing much code with (the rest of) FFmpeg down the line. > > > > > > Iam not sure iam drifting off topic maybe but > > > I frequently use code from libavutil outside multimedia > > > > > > thx > > > > > > > > > > > If you are not willing to listen to reviews than you can not collaborate > on > > FFmpeg project. > > > > > I tried to tell you that using this code inside libavformat is mistake. > But > > you keep ignoring that. > > You called me a liar. Which is unacceptable > > > libavformat is open source code, anyone can add any feature that he wants. > Iam in no way insisting to implement this in libavformat, but sofar its > really the only place (even if the active code would be moved outside, its > still interfacing in libavformat) > > Also iam not ignoring anyone. I just move forward and try to implement all > suggestions that i can and that i agree with. Once thats don
Re: [FFmpeg-devel] [PATCH v2] avformat: add Software Defined Radio support
On 6/23/2023 4:10 PM, Paul B Mahol wrote: On Fri, Jun 23, 2023 at 8:56 PM Michael Niedermayer wrote: On Fri, Jun 23, 2023 at 08:17:16PM +0200, Paul B Mahol wrote: On Fri, Jun 23, 2023 at 8:12 PM Michael Niedermayer < mich...@niedermayer.cc> wrote: 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 < mich...@niedermayer.cc> 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". * No software i tried or was suggested to me used V4L or Linux-DVB. * iam not sure the RSP1A i have has linux drivers for these interfaces * What iam interrested in was working with the signals at a low level, why because i find it interresting and fun. Accessing AM/FM through some high level API is not something iam interrested in. This is also because any issues are likely unsolvable at that level. If probing didnt find a station, or demodulation doesnt work, a high level API likely wont allow doing anything about that. So I can only agree with Kieran that these are *lower* layers, that don't really look like they belong in FFmpeg. FFmpeg has been always very low level. We stoped at where the OS provides support that works, not at some academic "level". If every OS provides a great SDR API than i missed that, which is possible because that was never something i was interrested in. If the code grows beyond that it could be split out into a seperate library outside FFmpeg. I think that the point is, that that code should be up-front in a separate FFmpeg-independent library. And it's not just a technical argument with layering. It's also that it's too far outside what FFmpeg typically works with, so it really should not be put under the purview of FFmpeg-devel. In other words, it's also a social problem. The flip side of that argument is that this may be of interest to other higher-level projects than FFmpeg, including projects that (rightfully) don't depend on FFmpeg, and that this may interest people who wouldn't contribute or participate in FFmpeg. The issue i have with this view is it comes from people who want nothing to do with this SDR work. I would see this argument very differntly if it would come from people who want to work on that external SDR library. I mean this is more a "go away" than a "lets work together on SDR (for FFmpeg)" The size of all of SDR really has as much bearing on FFmpeg as the size of all of mathematics has on the use of mathematics in FFmpeg. On an empirical basis, I'd argue that FFmpeg mathematics are so fine-tuned to specific algorithmic use cases, that you will anyway end up writing custom algorithms and optimisations here. And thus you won't be sharing much code with (the rest of) FFmpeg down the line. Iam not sure iam drifting off topic maybe but I frequently use code from libavutil outside multimedia thx If you are not willing to listen to reviews than you can not collaborate on FFmpeg project. I tried to tell you that using this code inside libavformat is mistake. But you keep ignoring that. You called me a liar. Which is unacceptable libavformat is open source code, anyone can add any feature that he wants. Iam in no way insisting to implement this in libavformat, but sofar its really the only place (even if the active code would be moved outside, its still interfacing in libavformat) Also iam not ignoring anyone. I just move forward and try to implement all suggestions that i can and that i agree with. Once thats done, we will look if we have a consensus what to do. That could be git master, it could be another place, it could include an external lib IF others want to work on this lib too. Maybe someone has an entirly different suggestion that we all prefer, i dont know. We will see But ATM i find this sdr stuff a bit interresting and so i will continue to work on it. If me working on free software offends anyone, iam not sure what to say. Yes your patches, not just this one, offend all of us: 1. breaks existing functionality and introduces subtle bugs 2. ignoring fixing various bugs and regressions re
Re: [FFmpeg-devel] [PATCH v2] avformat: add Software Defined Radio support
No. Absolutely not. Radio stuff belongs in radio projects such as GNU Radio. This is extreme scope creep. I can throw an AM detector together in 15 minutes. That doesn't mean it belongs in FFmpeg. You are also treading into modem territory, among other things. Please contribute to actually existing free radio projects instead. /Tomas ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC] SDR
tor 2023-06-22 klockan 16:57 +0200 skrev Michael Niedermayer: > If we support just audio and video (de)modulation it fits nicely in FFmpeg You have no idea what you are getting into. Are we going to implement a DVB-T demuxer in this project? For what purpose? You can just as well implement a modem externally that pipes bits into the mpegts demuxer. /Tomas ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC] SDR
fre 2023-06-23 klockan 22:18 +0200 skrev Tomas Härdin: > tor 2023-06-22 klockan 16:57 +0200 skrev Michael Niedermayer: > > If we support just audio and video (de)modulation it fits nicely in > > FFmpeg > > You have no idea what you are getting into. Are we going to implement > a > DVB-T demuxer in this project? For what purpose? You can just as well > implement a modem externally that pipes bits into the mpegts demuxer. Herp, I obviously mean a DVB-T *modem* /Tomas ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2] avformat: add Software Defined Radio support
Hi Tomas On Fri, Jun 23, 2023 at 10:10:29PM +0200, Tomas Härdin wrote: > No. Absolutely not. > > Radio stuff belongs in radio projects such as GNU Radio. This is > extreme scope creep. > > I can throw an AM detector together in 15 minutes. That doesn't mean it > belongs in FFmpeg. You are also treading into modem territory, among > other things. Please contribute to actually existing free radio > projects instead. And DSP belongs in DSP projects, mpeg decoding belongs in libmpeg2 png, ogg, vorbis belong in their respective projects in fact FFmpeg shouldnt exist we should all have been contributing to gstreamer Wouldnt that be the same line of thought ? But seriously there are 2 things. Theres myself and what is fun for me to work on (you suggest i shouldnt have fun?) And there is FFmpeg that is missing any and all SDR support Are you planing to add SDR support through some library like GNU radio to FFmpeg ? 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, also GNU Radio is not LGPL, i think FFmpeg generally prefers LGPL over GPL. 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 ? 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] [RFC] SDR
On Fri, Jun 23, 2023 at 10:19:37PM +0200, Tomas Härdin wrote: > fre 2023-06-23 klockan 22:18 +0200 skrev Tomas Härdin: > > tor 2023-06-22 klockan 16:57 +0200 skrev Michael Niedermayer: > > > If we support just audio and video (de)modulation it fits nicely in > > > FFmpeg > > > > You have no idea what you are getting into. Are we going to implement > > a > > DVB-T demuxer in this project? For what purpose? You can just as well > > implement a modem externally that pipes bits into the mpegts demuxer. > > Herp, I obviously mean a DVB-T *modem* as said previously i did a AM demodulator, one classical implementation and one that demodulates it synchronously mapping in phase and quadrature to mid and side channels or just mono The idea of the mid and side channels is that if theres 1 transmitter its mono, if there are 2 transmitters they will appear to come from different directions as one listens And i plan to do FM demodulation. after that i likely have many other non SDR things i want to work on and would very much be happy to then find someone else working on DAB/DVB but if noone does and i find time i might look at DAB because the existing DAB software thats on my ubuntu box works very poorly with the hw i had in fact it even has difficulty finding the frequency of the DAB signal alot of the time. (which is ridiculous) I have not looked at DVB at all so i cannot comment. if its a mess, the question is in what way it is a mess. FFmpeg should have DVB support in some form. whatever external or internal bits that would use. It should be supported. GNU radio, a different lib, libavradio, a demuxer, a filter in a future avfilter API whatever but it should be supported in some form thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB No snowflake in an avalanche ever feels responsible. -- Voltaire 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] configure: use just the pkg-config for sndio
ping.
On 2023-06-17 6:48 p.m., Brad Smith wrote:
On Sun, Jun 18, 2023 at 12:01:14AM +0200, Michael Niedermayer wrote:
this breaks a plain configure
here on ubuntu
./configure
ERROR: sndio not found using pkg-config
If you think configure made a mistake, make sure you are using the latest
version from Git. If the latest version fails, report the problem to the
ffmpeg-u...@ffmpeg.org mailing list or IRC #ffmpeg on irc.libera.chat.
Include the log file "ffbuild/config.log" produced by configure as this will
help
solve the problem.
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
The misfortune of the wise is better than the prosperity of the fool.
-- Epicurus
This is what I had intended.
---
configure | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/configure b/configure
index 0c77d8e1fe..2069bf8a37 100755
--- a/configure
+++ b/configure
@@ -7009,8 +7009,7 @@ enabled alsa && { check_pkg_config alsa alsa
"alsa/asoundlib.h" snd_pcm_htimesta
enabled libjack &&
require_pkg_config libjack jack jack/jack.h jack_port_get_latency_range
-enabled sndio && { check_pkg_config sndio sndio "sndio.h" sio_open ||
- check_lib sndio sndio.h sio_open -lsndio; }
+enabled sndio && check_pkg_config sndio sndio sndio.h sio_open
if enabled libcdio; then
check_pkg_config libcdio libcdio_paranoia "cdio/cdda.h cdio/paranoia.h"
cdio_cddap_open ||
___
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] configure: use just the pkg-config for sndio
On Fri, Jun 23, 2023 at 06:41:08PM -0400, Brad Smith wrote: > ping. > > On 2023-06-17 6:48 p.m., Brad Smith wrote: > > On Sun, Jun 18, 2023 at 12:01:14AM +0200, Michael Niedermayer wrote: > > > this breaks a plain configure > > > here on ubuntu > > > > > > ./configure > > > ERROR: sndio not found using pkg-config > > > > > > If you think configure made a mistake, make sure you are using the latest > > > version from Git. If the latest version fails, report the problem to the > > > ffmpeg-u...@ffmpeg.org mailing list or IRC #ffmpeg on irc.libera.chat. > > > Include the log file "ffbuild/config.log" produced by configure as this > > > will help > > > solve the problem. > > > > > > > > > > > > [...] > > > -- > > > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > > > > > The misfortune of the wise is better than the prosperity of the fool. > > > -- Epicurus > > > > This is what I had intended. You intended to break a plain ./configure on ubuntu ? If so i think we better dont apply that patch :) thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB No great genius has ever existed without some touch of madness. -- Aristotle signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] configure: use just the pkg-config for sndio
On 2023-06-23 6:55 p.m., Michael Niedermayer wrote: On Fri, Jun 23, 2023 at 06:41:08PM -0400, Brad Smith wrote: ping. On 2023-06-17 6:48 p.m., Brad Smith wrote: On Sun, Jun 18, 2023 at 12:01:14AM +0200, Michael Niedermayer wrote: this breaks a plain configure here on ubuntu ./configure ERROR: sndio not found using pkg-config If you think configure made a mistake, make sure you are using the latest version from Git. If the latest version fails, report the problem to the ffmpeg-u...@ffmpeg.org mailing list or IRC #ffmpeg on irc.libera.chat. Include the log file "ffbuild/config.log" produced by configure as this will help solve the problem. [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The misfortune of the wise is better than the prosperity of the fool. -- Epicurus This is what I had intended. You intended to break a plain ./configure on ubuntu ? If so i think we better dont apply that patch :) thx No, there was a second patch there. ___ 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] configure: use just the pkg-config for sndio
On 6/23/2023 7:55 PM, Michael Niedermayer wrote: On Fri, Jun 23, 2023 at 06:41:08PM -0400, Brad Smith wrote: ping. On 2023-06-17 6:48 p.m., Brad Smith wrote: On Sun, Jun 18, 2023 at 12:01:14AM +0200, Michael Niedermayer wrote: this breaks a plain configure here on ubuntu ./configure ERROR: sndio not found using pkg-config If you think configure made a mistake, make sure you are using the latest version from Git. If the latest version fails, report the problem to the ffmpeg-u...@ffmpeg.org mailing list or IRC #ffmpeg on irc.libera.chat. Include the log file "ffbuild/config.log" produced by configure as this will help solve the problem. [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The misfortune of the wise is better than the prosperity of the fool. -- Epicurus This is what I had intended. You intended to break a plain ./configure on ubuntu ? If so i think we better dont apply that patch :) thx He means the updated version he pasted right below that line. ___ 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] configure: use just the pkg-config for sndio
On Fri, Jun 23, 2023 at 06:56:30PM -0400, Brad Smith wrote: > On 2023-06-23 6:55 p.m., Michael Niedermayer wrote: > > On Fri, Jun 23, 2023 at 06:41:08PM -0400, Brad Smith wrote: > > > ping. > > > > > > On 2023-06-17 6:48 p.m., Brad Smith wrote: > > > > On Sun, Jun 18, 2023 at 12:01:14AM +0200, Michael Niedermayer wrote: > > > > > this breaks a plain configure > > > > > here on ubuntu > > > > > > > > > > ./configure > > > > > ERROR: sndio not found using pkg-config > > > > > > > > > > If you think configure made a mistake, make sure you are using the > > > > > latest > > > > > version from Git. If the latest version fails, report the problem to > > > > > the > > > > > ffmpeg-u...@ffmpeg.org mailing list or IRC #ffmpeg on irc.libera.chat. > > > > > Include the log file "ffbuild/config.log" produced by configure as > > > > > this will help > > > > > solve the problem. > > > > > > > > > > > > > > > > > > > > [...] > > > > > -- > > > > > Michael GnuPG fingerprint: > > > > > 9FF2128B147EF6730BADF133611EC787040B0FAB > > > > > > > > > > The misfortune of the wise is better than the prosperity of the fool. > > > > > -- Epicurus > > > > This is what I had intended. > > You intended to break a plain ./configure on ubuntu ? > > If so i think we better dont apply that patch :) > > > > thx > > No, there was a second patch there. oops i missed that, the 2nd patch works fine on ubuntu no objections from me thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB There will always be a question for which you do not know the correct answer. 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] configure: use just the pkg-config for sndio
On 2023-06-23 7:35 p.m., Michael Niedermayer wrote: On Fri, Jun 23, 2023 at 06:56:30PM -0400, Brad Smith wrote: On 2023-06-23 6:55 p.m., Michael Niedermayer wrote: On Fri, Jun 23, 2023 at 06:41:08PM -0400, Brad Smith wrote: ping. On 2023-06-17 6:48 p.m., Brad Smith wrote: On Sun, Jun 18, 2023 at 12:01:14AM +0200, Michael Niedermayer wrote: this breaks a plain configure here on ubuntu ./configure ERROR: sndio not found using pkg-config If you think configure made a mistake, make sure you are using the latest version from Git. If the latest version fails, report the problem to the ffmpeg-u...@ffmpeg.org mailing list or IRC #ffmpeg on irc.libera.chat. Include the log file "ffbuild/config.log" produced by configure as this will help solve the problem. [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The misfortune of the wise is better than the prosperity of the fool. -- Epicurus This is what I had intended. You intended to break a plain ./configure on ubuntu ? If so i think we better dont apply that patch :) thx No, there was a second patch there. oops i missed that, the 2nd patch works fine on ubuntu no objections from me thx 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 6/6] doc/developer: Require new modules to include tests
On Sun, Jun 18, 2023 at 11:50:21PM +0200, Michael Niedermayer wrote: > Signed-off-by: Michael Niedermayer > --- > doc/developer.texi | 5 - > 1 file changed, 4 insertions(+), 1 deletion(-) will apply [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Rewriting code that is poorly written but fully understood is good. Rewriting code that one doesnt understand is a sign that one is less smart than the original author, trying to rewrite it will not make it better. 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 v3 0/4] JPEG XL Parser addition
Changes from v2:
- Fix libjxldec to work with packets that are smaller than one frame
- Change how code is shared between libavcodec and libavformat to be more
sensible.
- Fix the parser to work with large headers that proceed the codestream in a
container format
(for example, if several-KB Exif boxes preceed the codestream.)
- Modify the parser to set width/height instead of avctx
Note: avctx->pix_fmt and s->format are both set, because otherwise the CLI
tools won't print
the pixel format without libjxl enabled.
- Update the fate test based on the new parser's packetization
This test relies on FATE samples that haven't been uploaded yet. To test, unzip
the following zipfile[1] in the FATE_SAMPLES directory, placing the test images
in jxl/.
[1]: https://buzo.us/y.zip
sha256sum: 43a2eeb0dfdf471b47a9fdfb1653974fa156ceceb776891cc137569a8ebf0e75
signature: https://buzo.us/R.asc
Leo Izen (4):
avcodec/libjxldec: use internal AVFrame as buffered space
avcodec/jpegxl_parser: add JPEG XL parser
avformat/jpegxl: remove jpegxl_probe, instead call
avcodec/jpegxl_parse
fate/jpegxl_anim: add demuxer fate test for jpegxl_anim
libavcodec/Makefile | 1 +
libavcodec/jpegxl.h | 72 ++
.../jpegxl_parse.c| 219 --
libavcodec/jpegxl_parse.h | 63 +
libavcodec/jpegxl_parser.c| 182 +++
libavcodec/libjxldec.c| 40 ++--
libavcodec/parsers.c | 1 +
libavcodec/version.h | 2 +-
libavformat/Makefile | 5 +-
libavformat/img2dec.c | 4 +-
libavformat/jpegxl_anim_dec.c | 114 ++---
.../{jpegxl_probe.h => jpegxl_parse.c}| 21 +-
tests/Makefile| 1 +
tests/fate/jxl.mak| 16 ++
tests/ref/fate/jxl-anim-demux-belgium | 6 +
tests/ref/fate/jxl-anim-demux-icos4d | 6 +
tests/ref/fate/jxl-anim-demux-lenna256| 7 +
tests/ref/fate/jxl-anim-demux-newton | 6 +
18 files changed, 564 insertions(+), 202 deletions(-)
create mode 100644 libavcodec/jpegxl.h
rename libavformat/jpegxl_probe.c => libavcodec/jpegxl_parse.c (65%)
create mode 100644 libavcodec/jpegxl_parse.h
create mode 100644 libavcodec/jpegxl_parser.c
rename libavformat/{jpegxl_probe.h => jpegxl_parse.c} (55%)
create mode 100644 tests/fate/jxl.mak
create mode 100644 tests/ref/fate/jxl-anim-demux-belgium
create mode 100644 tests/ref/fate/jxl-anim-demux-icos4d
create mode 100644 tests/ref/fate/jxl-anim-demux-lenna256
create mode 100644 tests/ref/fate/jxl-anim-demux-newton
--
2.41.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v3 1/4] avcodec/libjxldec: use internal AVFrame as buffered space
Before this commit, the decoder erroneously assumes that the AVFrame
passed to the receive_frame is the same one each time. Now it keeps an
internal AVFrame to write into, and copies it over when it's done.
---
libavcodec/libjxldec.c | 40 +++-
1 file changed, 23 insertions(+), 17 deletions(-)
diff --git a/libavcodec/libjxldec.c b/libavcodec/libjxldec.c
index 50417bcb02..cea7ea0d3b 100644
--- a/libavcodec/libjxldec.c
+++ b/libavcodec/libjxldec.c
@@ -58,6 +58,7 @@ typedef struct LibJxlDecodeContext {
int64_t frame_duration;
int prev_is_last;
AVRational timebase;
+AVFrame *frame;
} LibJxlDecodeContext;
static int libjxl_init_jxl_decoder(AVCodecContext *avctx)
@@ -104,6 +105,9 @@ static av_cold int libjxl_decode_init(AVCodecContext *avctx)
ctx->avpkt = avctx->internal->in_pkt;
ctx->pts = 0;
+ctx->frame = av_frame_alloc();
+if (!ctx->frame)
+return AVERROR(ENOMEM);
return libjxl_init_jxl_decoder(avctx);
}
@@ -351,10 +355,12 @@ static int libjxl_receive_frame(AVCodecContext *avctx,
AVFrame *frame)
size_t remaining;
if (!pkt->size) {
+av_log(avctx, AV_LOG_DEBUG, "Fetching new packet\n");
av_packet_unref(pkt);
ret = ff_decode_get_packet(avctx, pkt);
if (ret < 0 && ret != AVERROR_EOF)
return ret;
+av_log(avctx, AV_LOG_DEBUG, "Fetched packet of size: %d\n",
pkt->size);
if (!pkt->size) {
/* jret set by the last iteration of the loop */
if (jret == JXL_DEC_NEED_MORE_INPUT) {
@@ -389,10 +395,6 @@ static int libjxl_receive_frame(AVCodecContext *avctx,
AVFrame *frame)
return AVERROR_INVALIDDATA;
case JXL_DEC_NEED_MORE_INPUT:
av_log(avctx, AV_LOG_DEBUG, "NEED_MORE_INPUT event emitted\n");
-if (!pkt->size) {
-av_packet_unref(pkt);
-return AVERROR(EAGAIN);
-}
continue;
case JXL_DEC_BASIC_INFO:
av_log(avctx, AV_LOG_DEBUG, "BASIC_INFO event emitted\n");
@@ -421,16 +423,18 @@ static int libjxl_receive_frame(AVCodecContext *avctx,
AVFrame *frame)
continue;
case JXL_DEC_COLOR_ENCODING:
av_log(avctx, AV_LOG_DEBUG, "COLOR_ENCODING event emitted\n");
-if ((ret = libjxl_color_encoding_event(avctx, frame)) < 0)
+if ((ret = libjxl_color_encoding_event(avctx, ctx->frame)) < 0)
return ret;
continue;
case JXL_DEC_NEED_IMAGE_OUT_BUFFER:
av_log(avctx, AV_LOG_DEBUG, "NEED_IMAGE_OUT_BUFFER event
emitted\n");
-if ((ret = ff_get_buffer(avctx, frame, 0)) < 0)
+ret = ff_get_buffer(avctx, ctx->frame, 0);
+if (ret < 0)
return ret;
-ctx->jxl_pixfmt.align = frame->linesize[0];
-if (JxlDecoderSetImageOutBuffer(ctx->decoder, &ctx->jxl_pixfmt,
frame->data[0], frame->buf[0]->size)
-!= JXL_DEC_SUCCESS) {
+ctx->jxl_pixfmt.align = ctx->frame->linesize[0];
+if (JxlDecoderSetImageOutBuffer(ctx->decoder, &ctx->jxl_pixfmt,
+ctx->frame->data[0], ctx->frame->buf[0]->size)
+!= JXL_DEC_SUCCESS) {
av_log(avctx, AV_LOG_ERROR, "Bad libjxl dec need image out
buffer event\n");
return AVERROR_EXTERNAL;
}
@@ -444,8 +448,8 @@ static int libjxl_receive_frame(AVCodecContext *avctx,
AVFrame *frame)
case JXL_DEC_FRAME:
av_log(avctx, AV_LOG_DEBUG, "FRAME event emitted\n");
if (!ctx->basic_info.have_animation || ctx->prev_is_last) {
-frame->pict_type = AV_PICTURE_TYPE_I;
-frame->flags |= AV_FRAME_FLAG_KEY;
+ctx->frame->pict_type = AV_PICTURE_TYPE_I;
+ctx->frame->flags |= AV_FRAME_FLAG_KEY;
}
if (ctx->basic_info.have_animation) {
JxlFrameHeader header;
@@ -464,20 +468,21 @@ static int libjxl_receive_frame(AVCodecContext *avctx,
AVFrame *frame)
/* full image is one frame, even if animated */
av_log(avctx, AV_LOG_DEBUG, "FULL_IMAGE event emitted\n");
if (ctx->iccp) {
-AVFrameSideData *sd = av_frame_new_side_data_from_buf(frame,
AV_FRAME_DATA_ICC_PROFILE, ctx->iccp);
+AVFrameSideData *sd =
av_frame_new_side_data_from_buf(ctx->frame, AV_FRAME_DATA_ICC_PROFILE,
ctx->iccp);
if (!sd)
return AVERROR(ENOMEM);
/* ownership is transfered, and it is not ref-ed */
ctx->iccp = NULL;
}
if (avctx->pkt_timebase.num) {
-frame->pts = av_rescale_q(ctx->pts, ctx->timebase,
avctx->pkt_timebase);
-frame->duration = av_rescale_q(ctx->frame_duration,
ctx->timebase, avctx->pkt_time
[FFmpeg-devel] [PATCH v3 2/4] avcodec/jpegxl_parser: add JPEG XL parser
Add a parser to libavcodec for AV_CODEC_ID_JPEGXL. It doesn't find the
end of the stream in order to packetize the codec, but it does look at
the headers to set preliminary information like dimensions and pixel
format.
Note that much of this code is duplicated from avformat/jpegxl_probe.c,
but that code will be removed and call this instead in the next commit.
Signed-off-by:
---
libavcodec/Makefile| 1 +
libavcodec/jpegxl.h| 72 ++
libavcodec/jpegxl_parse.c | 495 +
libavcodec/jpegxl_parse.h | 63 +
libavcodec/jpegxl_parser.c | 182 ++
libavcodec/parsers.c | 1 +
libavcodec/version.h | 2 +-
7 files changed, 815 insertions(+), 1 deletion(-)
create mode 100644 libavcodec/jpegxl.h
create mode 100644 libavcodec/jpegxl_parse.c
create mode 100644 libavcodec/jpegxl_parse.h
create mode 100644 libavcodec/jpegxl_parser.c
diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index 0e4d27f37b..683373919a 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -1184,6 +1184,7 @@ OBJS-$(CONFIG_HEVC_PARSER) += hevc_parser.o
hevc_data.o
OBJS-$(CONFIG_HDR_PARSER) += hdr_parser.o
OBJS-$(CONFIG_IPU_PARSER) += ipu_parser.o
OBJS-$(CONFIG_JPEG2000_PARSER) += jpeg2000_parser.o
+OBJS-$(CONFIG_JPEGXL_PARSER) += jpegxl_parser.o jpegxl_parse.o
OBJS-$(CONFIG_MISC4_PARSER)+= misc4_parser.o
OBJS-$(CONFIG_MJPEG_PARSER)+= mjpeg_parser.o
OBJS-$(CONFIG_MLP_PARSER) += mlp_parse.o mlp_parser.o mlp.o
diff --git a/libavcodec/jpegxl.h b/libavcodec/jpegxl.h
new file mode 100644
index 00..d6faf1a8bd
--- /dev/null
+++ b/libavcodec/jpegxl.h
@@ -0,0 +1,72 @@
+/*
+ * JPEG XL Common Header Definitions
+ * Copyright (c) 2023 Leo Izen
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#ifndef AVCODEC_JPEGXL_H
+#define AVCODEC_JPEGXL_H
+
+#define FF_JPEGXL_CODESTREAM_SIGNATURE_LE 0x0aff
+#define FF_JPEGXL_CONTAINER_SIGNATURE_LE 0x204c584a0c00
+
+typedef enum FFJXLExtraChannelType {
+JPEGXL_CT_ALPHA = 0,
+JPEGXL_CT_DEPTH,
+JPEGXL_CT_SPOT_COLOR,
+JPEGXL_CT_SELECTION_MASK,
+JPEGXL_CT_BLACK,
+JPEGXL_CT_CFA,
+JPEGXL_CT_THERMAL,
+JPEGXL_CT_NON_OPTIONAL = 15,
+JPEGXL_CT_OPTIONAL
+} FFJXLExtraChannelType;
+
+typedef enum FFJXLColorSpace {
+JPEGXL_CS_RGB = 0,
+JPEGXL_CS_GRAY,
+JPEGXL_CS_XYB,
+JPEGXL_CS_UNKNOWN
+} FFJXLColorSpace;
+
+typedef enum FFJXLWhitePoint {
+JPEGXL_WP_D65 = 1,
+JPEGXL_WP_CUSTOM,
+JPEGXL_WP_E = 10,
+JPEGXL_WP_DCI = 11
+} FFJXLWhitePoint;
+
+typedef enum FFJXLPrimaries {
+JPEGXL_PR_SRGB = 1,
+JPEGXL_PR_CUSTOM,
+JPEGXL_PR_2100 = 9,
+JPEGXL_PR_P3 = 11,
+} FFJXLPrimaries;
+
+typedef enum FFJXLTransferCharacteristic {
+JPEGXL_TR_BT709 = 1,
+JPEGXL_TR_UNKNOWN,
+JPEGXL_TR_LINEAR = 8,
+JPEGXL_TR_SRGB = 13,
+JPEGXL_TR_PQ = 16,
+JPEGXL_TR_DCI,
+JPEGXL_TR_HLG,
+JPEGXL_TR_GAMMA = 1 << 24,
+} FFJXLTransferCharacteristic;
+
+#endif /* AVCODEC_JPEGXL_H */
diff --git a/libavcodec/jpegxl_parse.c b/libavcodec/jpegxl_parse.c
new file mode 100644
index 00..023e6adf07
--- /dev/null
+++ b/libavcodec/jpegxl_parse.c
@@ -0,0 +1,495 @@
+/*
+ * JPEG XL Header Parser
+ * Copyright (c) 2023 Leo Izen
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include
+
+#include "bytestream.h"
+#define UNCHECKED_BITSTREAM_READER 0
+#define BITSTREAM_READER_LE
+#include "get_bits.h"
+#include "jpegxl.
[FFmpeg-devel] [PATCH v3 4/4] fate/jpegxl_anim: add demuxer fate test for jpegxl_anim
Adds a fate test for the jpegxl_anim demuxer, that should allow testing for true positives and false positives for animated jpegxl files. Note that two of the test cases are not animated, in order to help sort out false positives. Signed-off-by: --- tests/Makefile | 1 + tests/fate/jxl.mak | 16 tests/ref/fate/jxl-anim-demux-belgium | 6 ++ tests/ref/fate/jxl-anim-demux-icos4d | 6 ++ tests/ref/fate/jxl-anim-demux-lenna256 | 7 +++ tests/ref/fate/jxl-anim-demux-newton | 6 ++ 6 files changed, 42 insertions(+) create mode 100644 tests/fate/jxl.mak create mode 100644 tests/ref/fate/jxl-anim-demux-belgium create mode 100644 tests/ref/fate/jxl-anim-demux-icos4d create mode 100644 tests/ref/fate/jxl-anim-demux-lenna256 create mode 100644 tests/ref/fate/jxl-anim-demux-newton diff --git a/tests/Makefile b/tests/Makefile index e09f30a0fc..7b80762e81 100644 --- a/tests/Makefile +++ b/tests/Makefile @@ -201,6 +201,7 @@ include $(SRC_PATH)/tests/fate/image.mak include $(SRC_PATH)/tests/fate/imf.mak include $(SRC_PATH)/tests/fate/indeo.mak include $(SRC_PATH)/tests/fate/jpeg2000.mak +include $(SRC_PATH)/tests/fate/jxl.mak include $(SRC_PATH)/tests/fate/libavcodec.mak include $(SRC_PATH)/tests/fate/libavdevice.mak include $(SRC_PATH)/tests/fate/libavformat.mak diff --git a/tests/fate/jxl.mak b/tests/fate/jxl.mak new file mode 100644 index 00..057d3be0e1 --- /dev/null +++ b/tests/fate/jxl.mak @@ -0,0 +1,16 @@ +# These two are animated JXL files +FATE_JPEGXL_ANIM_DEMUX += fate-jxl-anim-demux-newton +fate-jxl-anim-demux-newton: CMD = framecrc -i $(TARGET_SAMPLES)/jxl/newton.jxl -c copy +FATE_JPEGXL_ANIM_DEMUX += fate-jxl-anim-demux-icos4d +fate-jxl-anim-demux-icos4d: CMD = framecrc -i $(TARGET_SAMPLES)/jxl/icos4d.jxl -c copy + +# These two are not animated JXL. They are here to check false positives. +FATE_JPEGXL_ANIM_DEMUX += fate-jxl-anim-demux-belgium +fate-jxl-anim-demux-belgium: CMD = framecrc -i $(TARGET_SAMPLES)/jxl/belgium.jxl -c copy +FATE_JPEGXL_ANIM_DEMUX += fate-jxl-anim-demux-lenna256 +fate-jxl-anim-demux-lenna256: CMD = framecrc -i $(TARGET_SAMPLES)/jxl/lenna-256.jxl -c copy + +FATE_JPEGXL_ANIM_DEMUX += $(FATE_JPEGXL_ANIM_DEMUX-yes) + +FATE_SAMPLES_FFMPEG-$(call FRAMECRC, JPEGXL_ANIM) += $(FATE_JPEGXL_ANIM_DEMUX) +fate-jxl-anim-demux: $(FATE_JPEGXL_ANIM_DEMUX) diff --git a/tests/ref/fate/jxl-anim-demux-belgium b/tests/ref/fate/jxl-anim-demux-belgium new file mode 100644 index 00..b2fe5035ac --- /dev/null +++ b/tests/ref/fate/jxl-anim-demux-belgium @@ -0,0 +1,6 @@ +#tb 0: 1/25 +#media_type 0: video +#codec_id 0: jpegxl +#dimensions 0: 768x512 +#sar 0: 0/1 +0, 0, 0,1, 32, 0xa2930a20 diff --git a/tests/ref/fate/jxl-anim-demux-icos4d b/tests/ref/fate/jxl-anim-demux-icos4d new file mode 100644 index 00..eff6ff1f1b --- /dev/null +++ b/tests/ref/fate/jxl-anim-demux-icos4d @@ -0,0 +1,6 @@ +#tb 0: 1/1000 +#media_type 0: video +#codec_id 0: jpegxl +#dimensions 0: 48x48 +#sar 0: 0/1 +0, 0, 0,0,67898, 0x53b6516b diff --git a/tests/ref/fate/jxl-anim-demux-lenna256 b/tests/ref/fate/jxl-anim-demux-lenna256 new file mode 100644 index 00..0bd286a451 --- /dev/null +++ b/tests/ref/fate/jxl-anim-demux-lenna256 @@ -0,0 +1,7 @@ +#tb 0: 1/25 +#media_type 0: video +#codec_id 0: jpegxl +#dimensions 0: 256x256 +#sar 0: 0/1 +0, 0, 0,1, 4096, 0x2409e9e3 +0, 1, 1,1, 3992, 0x966dbfcb diff --git a/tests/ref/fate/jxl-anim-demux-newton b/tests/ref/fate/jxl-anim-demux-newton new file mode 100644 index 00..6fcb85c41e --- /dev/null +++ b/tests/ref/fate/jxl-anim-demux-newton @@ -0,0 +1,6 @@ +#tb 0: 1/1000 +#media_type 0: video +#codec_id 0: jpegxl +#dimensions 0: 128x96 +#sar 0: 0/1 +0, 0, 0,0,43376, 0xb2296182 -- 2.41.0 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v3 3/4] avformat/jpegxl: remove jpegxl_probe, instead call avcodec/jpegxl_parse
This prevents code duplication in the source form by calling the parse
code that was moved to avcodec last commit. The code will be duplicated
in binary form for shared builds (it's not that large), but for source
code it will only exist in one location now.
Signed-off-by:
---
libavformat/Makefile | 5 +-
libavformat/img2dec.c | 4 +-
libavformat/jpegxl_anim_dec.c | 114 +
.../{jpegxl_probe.h => jpegxl_parse.c}| 21 +-
libavformat/jpegxl_probe.c| 412 --
5 files changed, 28 insertions(+), 528 deletions(-)
rename libavformat/{jpegxl_probe.h => jpegxl_parse.c} (55%)
delete mode 100644 libavformat/jpegxl_probe.c
diff --git a/libavformat/Makefile b/libavformat/Makefile
index 2b90b788c0..0637199c9d 100644
--- a/libavformat/Makefile
+++ b/libavformat/Makefile
@@ -283,7 +283,7 @@ OBJS-$(CONFIG_IMAGE_HDR_PIPE_DEMUXER) += img2dec.o
img2.o
OBJS-$(CONFIG_IMAGE_J2K_PIPE_DEMUXER) += img2dec.o img2.o
OBJS-$(CONFIG_IMAGE_JPEG_PIPE_DEMUXER)+= img2dec.o img2.o
OBJS-$(CONFIG_IMAGE_JPEGLS_PIPE_DEMUXER) += img2dec.o img2.o
-OBJS-$(CONFIG_IMAGE_JPEGXL_PIPE_DEMUXER) += img2dec.o img2.o jpegxl_probe.o
+OBJS-$(CONFIG_IMAGE_JPEGXL_PIPE_DEMUXER) += img2dec.o img2.o jpegxl_parse.o
OBJS-$(CONFIG_IMAGE_PAM_PIPE_DEMUXER) += img2dec.o img2.o
OBJS-$(CONFIG_IMAGE_PBM_PIPE_DEMUXER) += img2dec.o img2.o
OBJS-$(CONFIG_IMAGE_PCX_PIPE_DEMUXER) += img2dec.o img2.o
@@ -320,7 +320,7 @@ OBJS-$(CONFIG_IVF_MUXER) += ivfenc.o
OBJS-$(CONFIG_IVR_DEMUXER) += rmdec.o rm.o rmsipr.o
OBJS-$(CONFIG_JACOSUB_DEMUXER) += jacosubdec.o subtitles.o
OBJS-$(CONFIG_JACOSUB_MUXER) += jacosubenc.o rawenc.o
-OBJS-$(CONFIG_JPEGXL_ANIM_DEMUXER) += jpegxl_anim_dec.o jpegxl_probe.o
+OBJS-$(CONFIG_JPEGXL_ANIM_DEMUXER) += jpegxl_anim_dec.o jpegxl_parse.o
OBJS-$(CONFIG_JV_DEMUXER)+= jvdec.o
OBJS-$(CONFIG_KUX_DEMUXER) += flvdec.o
OBJS-$(CONFIG_KVAG_DEMUXER) += kvag.o
@@ -715,6 +715,7 @@ SHLIBOBJS+= log2_tab.o
to_upper4.o
SHLIBOBJS-$(CONFIG_ISO_MEDIA)+= mpegaudiotabs.o
SHLIBOBJS-$(CONFIG_FLV_MUXER)+= mpeg4audio_sample_rates.o
SHLIBOBJS-$(CONFIG_HLS_DEMUXER) += ac3_channel_layout_tab.o
+SHLIBOBJS-$(CONFIG_JPEGXL_ANIM_DEMUXER) += jpegxl_parse.o
SHLIBOBJS-$(CONFIG_MATROSKA_DEMUXER) += mpeg4audio_sample_rates.o
SHLIBOBJS-$(CONFIG_MOV_DEMUXER) += ac3_channel_layout_tab.o
SHLIBOBJS-$(CONFIG_MP3_MUXER)+= mpegaudiotabs.o
diff --git a/libavformat/img2dec.c b/libavformat/img2dec.c
index b986d3a502..72b2c76405 100644
--- a/libavformat/img2dec.c
+++ b/libavformat/img2dec.c
@@ -36,7 +36,7 @@
#include "avio_internal.h"
#include "internal.h"
#include "img2.h"
-#include "jpegxl_probe.h"
+#include "libavcodec/jpegxl_parse.h"
#include "libavcodec/mjpeg.h"
#include "libavcodec/vbn.h"
#include "libavcodec/xwd.h"
@@ -850,7 +850,7 @@ static int jpegxl_probe(const AVProbeData *p)
if (AV_RL16(b) != FF_JPEGXL_CODESTREAM_SIGNATURE_LE)
return 0;
#if CONFIG_IMAGE_JPEGXL_PIPE_DEMUXER
-if (ff_jpegxl_verify_codestream_header(p->buf, p->buf_size, 1) >= 0)
+if (ff_jpegxl_parse_codestream_header(p->buf, p->buf_size, 1, NULL) >= 0)
return AVPROBE_SCORE_MAX - 2;
#endif
return 0;
diff --git a/libavformat/jpegxl_anim_dec.c b/libavformat/jpegxl_anim_dec.c
index 956b56c1d8..b178b74ff0 100644
--- a/libavformat/jpegxl_anim_dec.c
+++ b/libavformat/jpegxl_anim_dec.c
@@ -28,96 +28,28 @@
#include
#include
-#include "libavcodec/bytestream.h"
-#define BITSTREAM_READER_LE
-#include "libavcodec/get_bits.h"
-
+#include "libavcodec/jpegxl.h"
+#include "libavcodec/jpegxl_parse.h"
#include "libavutil/intreadwrite.h"
#include "libavutil/opt.h"
#include "avformat.h"
#include "internal.h"
-#include "jpegxl_probe.h"
typedef struct JXLAnimDemuxContext {
AVBufferRef *initial;
} JXLAnimDemuxContext;
-/*
- * copies as much of the codestream into the buffer as possible
- * pass a shorter buflen to request less
- * returns the number of bytes consumed from input, may be greater than
input_len
- * if the input doesn't end on an ISOBMFF-box boundary
- */
-static int jpegxl_collect_codestream_header(const uint8_t *input_buffer, int
input_len,
-uint8_t *buffer, int buflen, int
*copied) {
-GetByteContext gb;
-*copied = 0;
-bytestream2_init(&gb, input_buffer, input_len);
-
-while (1) {
-uint64_t size;
-uint32_t tag;
-int head_size = 8;
-
-if (bytestream2_get_bytes_left(&gb) < 16)
-break;
-
-size = bytestream2_get_be32(&gb);
-if (size == 1) {
-size = bytestream2_get_be64(&gb);
-head_size = 16;
-}
-/* invalid ISOBMFF size */
-if (size && size <= head_size
