Re: [FFmpeg-devel] [PATCH 7/9] MAINTAINERS: Update the entries for the release maintainer for FFmpeg
Le 17 juin 2024 01:08:29 GMT+02:00, Michael Niedermayer a écrit : >Ive been told that someone at the BCN video tech meetup claimed to be the >"release maintainer for FFmpeg". I don't think that this is appropriate in a commit message that'll go on a blockchain never to be modifiable. >If you have any doubt who maintains releases, just do something like the >following and look at the output: Assuming that the allegations are true, the recipients of the misinformation won't see this message so no point. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 5/9] avformat/mov: Check extend and base offset
Le 17 juin 2024 01:08:27 GMT+02:00, Michael Niedermayer
a écrit :
>Fixes: signed integer overflow: 2314885530818453536 + 9151314442816847872
>cannot be represented in type 'long'
>Fixes:
>68359/clusterfuzz-testcase-minimized-ffmpeg_dem_MOV_fuzzer-6571950311800832
>
>Found-by: continuous fuzzing process
>https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
>Signed-off-by: Michael Niedermayer
>---
> libavformat/mov.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
>diff --git a/libavformat/mov.c b/libavformat/mov.c
>index 9016cd5ad08..46cbce98040 100644
>--- a/libavformat/mov.c
>+++ b/libavformat/mov.c
>@@ -8131,7 +8131,9 @@ static int mov_read_iloc(MOVContext *c, AVIOContext *pb,
>MOVAtom atom)
> }
> for (int j = 0; j < extent_count; j++) {
> if (rb_size(pb, &extent_offset, offset_size) < 0 ||
>-rb_size(pb, &extent_length, length_size) < 0)
>+rb_size(pb, &extent_length, length_size) < 0 ||
>+base_offset < 0 || extent_offset < 0 ||
>+base_offset + (uint64_t)extent_offset > INT64_MAX)
Can we please stop with the bespoke arithmetic overflow checks and add
dedicated helpers instead, similar to what GCC and C23 have?
> return AVERROR_INVALIDDATA;
> if (offset_type == 1)
> c->heif_item[i].is_idat_relative = 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 5/9] avformat/mov: Check extend and base offset
Rémi Denis-Courmont:
>
>
> Le 17 juin 2024 01:08:27 GMT+02:00, Michael Niedermayer
> a écrit :
>> Fixes: signed integer overflow: 2314885530818453536 + 9151314442816847872
>> cannot be represented in type 'long'
>> Fixes:
>> 68359/clusterfuzz-testcase-minimized-ffmpeg_dem_MOV_fuzzer-6571950311800832
>>
>> Found-by: continuous fuzzing process
>> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
>> Signed-off-by: Michael Niedermayer
>> ---
>> libavformat/mov.c | 4 +++-
>> 1 file changed, 3 insertions(+), 1 deletion(-)
>>
>> diff --git a/libavformat/mov.c b/libavformat/mov.c
>> index 9016cd5ad08..46cbce98040 100644
>> --- a/libavformat/mov.c
>> +++ b/libavformat/mov.c
>> @@ -8131,7 +8131,9 @@ static int mov_read_iloc(MOVContext *c, AVIOContext
>> *pb, MOVAtom atom)
>> }
>> for (int j = 0; j < extent_count; j++) {
>> if (rb_size(pb, &extent_offset, offset_size) < 0 ||
>> -rb_size(pb, &extent_length, length_size) < 0)
>> +rb_size(pb, &extent_length, length_size) < 0 ||
>> +base_offset < 0 || extent_offset < 0 ||
>> +base_offset + (uint64_t)extent_offset > INT64_MAX)
>
> Can we please stop with the bespoke arithmetic overflow checks and add
> dedicated helpers instead, similar to what GCC and C23 have?
>
+1
>> return AVERROR_INVALIDDATA;
>> if (offset_type == 1)
>> c->heif_item[i].is_idat_relative = 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 8/9] avcodec/smcenc: width < 4 is unsupported
Fixed by making nx/ny always >= 0. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 2/3] avfilter/af_volumedetect.c: Add 32bit float audio support
On Tue, Jun 18, 2024 at 8:56 AM Rémi Denis-Courmont wrote:
>
>
> Le 17 juin 2024 19:52:10 GMT+02:00, Paul B Mahol a
> écrit :
> >On Mon, Jun 17, 2024 at 4:52 PM Rémi Denis-Courmont
> wrote:
> >
> >>
> >>
> >> Le 17 juin 2024 13:18:11 GMT+02:00, Yigithan Yigit <
> >> yigithanyigitde...@gmail.com> a écrit :
> >> >---
> >> > libavfilter/af_volumedetect.c | 159 --
> >> > 1 file changed, 133 insertions(+), 26 deletions(-)
> >> >
> >> >diff --git a/libavfilter/af_volumedetect.c
> b/libavfilter/af_volumedetect.c
> >> >index 327801a7f9..dbbcd037a5 100644
> >> >--- a/libavfilter/af_volumedetect.c
> >> >+++ b/libavfilter/af_volumedetect.c
> >> >@@ -20,27 +20,51 @@
> >> >
> >> > #include "libavutil/channel_layout.h"
> >> > #include "libavutil/avassert.h"
> >> >+#include "libavutil/mem.h"
> >> > #include "audio.h"
> >> > #include "avfilter.h"
> >> > #include "internal.h"
> >> >
> >> >+#define MAX_DB_FLT 1024
> >> > #define MAX_DB 91
> >> >+#define HISTOGRAM_SIZE 0x1
> >> >+#define HISTOGRAM_SIZE_FLT (MAX_DB_FLT*2)
> >> >
> >> > typedef struct VolDetectContext {
> >> >-/**
> >> >- * Number of samples at each PCM value.
> >> >- * histogram[0x8000 + i] is the number of samples at value i.
> >> >- * The extra element is there for symmetry.
> >> >- */
> >> >-uint64_t histogram[0x10001];
> >> >+uint64_t* histogram; ///< for integer number of samples at each
> PCM
> >> value, for float number of samples at each dB
> >> >+uint64_t nb_samples; ///< number of samples
> >> >+double sum2; ///< sum of the squares of the samples
> >> >+double max; ///< maximum sample value
> >> >+int is_float;///< true if the input is in floating point
> >> > } VolDetectContext;
> >> >
> >> >-static inline double logdb(uint64_t v)
> >> >+static inline double logdb(double v, enum AVSampleFormat sample_fmt)
> >> > {
> >> >-double d = v / (double)(0x8000 * 0x8000);
> >> >-if (!v)
> >> >-return MAX_DB;
> >> >-return -log10(d) * 10;
> >> >+if (sample_fmt == AV_SAMPLE_FMT_FLT) {
> >> >+if (!v)
> >> >+return MAX_DB_FLT;
> >> >+return -log10(v) * 10;
> >> >+} else {
> >> >+double d = v / (double)(0x8000 * 0x8000);
> >> >+if (!v)
> >> >+return MAX_DB;
> >> >+return -log10(d) * 10;
> >> >+}
> >> >+}
> >> >+
> >> >+static void update_float_stats(VolDetectContext *vd, float
> *audio_data)
> >> >+{
> >> >+double sample;
> >> >+int idx;
> >> >+if(!isnormal(*audio_data))
> >> >+return;
> >>
> >> Do we really need to classify floats here? That's probably going to hurt
> >> perfs badly, and makes an otherwise very vectorisable function not so
> >> easily vectored.
> >>
> >
> >This is fast, it should translate to checking few bits of memory.
>
> Sure but the branch is what irks me here, not the classification per se.
> And I don't get why it's needed here, where most of the code base seems to
> assume that floats are always numeric. It's also not clear why subnormals
> are disallowed here.
>
HUGE floats get out of range easily, there is probably nicer way to add
them to some kind of "non-uniform non-linear" histogram.
>
> IMO all that needs justification in the commit message which I find
> lacking. Or if it's unjustified then it shouldn't be there.
>
> >> >+sample = fabsf(*audio_data);
> >> >+if (sample > vd->max)
> >> >+vd->max = sample;
> >> >+vd->sum2 += sample * sample;
> >> >+idx = lrintf(floorf(logdb(sample * sample, AV_SAMPLE_FMT_FLT))) +
> >> MAX_DB_FLT;
> >>
> >> You're recomputing the same value again, and you seem to be rounding
> twice
> >> in a row?
> ___
> 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] avutil/timestamp: avoid possible FPE when 0 is passed to av_ts_make_time_string2()
Le 17 juin 2024 22:33:01 GMT+02:00, Marton Balint a écrit :
>Signed-off-by: Marton Balint
>---
> libavutil/timestamp.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
>diff --git a/libavutil/timestamp.c b/libavutil/timestamp.c
>index 2a3e3012a4..6c231a517d 100644
>--- a/libavutil/timestamp.c
>+++ b/libavutil/timestamp.c
>@@ -24,7 +24,7 @@ char *av_ts_make_time_string2(char *buf, int64_t ts,
>AVRational tb)
> snprintf(buf, AV_TS_MAX_STRING_SIZE, "NOPTS");
> } else {
> double val = av_q2d(tb) * ts;
>-double log = floor(log10(fabs(val)));
>+double log = (fpclassify(val) == FP_ZERO ? -INFINITY :
>floor(log10(fabs(val;
> int precision = (isfinite(log) && log < 0) ? -log + 5 : 6;
Can the log be infinite anymore?
> int last = snprintf(buf, AV_TS_MAX_STRING_SIZE, "%.*f", precision,
> val);
> last = FFMIN(last, AV_TS_MAX_STRING_SIZE - 1) - 1;
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 2/3] avfilter/af_volumedetect.c: Add 32bit float audio support
> On Jun 17, 2024, at 5:52 PM, Rémi Denis-Courmont wrote:
>
>
>
> Le 17 juin 2024 13:18:11 GMT+02:00, Yigithan Yigit
> mailto:yigithanyigitde...@gmail.com>> a écrit :
>> ---
>> libavfilter/af_volumedetect.c | 159 --
>> 1 file changed, 133 insertions(+), 26 deletions(-)
>>
>> diff --git a/libavfilter/af_volumedetect.c b/libavfilter/af_volumedetect.c
>> index 327801a7f9..dbbcd037a5 100644
>> --- a/libavfilter/af_volumedetect.c
>> +++ b/libavfilter/af_volumedetect.c
>> @@ -20,27 +20,51 @@
>>
>> #include "libavutil/channel_layout.h"
>> #include "libavutil/avassert.h"
>> +#include "libavutil/mem.h"
>> #include "audio.h"
>> #include "avfilter.h"
>> #include "internal.h"
>>
>> +#define MAX_DB_FLT 1024
>> #define MAX_DB 91
>> +#define HISTOGRAM_SIZE 0x1
>> +#define HISTOGRAM_SIZE_FLT (MAX_DB_FLT*2)
>>
>> typedef struct VolDetectContext {
>> -/**
>> - * Number of samples at each PCM value.
>> - * histogram[0x8000 + i] is the number of samples at value i.
>> - * The extra element is there for symmetry.
>> - */
>> -uint64_t histogram[0x10001];
>> +uint64_t* histogram; ///< for integer number of samples at each PCM
>> value, for float number of samples at each dB
>> +uint64_t nb_samples; ///< number of samples
>> +double sum2; ///< sum of the squares of the samples
>> +double max; ///< maximum sample value
>> +int is_float;///< true if the input is in floating point
>> } VolDetectContext;
>>
>> -static inline double logdb(uint64_t v)
>> +static inline double logdb(double v, enum AVSampleFormat sample_fmt)
>> {
>> -double d = v / (double)(0x8000 * 0x8000);
>> -if (!v)
>> -return MAX_DB;
>> -return -log10(d) * 10;
>> +if (sample_fmt == AV_SAMPLE_FMT_FLT) {
>> +if (!v)
>> +return MAX_DB_FLT;
>> +return -log10(v) * 10;
>> +} else {
>> +double d = v / (double)(0x8000 * 0x8000);
>> +if (!v)
>> +return MAX_DB;
>> +return -log10(d) * 10;
>> +}
>> +}
>> +
>> +static void update_float_stats(VolDetectContext *vd, float *audio_data)
>> +{
>> +double sample;
>> +int idx;
>> +if(!isnormal(*audio_data))
>> +return;
>
> Do we really need to classify floats here? That's probably going to hurt
> perfs badly, and makes an otherwise very vectorisable function not so easily
> vectored.
You could be correct, we might consider checking NaN, Inf+/- values. Otherwise
there is a risk of a crash if someone uses something like this
“aelvalsrc=3.4e39”.
>
>> +sample = fabsf(*audio_data);
>> +if (sample > vd->max)
>> +vd->max = sample;
>> +vd->sum2 += sample * sample;
>> +idx = lrintf(floorf(logdb(sample * sample, AV_SAMPLE_FMT_FLT))) +
>> MAX_DB_FLT;
>
> You're recomputing the same value again, and you seem to be rounding twice in
> a row?
I missed, fixed.
>
>> +vd->histogram[idx]++;
>> +vd->nb_samples++;
>> }
>>
>> static int filter_frame(AVFilterLink *inlink, AVFrame *samples)
>> @@ -51,18 +75,41 @@ static int filter_frame(AVFilterLink *inlink, AVFrame
>> *samples)
>>int nb_channels = samples->ch_layout.nb_channels;
>>int nb_planes = nb_channels;
>>int plane, i;
>> -int16_t *pcm;
>> +int planar = 0;
>>
>> -if (!av_sample_fmt_is_planar(samples->format)) {
>> -nb_samples *= nb_channels;
>> +planar = av_sample_fmt_is_planar(samples->format);
>> +if (!planar)
>>nb_planes = 1;
>> +if (vd->is_float) {
>> +float *audio_data;
>> +for (plane = 0; plane < nb_planes; plane++) {
>> +audio_data = (float *)samples->extended_data[plane];
>> +for (i = 0; i < nb_samples; i++) {
>> +if (planar) {
>> +update_float_stats(vd, &audio_data[i]);
>> +} else {
>> +for (int j = 0; j < nb_channels; j++)
>> +update_float_stats(vd, &audio_data[i * nb_channels
>> + j]);
>> +}
>> +}
>> +}
>> +} else {
>> +int16_t *pcm;
>> +for (plane = 0; plane < nb_planes; plane++) {
>> +pcm = (int16_t *)samples->extended_data[plane];
>> +for (i = 0; i < nb_samples; i++) {
>> +if (planar) {
>> +vd->histogram[pcm[i] + 0x8000]++;
>> +vd->nb_samples++;
>> +} else {
>> +for (int j = 0; j < nb_channels; j++) {
>> +vd->histogram[pcm[i * nb_channels + j] + 0x8000]++;
>> +vd->nb_samples++;
>> +}
>> +}
>> +}
>> +}
>
> Can't we pick the correct implementation (planar/packed and float/int) once
> and for all whilst configuring the filter?
Actually sounds good, I am going to try.
Thanks for the feedback!
>
>>}
>> -for (plane = 0; plane < nb_planes; plane++
Re: [FFmpeg-devel] [PATCH 7/9] MAINTAINERS: Update the entries for the release maintainer for FFmpeg
Michael Niedermayer 于2024年6月17日周一 07:09写道： > > Ive been told that someone at the BCN video tech meetup claimed to be the > "release maintainer for FFmpeg". > > If you have any doubt who maintains releases, just do something like the > following and look at the output: > VER=5.1 > echo commiters ; git shortlog --group=committer -s n$VER..release/$VER -n ;\ > echo authors ; git shortlog-s n$VER..release/$VER -n (base) MacBook-Pro:ffmpeg StevenLiu$ VER=5.1 (base) MacBook-Pro:ffmpeg StevenLiu$ echo committers ; git shortlog --group=committer -s n$VER..release/$VER -n ;echo authors ; git shortlog-s n$VER..release/$VER -n committers fatal: ambiguous argument 'n5.1..release/5.1': unknown revision or path not in the working tree. Use '--' to separate paths from revisions, like this: 'git [...] -- [...]' authors fatal: ambiguous argument 'n5.1..release/5.1': unknown revision or path not in the working tree. Use '--' to separate paths from revisions, like this: 'git [...] -- [...]' (base) MacBook-Pro:ffmpeg StevenLiu$ > > Signed-off-by: Michael Niedermayer > --- > MAINTAINERS | 8 +--- > 1 file changed, 5 insertions(+), 3 deletions(-) > > diff --git a/MAINTAINERS b/MAINTAINERS > index 41a98744adf..a82fa58c69f 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -536,10 +536,12 @@ wm4 > Releases > > > +7.0 Michael Niedermayer > +6.1 Michael Niedermayer > +5.1 Michael Niedermayer > +4.4 Michael Niedermayer > +3.4 Michael Niedermayer > 2.8 Michael Niedermayer > -2.7 Michael Niedermayer > -2.6 Michael Niedermayer > -2.5 Michael Niedermayer > > If you want to maintain an older release, please contact us > > -- > 2.45.2 > > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". ___ ffmpeg-devel 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 7/9] MAINTAINERS: Update the entries for the release maintainer for FFmpeg
Steven Liu 于2024年6月18日周二 17:53写道： > > Michael Niedermayer 于2024年6月17日周一 07:09写道： > > > > Ive been told that someone at the BCN video tech meetup claimed to be the > > "release maintainer for FFmpeg". > > > > If you have any doubt who maintains releases, just do something like the > > following and look at the output: > > VER=5.1 > > echo commiters ; git shortlog --group=committer -s n$VER..release/$VER -n > > ;\ > > echo authors ; git shortlog-s n$VER..release/$VER -n > > (base) MacBook-Pro:ffmpeg StevenLiu$ VER=5.1 > (base) MacBook-Pro:ffmpeg StevenLiu$ echo committers ; git shortlog > --group=committer -s n$VER..release/$VER -n ;echo authors ; git > shortlog-s n$VER..release/$VER -n > committers > fatal: ambiguous argument 'n5.1..release/5.1': unknown revision or > path not in the working tree. > Use '--' to separate paths from revisions, like this: > 'git [...] -- [...]' > authors > fatal: ambiguous argument 'n5.1..release/5.1': unknown revision or > path not in the working tree. > Use '--' to separate paths from revisions, like this: > 'git [...] -- [...]' > (base) MacBook-Pro:ffmpeg StevenLiu$ This can fix the error message. not sure if this is right operation :D echo committers ; git shortlog --group=committer -s n$VER..remotes/origin/release/$VER -n ;echo authors ; git shortlog -s n$VER..remotes/origin/release/$VER -n > > > > > > > Signed-off-by: Michael Niedermayer > > --- > > MAINTAINERS | 8 +--- > > 1 file changed, 5 insertions(+), 3 deletions(-) > > > > diff --git a/MAINTAINERS b/MAINTAINERS > > index 41a98744adf..a82fa58c69f 100644 > > --- a/MAINTAINERS > > +++ b/MAINTAINERS > > @@ -536,10 +536,12 @@ wm4 > > Releases > > > > > > +7.0 Michael Niedermayer > > +6.1 Michael Niedermayer > > +5.1 Michael Niedermayer > > +4.4 Michael Niedermayer > > +3.4 Michael Niedermayer > > 2.8 Michael Niedermayer > > -2.7 Michael Niedermayer > > -2.6 Michael Niedermayer > > -2.5 Michael Niedermayer > > > > If you want to maintain an older release, please contact us > > > > -- > > 2.45.2 > > > > ___ > > ffmpeg-devel mailing list > > ffmpeg-devel@ffmpeg.org > > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > > > To unsubscribe, visit link above, or email > > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". ___ ffmpeg-devel 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 7/9] MAINTAINERS: Update the entries for the release maintainer for FFmpeg
Quoting Michael Niedermayer (2024-06-18 01:48:25) > On Mon, Jun 17, 2024 at 09:07:23AM +0200, Anton Khirnov wrote: > > Quoting Michael Niedermayer (2024-06-17 01:08:29) > > > Ive been told that someone at the BCN video tech meetup claimed to be the > > > "release maintainer for FFmpeg". > > > > > > If you have any doubt who maintains releases, just do something like the > > > following and look at the output: > > > VER=5.1 > > > echo commiters ; git shortlog --group=committer -s n$VER..release/$VER > > > -n ;\ > > > echo authors ; git shortlog-s n$VER..release/$VER > > > -n > > > > Passive aggressive gossip does not belong in a commit message. > > we generally explain in a commit message the "why" and "what" and so on. > There was no intention of any aggression. The commit message is indirectly accusing an unindentified person of trying to usurp your position as a release maintainer. The accusation is aggressive, and the fact that it is indirect makes it passive aggressive. Not providing any specifics beyond "someone said that someone said" makes it gossip. Each of those factors in isolation IMO makes this text inappropriate for a commit message. > But how would you word it instead ? I would not word it at all, as there is no evidence that this needs clarifying. Gossip is not evidence. > The example git commands simply show the authors and commiters on the release > branch > since the first release on it. I think its reasonable to provide these as > reference I don't. Nobody is disputing your role as a release maintainer. -- Anton Khirnov ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC] 5 year plan & Inovation
On Mon, Jun 17, 2024 at 11:02:31PM +0200, Rémi Denis-Courmont wrote: > > > Le 17 juin 2024 20:34:39 GMT+02:00, Michael Niedermayer > a écrit : [...] > >We should turn ffplay into a fully competetive player. > > No. First there is no such thing as "a fully competitive player". You would > need at least one mobile player, one smart TV and STB player and one desktop > player, on top of the existing crude CLI player. And that's if you manage > Android and iOS, mac and Windows, together. Otherwise it's even more players. Maybe "fully competetive player" was a bad term I think ffplay is quite close to being fully competetive. I do use it 95% of the time and iam not feeling like iam missing something > > Then you would need each of them to have features that FFmpeg doesn't have as > a back-end, notably media library management. we support various playlists. That could be extended but i agree some kind of playlist display and editing / (media library management seems a fancy term for that) is important for some users > > That's a lot of work, mostly GUI work. No offence but you and most other devs > here don't strike me as GUI devs. VLC is pretty much dead now for > under-estimating how hard it was to rewrite the desktop UI. How will you find > and keep motivated the developers for all that UI work? They are not going to > manifest spontaneously, even less so in a community with a deservedly > horrible reputation as FFmpeg's. I have written basic GUIs in some toy projects long prior ffmpeg, I remember having had a multi level menu and a animated raytraced mouse cursor in one ;) it was just a few lines of C + ASM code but looked quite good for the time. And in the software defined radio code i had written there was a vissualization with the decoded channel/artist/song names drawn on the spectrum waterfall plot thingy. If one wants to write a GUI with 10 differnt high level APIs, its going to be alot of code and hard to maintain (keeping up with each platforms / lib GUI APIs and all the bugs) I see nothing wrong with making it easy for people to do this if one wants to maintain a specific GUI for a specific platform. But supporting 10 GUI libs wasnt what i had in mind Instead really we need just one GUI, and 2 variants (one for touchscreens and one for non touchscreens) implementing this with nothing but ANSI C and a framebuffer / 2d array of pixels is very doable. It can be made to look quite good, it depends on no APIs, and its not alot of code. One can of course also instead use some portable GUI library, i think whoever works on such GUI would decide how to do it. > > Unless you just won the Euromillion or something like that, this is not going > to happen. No ifs or buts about it. I think we where thinking of different things thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Republics decline into democracies and democracies degenerate into despotisms. -- 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 1/2] avutil/executor: Allowing thread_count be zero
On Mon, Jun 17, 2024 at 5:28 PM Zhao Zhili wrote: > > > > On Jun 17, 2024, at 16:45, Hendrik Leppkes wrote: > > > > On Mon, Jun 17, 2024 at 10:03 AM Zhao Zhili > wrote: > >> > >> > >> > >>> On Jun 17, 2024, at 15:05, Anton Khirnov wrote: > >>> > >>> Quoting Zhao Zhili (2024-06-17 07:19:26) > From: Zhao Zhili > > When thread_count be zero, it will be run on current thread like > !HAVE_THREADS. > >>> > >>> Other APIs treat zero to mean "auto". > >> > >> executor don’t detect cpu cores by itself. It’s more low level than > libavcodec. > >> > >> Zero thread is zero thread, literally. If we use thread_count one to > mean > >> run on current thread, how to create a single thread then? > > > > Whats the point of creating a single thread? Does the main thread ever > > do something else in the meantime, or does it just wait for the job > > anyway? > > Executor as a basic infrastructure should support such usage. The caller > don’t need to wait for the job to finish. > Hi Zhili, Thank you for the patch. Could you explain more about its usage? Why do we need to run everything in the main thread when we have pthread in the system? Thank you. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 1/2] avutil/executor: Allowing thread_count be zero
Nuo Mi 于2024年6月18日周二 19:51写道： > > On Mon, Jun 17, 2024 at 5:28 PM Zhao Zhili wrote: > > > > > > > > On Jun 17, 2024, at 16:45, Hendrik Leppkes wrote: > > > > > > On Mon, Jun 17, 2024 at 10:03 AM Zhao Zhili > > wrote: > > >> > > >> > > >> > > >>> On Jun 17, 2024, at 15:05, Anton Khirnov wrote: > > >>> > > >>> Quoting Zhao Zhili (2024-06-17 07:19:26) > > From: Zhao Zhili > > > > When thread_count be zero, it will be run on current thread like > > !HAVE_THREADS. > > >>> > > >>> Other APIs treat zero to mean "auto". > > >> > > >> executor don’t detect cpu cores by itself. It’s more low level than > > libavcodec. > > >> > > >> Zero thread is zero thread, literally. If we use thread_count one to > > mean > > >> run on current thread, how to create a single thread then? > > > > > > Whats the point of creating a single thread? Does the main thread ever > > > do something else in the meantime, or does it just wait for the job > > > anyway? > > > > Executor as a basic infrastructure should support such usage. The caller > > don’t need to wait for the job to finish. > > > Hi Zhili, > Thank you for the patch. > Could you explain more about its usage? > Why do we need to run everything in the main thread when we have pthread in > the system? Just control CPU resource be used by decoder, perhaps the computer is running some other applications. There are running more application in one computer, and the ffmpeg decoder is need not realtime. For example running machine learning traning some model, and use ffmpeg transcoding vod videos, but transcode functions is borrow machine learning's team computers :D. > > Thank you. > ___ > 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". Thanks Steven ___ 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] fate/lavf-container: add a hevc in ISOBMFF remux test
mån 2024-06-17 klockan 11:41 -0300 skrev James Almer: > Signed-off-by: James Almer > --- > tests/fate/lavf-container.mak | 2 ++ > tests/ref/lavf-fate/hevc.mp4 | 3 +++ > 2 files changed, 5 insertions(+) > create mode 100644 tests/ref/lavf-fate/hevc.mp4 Looks OK /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 v3 0/5] Vision Pro Spatial Data
On 6/17/2024 8:20 PM, Derek Buitenhuis wrote: > 12 files changed, 490 insertions(+), 1 deletion(-) Will push later today if there are no objections. - Derek ___ 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] fate/lavf-container: add a hevc in ISOBMFF remux test
James Almer: > Signed-off-by: James Almer > --- > tests/fate/lavf-container.mak | 2 ++ > tests/ref/lavf-fate/hevc.mp4 | 3 +++ > 2 files changed, 5 insertions(+) > create mode 100644 tests/ref/lavf-fate/hevc.mp4 > > diff --git a/tests/fate/lavf-container.mak b/tests/fate/lavf-container.mak > index d84117c50f..56490c3369 100644 > --- a/tests/fate/lavf-container.mak > +++ b/tests/fate/lavf-container.mak > @@ -74,6 +74,7 @@ FATE_LAVF_CONTAINER_FATE-$(call ALLYES, IVF_DEMUXER > AV1_DECODER AV1_PARSER MOV_M > FATE_LAVF_CONTAINER_FATE-$(call ALLYES, IVF_DEMUXER AV1_DECODER AV1_PARSER > MATROSKA_MUXER) += av1.mkv > FATE_LAVF_CONTAINER_FATE-$(call ALLYES, EVC_DEMUXER EVC_PARSER MOV_MUXER) > += evc.mp4 > FATE_LAVF_CONTAINER_FATE-$(call ALLYES, H264_DEMUXER H264_PARSER MOV_MUXER) > += h264.mp4 > +FATE_LAVF_CONTAINER_FATE-$(call ALLYES, HEVC_DEMUXER HEVC_PARSER MOV_MUXER) > += hevc.mp4 > FATE_LAVF_CONTAINER_FATE-$(call ALLYES, VVC_DEMUXER VVC_PARSER MOV_MUXER) > += vvc.mp4 > FATE_LAVF_CONTAINER_FATE-$(call ALLYES, MATROSKA_DEMUXER OGG_MUXER) > += vp3.ogg > FATE_LAVF_CONTAINER_FATE-$(call ALLYES, MATROSKA_DEMUXER OGV_MUXER) > += vp8.ogg > @@ -92,6 +93,7 @@ fate-lavf-fate-av1.mp4: CMD = lavf_container_fate > "av1-test-vectors/av1-1-b8-05- > fate-lavf-fate-av1.mkv: CMD = lavf_container_fate > "av1-test-vectors/av1-1-b8-05-mv.ivf" "-c:v av1" "-c:v copy" > fate-lavf-fate-evc.mp4: CMD = lavf_container_fate "evc/akiyo_cif.evc" "" > "-c:v copy" > fate-lavf-fate-h264.mp4: CMD = lavf_container_fate "h264/intra_refresh.h264" > "" "-c:v copy" > +fate-lavf-fate-hevc.mp4: CMD = lavf_container_fate > "hevc-conformance/HRD_A_Fujitsu_2.bit" "" "-c:v copy" > fate-lavf-fate-vvc.mp4: CMD = lavf_container_fate > "vvc-conformance/VPS_A_3.bit" "" "-c:v copy" > fate-lavf-fate-vp3.ogg: CMD = lavf_container_fate "vp3/coeff_level64.mkv" > "-idct auto" > fate-lavf-fate-vp8.ogg: CMD = lavf_container_fate "vp8/RRSF49-short.webm" "" > "-acodec copy" > diff --git a/tests/ref/lavf-fate/hevc.mp4 b/tests/ref/lavf-fate/hevc.mp4 > new file mode 100644 > index 00..aea5ae8979 > --- /dev/null > +++ b/tests/ref/lavf-fate/hevc.mp4 > @@ -0,0 +1,3 @@ > +37b3a3e84df2350380b05b2af4dc97f5 *tests/data/lavf-fate/lavf.hevc.mp4 > +151340 tests/data/lavf-fate/lavf.hevc.mp4 > +tests/data/lavf-fate/lavf.hevc.mp4 CRC=0xc0a771de Sure this does not need the HEVC decoder (to derive some stream properties that end up in isobmff header fields)? And I would also expect it to need the extract_extradata bsf as well. - Andreas ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] fate/lavf-container: add a hevc in ISOBMFF remux test
On 6/18/2024 10:32 AM, Andreas Rheinhardt wrote: James Almer: Signed-off-by: James Almer --- tests/fate/lavf-container.mak | 2 ++ tests/ref/lavf-fate/hevc.mp4 | 3 +++ 2 files changed, 5 insertions(+) create mode 100644 tests/ref/lavf-fate/hevc.mp4 diff --git a/tests/fate/lavf-container.mak b/tests/fate/lavf-container.mak index d84117c50f..56490c3369 100644 --- a/tests/fate/lavf-container.mak +++ b/tests/fate/lavf-container.mak @@ -74,6 +74,7 @@ FATE_LAVF_CONTAINER_FATE-$(call ALLYES, IVF_DEMUXER AV1_DECODER AV1_PARSER MOV_M FATE_LAVF_CONTAINER_FATE-$(call ALLYES, IVF_DEMUXER AV1_DECODER AV1_PARSER MATROSKA_MUXER) += av1.mkv FATE_LAVF_CONTAINER_FATE-$(call ALLYES, EVC_DEMUXER EVC_PARSER MOV_MUXER) += evc.mp4 FATE_LAVF_CONTAINER_FATE-$(call ALLYES, H264_DEMUXER H264_PARSER MOV_MUXER) += h264.mp4 +FATE_LAVF_CONTAINER_FATE-$(call ALLYES, HEVC_DEMUXER HEVC_PARSER MOV_MUXER) += hevc.mp4 FATE_LAVF_CONTAINER_FATE-$(call ALLYES, VVC_DEMUXER VVC_PARSER MOV_MUXER) += vvc.mp4 FATE_LAVF_CONTAINER_FATE-$(call ALLYES, MATROSKA_DEMUXER OGG_MUXER) += vp3.ogg FATE_LAVF_CONTAINER_FATE-$(call ALLYES, MATROSKA_DEMUXER OGV_MUXER) += vp8.ogg @@ -92,6 +93,7 @@ fate-lavf-fate-av1.mp4: CMD = lavf_container_fate "av1-test-vectors/av1-1-b8-05- fate-lavf-fate-av1.mkv: CMD = lavf_container_fate "av1-test-vectors/av1-1-b8-05-mv.ivf" "-c:v av1" "-c:v copy" fate-lavf-fate-evc.mp4: CMD = lavf_container_fate "evc/akiyo_cif.evc" "" "-c:v copy" fate-lavf-fate-h264.mp4: CMD = lavf_container_fate "h264/intra_refresh.h264" "" "-c:v copy" +fate-lavf-fate-hevc.mp4: CMD = lavf_container_fate "hevc-conformance/HRD_A_Fujitsu_2.bit" "" "-c:v copy" fate-lavf-fate-vvc.mp4: CMD = lavf_container_fate "vvc-conformance/VPS_A_3.bit" "" "-c:v copy" fate-lavf-fate-vp3.ogg: CMD = lavf_container_fate "vp3/coeff_level64.mkv" "-idct auto" fate-lavf-fate-vp8.ogg: CMD = lavf_container_fate "vp8/RRSF49-short.webm" "" "-acodec copy" diff --git a/tests/ref/lavf-fate/hevc.mp4 b/tests/ref/lavf-fate/hevc.mp4 new file mode 100644 index 00..aea5ae8979 --- /dev/null +++ b/tests/ref/lavf-fate/hevc.mp4 @@ -0,0 +1,3 @@ +37b3a3e84df2350380b05b2af4dc97f5 *tests/data/lavf-fate/lavf.hevc.mp4 +151340 tests/data/lavf-fate/lavf.hevc.mp4 +tests/data/lavf-fate/lavf.hevc.mp4 CRC=0xc0a771de Sure this does not need the HEVC decoder (to derive some stream properties that end up in isobmff header fields)? And I would also expect it to need the extract_extradata bsf as well. The parser is enough to get information for remuxing purposes. And the muxer will take the required NALUs from the first packet if there's no extradata present in codecpar. ___ 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/7] avcodec/utils: apply the same alignment to YUV410 as we do to YUV420 when motion estimation is used
The snow encoder uses block based motion estimation which can read out of array
if
insufficient alignment is used
Fixes: out of array access
Fixes:
68963/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_SNOW_fuzzer-4979988435632128
Fixes:
68969/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_SNOW_fuzzer-6239933667803136.fuzz
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavcodec/utils.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/libavcodec/utils.c b/libavcodec/utils.c
index 337c00e789a..7914f799041 100644
--- a/libavcodec/utils.c
+++ b/libavcodec/utils.c
@@ -259,6 +259,9 @@ void avcodec_align_dimensions2(AVCodecContext *s, int
*width, int *height,
if (s->codec_id == AV_CODEC_ID_SVQ1) {
w_align = 64;
h_align = 64;
+} else if (s->codec_id == AV_CODEC_ID_SNOW) {
+w_align = 16;
+h_align = 16;
}
break;
case AV_PIX_FMT_RGB555:
--
2.45.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 2/7] avcodec/ratecontrol: Try to keep fps as a rational
Signed-off-by: Michael Niedermayer
---
libavcodec/ratecontrol.c | 22 ++
1 file changed, 14 insertions(+), 8 deletions(-)
diff --git a/libavcodec/ratecontrol.c b/libavcodec/ratecontrol.c
index 609d47faeb4..df27639ca73 100644
--- a/libavcodec/ratecontrol.c
+++ b/libavcodec/ratecontrol.c
@@ -56,20 +56,25 @@ void ff_write_pass1_stats(MpegEncContext *s)
s->header_bits);
}
-static double get_fps(AVCodecContext *avctx)
+static AVRational get_fpsQ(AVCodecContext *avctx)
{
if (avctx->framerate.num > 0 && avctx->framerate.den > 0)
-return av_q2d(avctx->framerate);
+return avctx->framerate;
FF_DISABLE_DEPRECATION_WARNINGS
-return 1.0 / av_q2d(avctx->time_base)
#if FF_API_TICKS_PER_FRAME
-/ FFMAX(avctx->ticks_per_frame, 1)
+return av_div_q((AVRational){1, FFMAX(avctx->ticks_per_frame, 1)},
avctx->time_base);
+#else
+return av_inv_q(avctx->time_base);
#endif
-;
FF_ENABLE_DEPRECATION_WARNINGS
}
+static double get_fps(AVCodecContext *avctx)
+{
+return av_q2d(get_fpsQ(avctx));
+}
+
static inline double qp2bits(const RateControlEntry *rce, double qp)
{
if (qp <= 0.0) {
@@ -332,12 +337,13 @@ static int init_pass2(MpegEncContext *s)
RateControlContext *rcc = &s->rc_context;
AVCodecContext *a = s->avctx;
int i, toobig;
-double fps = get_fps(s->avctx);
+AVRational fps = get_fpsQ(s->avctx);
double complexity[5] = { 0 }; // approximate bits at quant=1
uint64_t const_bits[5] = { 0 }; // quantizer independent bits
uint64_t all_const_bits;
-uint64_t all_available_bits = (uint64_t)(s->bit_rate *
- (double)rcc->num_entries / fps);
+uint64_t all_available_bits = av_rescale_q(s->bit_rate,
+
(AVRational){rcc->num_entries,1},
+ fps);
double rate_factor = 0;
double step;
const int filter_size = (int)(a->qblur * 4) | 1;
--
2.45.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 3/7] avcodec/ratecontrol: Handle wanted bits overflow
Fixes: 5.92611e+20 is outside the range of representable values of type
'unsigned long'
Fixes:
68984/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_SNOW_fuzzer-5155755073273856
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavcodec/ratecontrol.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/libavcodec/ratecontrol.c b/libavcodec/ratecontrol.c
index df27639ca73..86ec7a3443e 100644
--- a/libavcodec/ratecontrol.c
+++ b/libavcodec/ratecontrol.c
@@ -936,6 +936,7 @@ float ff_rate_estimate_qscale(MpegEncContext *s, int
dry_run)
wanted_bits = rce->expected_bits;
} else {
const MPVPicture *dts_pic;
+double wanted_bits_double;
rce = &local_rce;
/* FIXME add a dts field to AVFrame and ensure it is set and use it
@@ -947,9 +948,14 @@ float ff_rate_estimate_qscale(MpegEncContext *s, int
dry_run)
dts_pic = s->last_pic.ptr;
if (!dts_pic || dts_pic->f->pts == AV_NOPTS_VALUE)
-wanted_bits = (uint64_t)(s->bit_rate * (double)picture_number /
fps);
+wanted_bits_double = s->bit_rate * (double)picture_number / fps;
else
-wanted_bits = (uint64_t)(s->bit_rate * (double)dts_pic->f->pts /
fps);
+wanted_bits_double = s->bit_rate * (double)dts_pic->f->pts / fps;
+if (wanted_bits_double > INT64_MAX) {
+av_log(s, AV_LOG_WARNING, "Bits exceed 64bit range\n");
+wanted_bits = INT64_MAX;
+} else
+wanted_bits = (int64_t)wanted_bits_double;
}
diff = s->total_bits - wanted_bits;
--
2.45.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 4/7] avcodec/snowenc: MV limits due to mv_penalty table size
Fixes: out of array read
Fixes:
69673/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_SNOW_fuzzer-5476592894148608
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavcodec/snowenc.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/libavcodec/snowenc.c b/libavcodec/snowenc.c
index 8d6dabae658..dd6ce36aa54 100644
--- a/libavcodec/snowenc.c
+++ b/libavcodec/snowenc.c
@@ -413,6 +413,7 @@ static int encode_q_branch(SnowEncContext *enc, int level,
int x, int y)
int my_context= av_log2(2*FFABS(left->my - top->my));
int s_context= 2*left->level + 2*top->level + tl->level + tr->level;
int ref, best_ref, ref_score, ref_mx, ref_my;
+int range = MAX_MV >> (1 + qpel);
av_assert0(sizeof(s->block_state) >= 256);
if(s->keyframe){
@@ -454,6 +455,11 @@ static int encode_q_branch(SnowEncContext *enc, int level,
int x, int y)
c->xmax = - (x+1)*block_w + (w<<(LOG2_MB_SIZE - s->block_max_depth)) +
16-3;
c->ymax = - (y+1)*block_w + (h<<(LOG2_MB_SIZE - s->block_max_depth)) +
16-3;
+c->xmin = FFMAX(c->xmin,-range);
+c->xmax = FFMIN(c->xmax, range);
+c->ymin = FFMAX(c->ymin,-range);
+c->ymax = FFMIN(c->ymax, range);
+
if(P_LEFT[0] > (c->xmaxymaxxmax
[FFmpeg-devel] [PATCH 5/7] avcodec/jfdctint_template: Fewer integer anomalies
Fixes: signed integer overflow: 105788 * -20995 cannot be represented in type
'int'
Fixes: signed integer overflow: 923211729 + 2073948236 cannot be represented in
type 'int'
Fixes: signed integer overflow: 1281179284 + 2073948236 cannot be represented
in type 'int'
Fixes:
68975/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_PRORES_fuzzer-6266769177116672
Fixes:
68997/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_PRORES_KS_fuzzer-6284237161431040
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavcodec/jfdctint_template.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/libavcodec/jfdctint_template.c b/libavcodec/jfdctint_template.c
index ca17300c324..aa2680132ee 100644
--- a/libavcodec/jfdctint_template.c
+++ b/libavcodec/jfdctint_template.c
@@ -69,7 +69,7 @@
#define GLOBAL(x) x
#define RIGHT_SHIFT(x, n) ((x) >> (n))
#define MULTIPLY16C16(var,const) ((var)*(const))
-#define DESCALE(x,n) RIGHT_SHIFT((x) + (1 << ((n) - 1)), n)
+#define DESCALE(x,n) RIGHT_SHIFT((int)(x) + (1 << ((n) - 1)), n)
/*
@@ -175,7 +175,7 @@
#if BITS_IN_JSAMPLE == 8 && CONST_BITS<=13 && PASS1_BITS<=2
#define MULTIPLY(var,const) MULTIPLY16C16(var,const)
#else
-#define MULTIPLY(var,const) ((var) * (const))
+#define MULTIPLY(var,const) (int)((var) * (unsigned)(const))
#endif
@@ -261,7 +261,7 @@ FUNC(ff_jpeg_fdct_islow)(int16_t *data)
{
int tmp0, tmp1, tmp2, tmp3, tmp4, tmp5, tmp6, tmp7;
int tmp10, tmp11, tmp12, tmp13;
- int z1, z2, z3, z4, z5;
+ unsigned z1, z2, z3, z4, z5;
int16_t *dataptr;
int ctr;
--
2.45.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 6/7] avcodec/vc2enc: Fix overflows with storing large values
Fixes: left shift of 1431634944 by 2 places cannot be represented in type 'int'
Fixes: left shift of 1073741824 by 1 places cannot be represented in type 'int'
Fixes:
69061/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_VC2_fuzzer-6325700826038272
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavcodec/vc2enc.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/libavcodec/vc2enc.c b/libavcodec/vc2enc.c
index 4ea836d9c9a..7fa6ddc4ca0 100644
--- a/libavcodec/vc2enc.c
+++ b/libavcodec/vc2enc.c
@@ -189,7 +189,9 @@ typedef struct VC2EncContext {
static av_always_inline void put_vc2_ue_uint(PutBitContext *pb, uint32_t val)
{
int i;
-int pbits = 0, bits = 0, topbit = 1, maxval = 1;
+int bits = 0;
+unsigned topbit = 1, maxval = 1;
+uint64_t pbits = 0;
if (!val++) {
put_bits(pb, 1, 1);
@@ -206,12 +208,13 @@ static av_always_inline void
put_vc2_ue_uint(PutBitContext *pb, uint32_t val)
for (i = 0; i < bits; i++) {
topbit >>= 1;
+av_assert2(pbits <= UINT64_MAX>>3);
pbits <<= 2;
if (val & topbit)
pbits |= 0x1;
}
-put_bits(pb, bits*2 + 1, (pbits << 1) | 1);
+put_bits64(pb, bits*2 + 1, (pbits << 1) | 1);
}
static av_always_inline int count_vc2_ue_uint(uint32_t val)
--
2.45.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 7/7] avcodec/proresenc_kostya: use unsigned alpha for rotation
Fixes: left shift of negative value -208
Fixes:
69073/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_PRORES_KS_fuzzer-4745020002336768
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavcodec/proresenc_kostya.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/proresenc_kostya.c b/libavcodec/proresenc_kostya.c
index 8b91ca1a98a..fe8cc5f0fda 100644
--- a/libavcodec/proresenc_kostya.c
+++ b/libavcodec/proresenc_kostya.c
@@ -343,7 +343,7 @@ static void get_slice_data(ProresContext *ctx, const
uint16_t *src,
static void get_alpha_data(ProresContext *ctx, const uint16_t *src,
ptrdiff_t linesize, int x, int y, int w, int h,
- int16_t *blocks, int mbs_per_slice, int abits)
+ uint16_t *blocks, int mbs_per_slice, int abits)
{
const int slice_width = 16 * mbs_per_slice;
int i, j, copy_w, copy_h;
--
2.45.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2] avcodec/jpeg2000dec: Add support for placeholder passes, CAP, and CPF markers
It seems this patch combines a lot of things that might be better to
split into separate patches for easier review
> @@ -382,6 +391,9 @@ static int get_siz(Jpeg2000DecoderContext *s)
> } else if (ncomponents == 1 && s->precision == 8) {
> s->avctx->pix_fmt = AV_PIX_FMT_GRAY8;
> i = 0;
> + } else if (ncomponents == 1 && s->precision == 12) {
> + s->avctx->pix_fmt = AV_PIX_FMT_GRAY16LE;
> + i = 0;
Could we handle 9 <= precision <= 16 while we're at it?
> @@ -408,6 +420,73 @@ static int get_siz(Jpeg2000DecoderContext *s)
> s->avctx->bits_per_raw_sample = s->precision;
> return 0;
> }
> +/* get extended capabilities (CAP) marker segment */
> +static int get_cap(Jpeg2000DecoderContext *s, Jpeg2000CodingStyle
> *c)
> +{
> + uint32_t Pcap;
> + uint16_t Ccap_i[32] = { 0 };
> + uint16_t Ccap_15;
> + uint8_t P;
> +
> + if (bytestream2_get_bytes_left(&s->g) < 6) {
> + av_log(s->avctx, AV_LOG_ERROR, "Insufficient space for
> CAP\n");
> + return AVERROR_INVALIDDATA;
> + }
> +
> + Pcap = bytestream2_get_be32u(&s->g);
> + s->isHT = (Pcap >> (31 - (15 - 1))) & 1;
> + for (int i = 0; i < 32; i++) {
> + if ((Pcap >> (31 - i)) & 1)
> + Ccap_i[i] = bytestream2_get_be16u(&s->g);
> + }
> + Ccap_15 = Ccap_i[14];
> + if (s->isHT == 1) {
> + av_log(s->avctx, AV_LOG_INFO, "This is an HTJ2K codestream.\n");
> + // Bits 14-15
> + switch ((Ccap_15 >> 14) & 0x3) {
Missing indentation
> + case 0x3:
> + s->Ccap15_b14_15 = HTJ2K_MIXED;
> + break;
> + case 0x1:
> + s->Ccap15_b14_15 = HTJ2K_HTDECLARED;
> + break;
> + case 0x0:
> + s->Ccap15_b14_15 = HTJ2K_HTONLY;
> + break;
> + default:
> + av_log(s->avctx, AV_LOG_ERROR, "Unknown CCap
> value.\n");
> + return AVERROR(EINVAL);
> + break;
> + }
> + // Bit 13
> + if ((Ccap_15 >> 13) & 1) {
> + av_log(s->avctx, AV_LOG_ERROR, "MULTIHT set is not
> supported.\n");
> + return AVERROR_PATCHWELCOME;
> + }
> + // Bit 12
> + s->Ccap15_b12 = (Ccap_15 >> 12) & 1;
> + // Bit 11
> + s->Ccap15_b11 = (Ccap_15 >> 11) & 1;
> + // Bit 5
> + s->Ccap15_b05 = (Ccap_15 >> 5) & 1;
> + // Bit 0-4
> + P = Ccap_15 & 0x1F;
> + if (!P)
> + s->HT_MAGB = 8;
> + else if (P < 20)
> + s->HT_MAGB = P + 8;
> + else if (P < 31)
> + s->HT_MAGB = 4 * (P - 19) + 27;
> + else
> + s->HT_MAGB = 74;
> +
> + if (s->HT_MAGB > 31) {
> + av_log(s->avctx, AV_LOG_ERROR, "Available internal
> precision is exceeded (MAGB> 31).\n");
> + return AVERROR_PATCHWELCOME;
> + }
> + }
Weird indentation
> @@ -802,6 +881,15 @@ static int read_crg(Jpeg2000DecoderContext *s,
> int n)
> bytestream2_skip(&s->g, n - 2);
> return 0;
> }
> +
> +static int read_cpf(Jpeg2000DecoderContext *s, int n)
> +{
> + if (bytestream2_get_bytes_left(&s->g) < (n - 2))
> + return AVERROR_INVALIDDATA;
> + bytestream2_skip(&s->g, n - 2);
> + return 0;
> +}
Don't we already have code for skipping markers we don't care about?
> +
> /* Tile-part lengths: see ISO 15444-1:2002, section A.7.1
> * Used to know the number of tile parts and lengths.
> * There may be multiple TLMs in the header.
> @@ -965,6 +1053,10 @@ static int init_tile(Jpeg2000DecoderContext *s,
> int tileno)
> comp->roi_shift = s->roi_shift[compno];
> if (!codsty->init)
> return AVERROR_INVALIDDATA;
> + if (s->isHT && (!s->Ccap15_b05) && (!codsty->transform))
> + av_log(s->avctx, AV_LOG_WARNING, "Transformation = 0
> (lossy DWT) is found in HTREV HT set\n");
> + if (s->isHT && s->Ccap15_b14_15 != (codsty->cblk_style >> 6)
> && s->Ccap15_b14_15 != HTJ2K_HTONLY)
> + av_log(s->avctx, AV_LOG_WARNING, "SPcod/SPcoc value does
> not match bit 14-15 values of Ccap15\n");
Do you have samples demonstrating the need to accept such broken files?
If not then we should probably error out
> @@ -1704,7 +1989,7 @@ static int decode_cblk(const
> Jpeg2000DecoderContext *s, Jpeg2000CodingStyle *cod
> Jpeg2000T1Context *t1, Jpeg2000Cblk *cblk,
> int width, int height, int bandpos, uint8_t
> roi_shift)
> {
> - int passno = cblk->npasses, pass_t = 2, bpno = cblk->nonzerobits
> - 1 + roi_shift;
> + int passno = cblk->npasses, pass_t = 2, bpno = cblk->nonzerobits
> - 1;
Won't this break files with ROI? I see there's some ROI stuff further
down so maybe not
> @@ -2187,22 +2472,42 @@ static int
> jpeg2000_read_main_headers(Jpeg2000DecoderContext *s)
> if (!s->tile)
> s->numXtiles = s->numYtiles = 0;
> break;
> + case JPEG2000_CAP:
> + if (!s->ncomponents) {
> + av_log(s->avctx, AV_LOG_WARNING, "CAP marker
Re: [FFmpeg-devel] [PATCH 1/2] avutil/executor: Allowing thread_count be zero
> On Jun 18, 2024, at 19:50, Nuo Mi wrote: > > On Mon, Jun 17, 2024 at 5:28 PM Zhao Zhili wrote: > >> >> >>> On Jun 17, 2024, at 16:45, Hendrik Leppkes wrote: >>> >>> On Mon, Jun 17, 2024 at 10:03 AM Zhao Zhili >> wrote: > On Jun 17, 2024, at 15:05, Anton Khirnov wrote: > > Quoting Zhao Zhili (2024-06-17 07:19:26) >> From: Zhao Zhili >> >> When thread_count be zero, it will be run on current thread like >> !HAVE_THREADS. > > Other APIs treat zero to mean "auto". executor don’t detect cpu cores by itself. It’s more low level than >> libavcodec. Zero thread is zero thread, literally. If we use thread_count one to >> mean run on current thread, how to create a single thread then? >>> >>> Whats the point of creating a single thread? Does the main thread ever >>> do something else in the meantime, or does it just wait for the job >>> anyway? >> >> Executor as a basic infrastructure should support such usage. The caller >> don’t need to wait for the job to finish. >> > Hi Zhili, > Thank you for the patch. > Could you explain more about its usage? > Why do we need to run everything in the main thread when we have pthread in > the system? In addition to match other decodes behavior, there are some usecases which require the decoder to not create a thread at runtime. For example, when build libavcodec with wasm and run in web browser, the runtime may or may not support threads, threads number should be decided at runtime, and can be zero. > > Thank you. > ___ > 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] fate/jpeg2000dec: add support for p0_10.j2k
lör 2024-06-15 klockan 21:47 -0700 skrev p...@sandflow.com: > From: Pierre-Anthony Lemieux > > p0_10.j2k is one of the reference codestreams included in Rec. ITU-T > T.803 | ISO/IEC 15444-4. > --- > tests/fate/jpeg2000.mak | 3 +++ > tests/ref/fate/jpeg2000dec-p0_10 | 6 ++ > 2 files changed, 9 insertions(+) > create mode 100644 tests/ref/fate/jpeg2000dec-p0_10 Sounds good, assuming it decodes correctly If there are more files like this, could we add all of them in one go? /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 3/5] avformat/mxfdec: Check container_ul->desc before use
fre 2024-06-07 klockan 02:32 +0200 skrev Michael Niedermayer:
> Fixes: CID1592939 Dereference after null check
>
> Sponsored-by: Sovereign Tech Fund
> Signed-off-by: Michael Niedermayer
> ---
> libavformat/mxfdec.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/libavformat/mxfdec.c b/libavformat/mxfdec.c
> index e65cec74c23..820b03940aa 100644
> --- a/libavformat/mxfdec.c
> +++ b/libavformat/mxfdec.c
> @@ -3031,6 +3031,7 @@ static int
> mxf_parse_structural_metadata(MXFContext *mxf)
> if (container_ul->desc)
> av_dict_set(&st->metadata, "data_type",
> container_ul->desc, 0);
> if (mxf->eia608_extract &&
> + container_ul->desc &&
> !strcmp(container_ul->desc, "vbi_vanc_smpte_436M"))
> {
> st->codecpar->codec_type = AVMEDIA_TYPE_SUBTITLE;
> st->codecpar->codec_id = AV_CODEC_ID_EIA_608;
OK
/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 4/5] avformat/mxfenc: Remove dead code
fre 2024-06-07 klockan 02:32 +0200 skrev Michael Niedermayer:
> Fixes: CID1524681 Logically dead code
>
> Sponsored-by: Sovereign Tech Fund
> Signed-off-by: Michael Niedermayer
> ---
> libavformat/mxfenc.c | 3 ---
> 1 file changed, 3 deletions(-)
>
> diff --git a/libavformat/mxfenc.c b/libavformat/mxfenc.c
> index f424858fc4e..b8e7bfe3018 100644
> --- a/libavformat/mxfenc.c
> +++ b/libavformat/mxfenc.c
> @@ -2606,9 +2606,6 @@ static int mxf_parse_ffv1_frame(AVFormatContext
> *s, AVStream *st, AVPacket *pkt)
> ff_build_rac_states(&c, 0.05 * (1LL << 32), 256 - 8);
> v = get_ffv1_unsigned_symbol(&c, state);
> av_assert0(v >= 2);
> - if (v > 4) {
> - return 0;
> - }
> if (v > 4) {
> av_log(s, AV_LOG_ERROR, "unsupported ffv1 version %d\n",
> v);
> return 0;
Commit message isn't quite accurate - this rather resurrects the error
print
/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] STF 2025
mån 2024-06-03 klockan 08:50 +0200 skrev Thilo Borgmann via ffmpeg- devel: > Am 02.06.24 um 22:14 schrieb Tomas Härdin: > > sön 2024-06-02 klockan 20:01 +0200 skrev Michael Niedermayer: > > > Hi > > > > > > > > > On Sat, Jun 01, 2024 at 05:19:26PM +0200, Tomas Härdin wrote: > > > > > > [...] > > > > > > > > * Fund professional real live presence on multimedia / FOSS / > > > > > buisness related > > > > > events. > > > > > > > > Also reasonable. I could help man a booth at IBC or any other > > > > event > > > > in > > > > Europe > > > > > > Iam strongly in favor of that! Though i have no idea about cost > > > (for > > > IBC) > > > which probably requires someone to sponsor a booth if its not > > > free. > > > Or any details. But i think its probably best if you mail thilo > > > as he > > > was helping with FFmpeg presence on many european booths > > > > Attending is free, so I expect booths cost quite a bit to make up > > the > > costs. There's an inquiry form on the IBC website. Can't hurt to > > ask > > > > Hotels aren't cheap as Rémi points out. Last time I attended IBC we > > had > > to get a hotel in Harlem. Luckily I know some people in Amsterdam > > We have a booth on IBC this year which again gets sponsored so no > costs for FFmpeg. > Some details are still unclear which is why it's not yet announced. > > @Thomas: Happy you want to attend, I'll keep you updated. Update: I probably won't be able to attend due to a scheduling conflict /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] avcodec: add farbfeld encoder
mån 2024-06-03 klockan 19:16 + skrev marcus: > > > > > > > Check the return value of av_image_get_buffer_size() before > > > adding > > > > > HEADER_SIZE to it. There will be a signed overflow (UB) for > > > images of > > > size 16385x16385 (and many others). > > > > > > Sorry, I missed the multiplication by h+128 in > > av_image_check_size2(). > > So this isn't a problem in this specific case. > > > > > Aside: av_image_get_buffer_size() will UB for sizes above INT_MAX > > > because the size_t's in sizes[] get accumulated into an int. > > > Besides > > > the UB it also returns incorrect values. > > > > > > This however is a problem for planar formats. This doesn't affect > > this patch however. > Did you incorrectly format that message? Or did you really mean that > the UB when the size is greater than INT_MAX doesn't affect my patch? It doesn't affect this patch because AV_PIX_FMT_RGBA64BE isn't planar /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] fate/jpeg2000dec: add support for p0_10.j2k
On Tue, Jun 18, 2024 at 7:25 AM Tomas Härdin wrote: > > lör 2024-06-15 klockan 21:47 -0700 skrev p...@sandflow.com: > > From: Pierre-Anthony Lemieux > > > > p0_10.j2k is one of the reference codestreams included in Rec. ITU-T > > T.803 | ISO/IEC 15444-4. > > --- > > tests/fate/jpeg2000.mak | 3 +++ > > tests/ref/fate/jpeg2000dec-p0_10 | 6 ++ > > 2 files changed, 9 insertions(+) > > create mode 100644 tests/ref/fate/jpeg2000dec-p0_10 > > Sounds good, assuming it decodes correctly > > If there are more files like this, could we add all of them in one go? I expect significantly more files to be added once the "Add support for placeholder passes, CAP, and CPF markers" patch is merged. In the meantime, I do not see a downside to updating FATE since it addresses a specific bug in trac. > > /Tomas > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] avformat/dump: Print all possible Stereo3D info
Signed-off-by: Derek Buitenhuis --- As requested by James. --- libavformat/dump.c | 9 + 1 file changed, 9 insertions(+) diff --git a/libavformat/dump.c b/libavformat/dump.c index 059fb84522..8e8b9e1959 100644 --- a/libavformat/dump.c +++ b/libavformat/dump.c @@ -260,6 +260,15 @@ static void dump_stereo3d(void *ctx, const AVPacketSideData *sd, int log_level) stereo = (const AVStereo3D *)sd->data; av_log(ctx, log_level, "%s", av_stereo3d_type_name(stereo->type)); +av_log(ctx, log_level, ", view: %s", av_stereo3d_view_name(stereo->view)); +av_log(ctx, log_level, ", primary eye: %s", av_stereo3d_primary_eye_name(stereo->primary_eye)); +if (stereo->baseline) +av_log(ctx, log_level, ", baseline: %"PRIu32"", stereo->baseline); +if (stereo->horizontal_disparity_adjustment.num && stereo->horizontal_disparity_adjustment.den) +av_log(ctx, log_level, ", horizontal_disparity_adjustment: %d/%d", + stereo->horizontal_disparity_adjustment.num, stereo->horizontal_disparity_adjustment.den); +if (stereo->horizontal_field_of_view) +av_log(ctx, log_level, ", horizontal_field_of_view: %"PRIu32"", stereo->horizontal_field_of_view); if (stereo->flags & AV_STEREO3D_FLAG_INVERT) av_log(ctx, log_level, " (inverted)"); -- 2.43.0 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2] avdevice/avfoundation: add external video devices
Am 09.06.24 um 21:51 schrieb Theo Fabi: Video devices categorized by AVFoundation as 'AVCaptureDeviceTypeExternal(Unknown)' (like USB video streams) were not recognized by libavdevice. Signed-off-by: Theo Fabi --- libavdevice/avfoundation.m | 3 +++ 1 file changed, 3 insertions(+) Ok. Will push soon. Thanks, Thilo ___ 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] avformat/tls_schannel: forward AVIO_FLAG_NONBLOCK to tcp stream
On 11.06.2024 15:10, Timo Rothenpieler wrote:
On 03.06.2024 22:28, Timo Rothenpieler wrote:
From: BtbN
This is fixed locally
Fixes for example rtmps streaming over schannel.
---
libavformat/tls_schannel.c | 15 ++-
1 file changed, 14 insertions(+), 1 deletion(-)
diff --git a/libavformat/tls_schannel.c b/libavformat/tls_schannel.c
index 214a47a218..7265a9794d 100644
--- a/libavformat/tls_schannel.c
+++ b/libavformat/tls_schannel.c
@@ -113,6 +113,7 @@ static int tls_shutdown_client(URLContext *h)
c->request_flags, 0, 0,
NULL, 0, &c->ctxt_handle,
&outbuf_desc,
&c->context_flags, &c->ctxt_timestamp);
if (sspi_ret == SEC_E_OK || sspi_ret ==
SEC_I_CONTEXT_EXPIRED) {
+ s->tcp->flags &= ~AVIO_FLAG_NONBLOCK;
ret = ffurl_write(s->tcp, outbuf.pvBuffer,
outbuf.cbBuffer);
FreeContextBuffer(outbuf.pvBuffer);
if (ret < 0 || ret != outbuf.cbBuffer)
@@ -316,6 +317,7 @@ static int tls_client_handshake(URLContext *h)
goto fail;
}
+ s->tcp->flags &= ~AVIO_FLAG_NONBLOCK;
ret = ffurl_write(s->tcp, outbuf.pvBuffer, outbuf.cbBuffer);
FreeContextBuffer(outbuf.pvBuffer);
if (ret < 0 || ret != outbuf.cbBuffer) {
@@ -416,11 +418,16 @@ static int tls_read(URLContext *h, uint8_t *buf,
int len)
}
}
+ s->tcp->flags &= ~AVIO_FLAG_NONBLOCK;
+ s->tcp->flags |= h->flags & AVIO_FLAG_NONBLOCK;
+
ret = ffurl_read(s->tcp, c->enc_buf + c->enc_buf_offset,
c->enc_buf_size - c->enc_buf_offset);
if (ret == AVERROR_EOF) {
c->connection_closed = 1;
ret = 0;
+ } else if (ret == AVERROR(EAGAIN)) {
+ ret = 0;
} else if (ret < 0) {
av_log(h, AV_LOG_ERROR, "Unable to read from socket\n");
return ret;
@@ -564,8 +571,14 @@ static int tls_write(URLContext *h, const uint8_t
*buf, int len)
sspi_ret = EncryptMessage(&c->ctxt_handle, 0, &outbuf_desc, 0);
if (sspi_ret == SEC_E_OK) {
len = outbuf[0].cbBuffer + outbuf[1].cbBuffer +
outbuf[2].cbBuffer;
+
+ s->tcp->flags &= ~AVIO_FLAG_NONBLOCK;
+ s->tcp->flags |= h->flags & AVIO_FLAG_NONBLOCK;
+
ret = ffurl_write(s->tcp, data, len);
- if (ret < 0 || ret != len) {
+ if (ret == AVERROR(EAGAIN)) {
+ goto done;
+ } else if (ret < 0 || ret != len) {
ret = AVERROR(EIO);
av_log(h, AV_LOG_ERROR, "Writing encrypted data to
socket failed\n");
goto done;
ping
I'm specifically unsure if implementing the sending-side like this is
valid and would appreciate review from someone familiar with the code
and schannel.
ping
___
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] avformat/tls_schannel: forward AVIO_FLAG_NONBLOCK to tcp stream
On 2024-06-18 10:00 pm, Timo Rothenpieler wrote:
On 11.06.2024 15:10, Timo Rothenpieler wrote:
On 03.06.2024 22:28, Timo Rothenpieler wrote:
From: BtbN
This is fixed locally
Fixes for example rtmps streaming over schannel.
---
libavformat/tls_schannel.c | 15 ++-
1 file changed, 14 insertions(+), 1 deletion(-)
diff --git a/libavformat/tls_schannel.c b/libavformat/tls_schannel.c
index 214a47a218..7265a9794d 100644
--- a/libavformat/tls_schannel.c
+++ b/libavformat/tls_schannel.c
@@ -113,6 +113,7 @@ static int tls_shutdown_client(URLContext *h)
c->request_flags, 0, 0, NULL, 0, &c->ctxt_handle,
&outbuf_desc, &c->context_flags, &c->ctxt_timestamp);
if (sspi_ret == SEC_E_OK || sspi_ret ==
SEC_I_CONTEXT_EXPIRED) {
+ s->tcp->flags &= ~AVIO_FLAG_NONBLOCK;
ret = ffurl_write(s->tcp, outbuf.pvBuffer,
outbuf.cbBuffer);
FreeContextBuffer(outbuf.pvBuffer);
if (ret < 0 || ret != outbuf.cbBuffer)
@@ -316,6 +317,7 @@ static int tls_client_handshake(URLContext *h)
goto fail;
}
+ s->tcp->flags &= ~AVIO_FLAG_NONBLOCK;
ret = ffurl_write(s->tcp, outbuf.pvBuffer, outbuf.cbBuffer);
FreeContextBuffer(outbuf.pvBuffer);
if (ret < 0 || ret != outbuf.cbBuffer) {
@@ -416,11 +418,16 @@ static int tls_read(URLContext *h, uint8_t
*buf, int len)
}
}
+ s->tcp->flags &= ~AVIO_FLAG_NONBLOCK;
+ s->tcp->flags |= h->flags & AVIO_FLAG_NONBLOCK;
+
ret = ffurl_read(s->tcp, c->enc_buf + c->enc_buf_offset,
c->enc_buf_size - c->enc_buf_offset);
if (ret == AVERROR_EOF) {
c->connection_closed = 1;
ret = 0;
+ } else if (ret == AVERROR(EAGAIN)) {
+ ret = 0;
} else if (ret < 0) {
av_log(h, AV_LOG_ERROR, "Unable to read from socket\n");
return ret;
@@ -564,8 +571,14 @@ static int tls_write(URLContext *h, const
uint8_t *buf, int len)
sspi_ret = EncryptMessage(&c->ctxt_handle, 0, &outbuf_desc, 0);
if (sspi_ret == SEC_E_OK) {
len = outbuf[0].cbBuffer + outbuf[1].cbBuffer +
outbuf[2].cbBuffer;
+
+ s->tcp->flags &= ~AVIO_FLAG_NONBLOCK;
+ s->tcp->flags |= h->flags & AVIO_FLAG_NONBLOCK;
+
ret = ffurl_write(s->tcp, data, len);
- if (ret < 0 || ret != len) {
+ if (ret == AVERROR(EAGAIN)) {
+ goto done;
+ } else if (ret < 0 || ret != len) {
ret = AVERROR(EIO);
av_log(h, AV_LOG_ERROR, "Writing encrypted data to
socket failed\n");
goto done;
ping
I'm specifically unsure if implementing the sending-side like this is
valid and would appreciate review from someone familiar with the code
and schannel.
FWIW, I had to do the same for securetransport on a project a couple of
years back to get rtmps working. Worked fine, and did not get any
reports of ill-effects.
Regards,
Gyan
___
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/7] avcodec/utils: apply the same alignment to YUV410 as we do to YUV420 when motion estimation is used
Michael Niedermayer:
> The snow encoder uses block based motion estimation which can read out of
> array if
> insufficient alignment is used
>
> Fixes: out of array access
> Fixes:
> 68963/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_SNOW_fuzzer-4979988435632128
> Fixes:
> 68969/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_SNOW_fuzzer-6239933667803136.fuzz
>
> Found-by: continuous fuzzing process
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by: Michael Niedermayer
> ---
> libavcodec/utils.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/libavcodec/utils.c b/libavcodec/utils.c
> index 337c00e789a..7914f799041 100644
> --- a/libavcodec/utils.c
> +++ b/libavcodec/utils.c
> @@ -259,6 +259,9 @@ void avcodec_align_dimensions2(AVCodecContext *s, int
> *width, int *height,
> if (s->codec_id == AV_CODEC_ID_SVQ1) {
> w_align = 64;
> h_align = 64;
> +} else if (s->codec_id == AV_CODEC_ID_SNOW) {
> +w_align = 16;
> +h_align = 16;
> }
> break;
> case AV_PIX_FMT_RGB555:
avcodec_align_dimensions2() is for decoders and happens to be used by
ff_encode_alloc_frame(), too. But decoders should not be required to add
more padding because the decoder needs more. Instead the encoder should
add more padding itself (by using more than 2 * EDGE_WIDTH).
- Andreas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2 4/4] swscale/aarch64: add neon {lum, chr}ConvertRange
On Tue, Jun 11, 2024 at 2:29 PM Ramiro Polla wrote:
>
> chrRangeFromJpeg_8_c: 29.2
> chrRangeFromJpeg_8_neon: 19.5
> chrRangeFromJpeg_24_c: 80.5
> chrRangeFromJpeg_24_neon: 34.0
> chrRangeFromJpeg_128_c: 413.7
> chrRangeFromJpeg_128_neon: 156.0
> chrRangeFromJpeg_144_c: 471.0
> chrRangeFromJpeg_144_neon: 174.2
> chrRangeFromJpeg_256_c: 842.0
> chrRangeFromJpeg_256_neon: 305.5
> chrRangeFromJpeg_512_c: 1699.0
> chrRangeFromJpeg_512_neon: 608.0
> chrRangeToJpeg_8_c: 51.7
> chrRangeToJpeg_8_neon: 22.7
> chrRangeToJpeg_24_c: 149.7
> chrRangeToJpeg_24_neon: 38.0
> chrRangeToJpeg_128_c: 761.7
> chrRangeToJpeg_128_neon: 176.7
> chrRangeToJpeg_144_c: 866.2
> chrRangeToJpeg_144_neon: 198.7
> chrRangeToJpeg_256_c: 1516.5
> chrRangeToJpeg_256_neon: 348.7
> chrRangeToJpeg_512_c: 3067.2
> chrRangeToJpeg_512_neon: 692.7
> lumRangeFromJpeg_8_c: 24.0
> lumRangeFromJpeg_8_neon: 17.0
> lumRangeFromJpeg_24_c: 56.7
> lumRangeFromJpeg_24_neon: 21.0
> lumRangeFromJpeg_128_c: 294.5
> lumRangeFromJpeg_128_neon: 76.7
> lumRangeFromJpeg_144_c: 332.5
> lumRangeFromJpeg_144_neon: 86.7
> lumRangeFromJpeg_256_c: 586.0
> lumRangeFromJpeg_256_neon: 152.2
> lumRangeFromJpeg_512_c: 1190.0
> lumRangeFromJpeg_512_neon: 298.0
> lumRangeToJpeg_8_c: 31.7
> lumRangeToJpeg_8_neon: 19.5
> lumRangeToJpeg_24_c: 83.5
> lumRangeToJpeg_24_neon: 24.2
> lumRangeToJpeg_128_c: 440.5
> lumRangeToJpeg_128_neon: 91.0
> lumRangeToJpeg_144_c: 504.2
> lumRangeToJpeg_144_neon: 101.0
> lumRangeToJpeg_256_c: 879.7
> lumRangeToJpeg_256_neon: 177.2
> lumRangeToJpeg_512_c: 1794.2
> lumRangeToJpeg_512_neon: 354.0
> ---
> libswscale/aarch64/Makefile | 1 +
> libswscale/aarch64/range_convert_neon.S | 99 +
> libswscale/aarch64/swscale.c| 21 ++
> libswscale/swscale_internal.h | 1 +
> libswscale/utils.c | 4 +-
> 5 files changed, 125 insertions(+), 1 deletion(-)
> create mode 100644 libswscale/aarch64/range_convert_neon.S
>
> diff --git a/libswscale/aarch64/Makefile b/libswscale/aarch64/Makefile
> index adfd90a1b6..37ad960619 100644
> --- a/libswscale/aarch64/Makefile
> +++ b/libswscale/aarch64/Makefile
> @@ -5,5 +5,6 @@ OBJS+= aarch64/rgb2rgb.o\
> NEON-OBJS += aarch64/hscale.o \
> aarch64/input.o \
> aarch64/output.o \
> + aarch64/range_convert_neon.o \
> aarch64/rgb2rgb_neon.o \
> aarch64/yuv2rgb_neon.o \
> diff --git a/libswscale/aarch64/range_convert_neon.S
> b/libswscale/aarch64/range_convert_neon.S
> new file mode 100644
> index 00..ea56dc2e32
> --- /dev/null
> +++ b/libswscale/aarch64/range_convert_neon.S
> @@ -0,0 +1,99 @@
> +/*
> + * Copyright (c) 2024 Ramiro Polla
> + *
> + * This file is part of FFmpeg.
> + *
> + * FFmpeg is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU Lesser General Public
> + * License as published by the Free Software Foundation; either
> + * version 2.1 of the License, or (at your option) any later version.
> + *
> + * FFmpeg is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
> + * Lesser General Public License for more details.
> + *
> + * You should have received a copy of the GNU Lesser General Public
> + * License along with FFmpeg; if not, write to the Free Software
> + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301
> USA
> + */
> +
> +#include "libavutil/aarch64/asm.S"
> +
> +.macro lumConvertRange name, max, mult, offset, shift
> +function ff_\name, export=1
> +.if \max != 0
> +mov w3, #\max
> +dup v24.8h, w3
> +.endif
> +mov w3, #\mult
> +dup v25.4s, w3
> +movzw3, \offset & 0x
> +movkw3, (\offset >> 16) & 0x, lsl #16
> +dup v26.4s, w3
> +1:
> +ld1 {v0.8h}, [x0]
> +.if \max != 0
> +sminv0.8h, v0.8h, v24.8h
> +.endif
> +mov v16.16b, v26.16b
> +mov v18.16b, v26.16b
> +sxtlv20.4s, v0.4h
> +sxtl2 v22.4s, v0.8h
> +mla v16.4s, v20.4s, v25.4s
> +mla v18.4s, v22.4s, v25.4s
> +shrnv0.4h, v16.4s, #\shift
> +shrn2 v0.8h, v18.4s, #\shift
> +subsw1, w1, #8
> +st1 {v0.8h}, [x0], #16
> +b.gt1b
> +ret
> +endfunc
> +.endm
> +
> +.macro chrConvertRange name, max, mult, offset, shift
> +function ff_\name, export=1
> +.if \max != 0
> +mov w3, #\max
> +dup v24.8h, w3
> +.endif
> +mov w3, #\mult
> +dup
Re: [FFmpeg-devel] [PATCH] avformat/tls_schannel: forward AVIO_FLAG_NONBLOCK to tcp stream
On 18.06.2024 18:56, Gyan Doshi wrote: FWIW, I had to do the same for securetransport on a project a couple of years back to get rtmps working. Worked fine, and did not get any reports of ill-effects. You mean the FFmpeg implementation of rtmps? Cause if so, I think that only makes use of nonblocking mode for receiving, not sending. So it wouldn't run into this if it was wrong. Just making the reading side support non-blocking would definitely also be an option, it would at least fix rtmps. ___ 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] avformat/dump: Print all possible Stereo3D info
On 6/18/2024 12:31 PM, Derek Buitenhuis wrote: Signed-off-by: Derek Buitenhuis --- As requested by James. --- libavformat/dump.c | 9 + 1 file changed, 9 insertions(+) diff --git a/libavformat/dump.c b/libavformat/dump.c index 059fb84522..8e8b9e1959 100644 --- a/libavformat/dump.c +++ b/libavformat/dump.c @@ -260,6 +260,15 @@ static void dump_stereo3d(void *ctx, const AVPacketSideData *sd, int log_level) stereo = (const AVStereo3D *)sd->data; av_log(ctx, log_level, "%s", av_stereo3d_type_name(stereo->type)); +av_log(ctx, log_level, ", view: %s", av_stereo3d_view_name(stereo->view)); +av_log(ctx, log_level, ", primary eye: %s", av_stereo3d_primary_eye_name(stereo->primary_eye)); nit: These three could be combined into a single av_log call. +if (stereo->baseline) +av_log(ctx, log_level, ", baseline: %"PRIu32"", stereo->baseline); +if (stereo->horizontal_disparity_adjustment.num && stereo->horizontal_disparity_adjustment.den) +av_log(ctx, log_level, ", horizontal_disparity_adjustment: %d/%d", + stereo->horizontal_disparity_adjustment.num, stereo->horizontal_disparity_adjustment.den); +if (stereo->horizontal_field_of_view) +av_log(ctx, log_level, ", horizontal_field_of_view: %"PRIu32"", stereo->horizontal_field_of_view); if (stereo->flags & AV_STEREO3D_FLAG_INVERT) av_log(ctx, log_level, " (inverted)"); ___ 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] avformat/dump: Print all possible Stereo3D info
Signed-off-by: Derek Buitenhuis --- libavformat/dump.c | 11 ++- 1 file changed, 10 insertions(+), 1 deletion(-) diff --git a/libavformat/dump.c b/libavformat/dump.c index 059fb84522..61a2c6a29f 100644 --- a/libavformat/dump.c +++ b/libavformat/dump.c @@ -259,7 +259,16 @@ static void dump_stereo3d(void *ctx, const AVPacketSideData *sd, int log_level) stereo = (const AVStereo3D *)sd->data; -av_log(ctx, log_level, "%s", av_stereo3d_type_name(stereo->type)); +av_log(ctx, log_level, "%s, view: %s, primary eye: %s", + av_stereo3d_type_name(stereo->type), av_stereo3d_view_name(stereo->view), + av_stereo3d_primary_eye_name(stereo->primary_eye)); +if (stereo->baseline) +av_log(ctx, log_level, ", baseline: %"PRIu32"", stereo->baseline); +if (stereo->horizontal_disparity_adjustment.num && stereo->horizontal_disparity_adjustment.den) +av_log(ctx, log_level, ", horizontal_disparity_adjustment: %d/%d", + stereo->horizontal_disparity_adjustment.num, stereo->horizontal_disparity_adjustment.den); +if (stereo->horizontal_field_of_view) +av_log(ctx, log_level, ", horizontal_field_of_view: %"PRIu32"", stereo->horizontal_field_of_view); if (stereo->flags & AV_STEREO3D_FLAG_INVERT) av_log(ctx, log_level, " (inverted)"); -- 2.43.0 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avformat/dump: Print all possible Stereo3D info
On 6/18/2024 7:34 PM, James Almer wrote: > nit: These three could be combined into a single av_log call. v2 sent. - Derek ___ 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/dump: Print all possible Stereo3D info
On 6/18/2024 3:55 PM, Derek Buitenhuis wrote: Signed-off-by: Derek Buitenhuis --- libavformat/dump.c | 11 ++- 1 file changed, 10 insertions(+), 1 deletion(-) diff --git a/libavformat/dump.c b/libavformat/dump.c index 059fb84522..61a2c6a29f 100644 --- a/libavformat/dump.c +++ b/libavformat/dump.c @@ -259,7 +259,16 @@ static void dump_stereo3d(void *ctx, const AVPacketSideData *sd, int log_level) stereo = (const AVStereo3D *)sd->data; -av_log(ctx, log_level, "%s", av_stereo3d_type_name(stereo->type)); +av_log(ctx, log_level, "%s, view: %s, primary eye: %s", + av_stereo3d_type_name(stereo->type), av_stereo3d_view_name(stereo->view), + av_stereo3d_primary_eye_name(stereo->primary_eye)); +if (stereo->baseline) +av_log(ctx, log_level, ", baseline: %"PRIu32"", stereo->baseline); +if (stereo->horizontal_disparity_adjustment.num && stereo->horizontal_disparity_adjustment.den) +av_log(ctx, log_level, ", horizontal_disparity_adjustment: %d/%d", + stereo->horizontal_disparity_adjustment.num, stereo->horizontal_disparity_adjustment.den); +if (stereo->horizontal_field_of_view) +av_log(ctx, log_level, ", horizontal_field_of_view: %"PRIu32"", stereo->horizontal_field_of_view); if (stereo->flags & AV_STEREO3D_FLAG_INVERT) av_log(ctx, log_level, " (inverted)"); LGTM. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] ffprobe: always print all Stereo3D fields
ffprobe is meant to generate parseable output, and if a field is present, it
should be printed even if it has a default value.
Signed-off-by: James Almer
---
fftools/ffprobe.c| 9 +++--
tests/ref/fate/matroska-spherical-mono | 3 +++
tests/ref/fate/matroska-spherical-mono-remux | 6 ++
tests/ref/fate/matroska-stereo_mode | 12
tests/ref/fate/matroska-vp8-alpha-remux | 3 +++
5 files changed, 27 insertions(+), 6 deletions(-)
diff --git a/fftools/ffprobe.c b/fftools/ffprobe.c
index a814cb5ade..d7ba980ff9 100644
--- a/fftools/ffprobe.c
+++ b/fftools/ffprobe.c
@@ -2546,12 +2546,9 @@ static void print_pkt_side_data(WriterContext *w,
print_int("inverted", !!(stereo->flags & AV_STEREO3D_FLAG_INVERT));
print_str("view", av_stereo3d_view_name(stereo->view));
print_str("primary_eye",
av_stereo3d_primary_eye_name(stereo->primary_eye));
-if (stereo->baseline)
-print_int("baseline", stereo->baseline);
-if (stereo->horizontal_disparity_adjustment.num &&
stereo->horizontal_disparity_adjustment.den)
-print_q("horizontal_disparity_adjustment",
stereo->horizontal_disparity_adjustment, '/');
-if (stereo->horizontal_field_of_view)
-print_int("horizontal_field_of_view",
stereo->horizontal_field_of_view);
+print_int("baseline", stereo->baseline);
+print_q("horizontal_disparity_adjustment",
stereo->horizontal_disparity_adjustment, '/');
+print_int("horizontal_field_of_view",
stereo->horizontal_field_of_view);
} else if (sd->type == AV_PKT_DATA_SPHERICAL) {
const AVSphericalMapping *spherical = (AVSphericalMapping
*)sd->data;
print_str("projection",
av_spherical_projection_name(spherical->projection));
diff --git a/tests/ref/fate/matroska-spherical-mono
b/tests/ref/fate/matroska-spherical-mono
index 08b94e455b..c52ca8e7ee 100644
--- a/tests/ref/fate/matroska-spherical-mono
+++ b/tests/ref/fate/matroska-spherical-mono
@@ -5,6 +5,9 @@ type=2D
inverted=0
view=packed
primary_eye=none
+baseline=0
+horizontal_disparity_adjustment=0/0
+horizontal_field_of_view=0
[/SIDE_DATA]
[SIDE_DATA]
side_data_type=Spherical Mapping
diff --git a/tests/ref/fate/matroska-spherical-mono-remux
b/tests/ref/fate/matroska-spherical-mono-remux
index 0ca77c8074..10b92d5f2e 100644
--- a/tests/ref/fate/matroska-spherical-mono-remux
+++ b/tests/ref/fate/matroska-spherical-mono-remux
@@ -29,6 +29,9 @@ type=2D
inverted=0
view=packed
primary_eye=none
+baseline=0
+horizontal_disparity_adjustment=0/0
+horizontal_field_of_view=0
[/SIDE_DATA]
[SIDE_DATA]
side_data_type=Spherical Mapping
@@ -55,6 +58,9 @@ type=2D
inverted=0
view=packed
primary_eye=none
+baseline=0
+horizontal_disparity_adjustment=0/0
+horizontal_field_of_view=0
[/SIDE_DATA]
[SIDE_DATA]
side_data_type=Spherical Mapping
diff --git a/tests/ref/fate/matroska-stereo_mode
b/tests/ref/fate/matroska-stereo_mode
index 13bce13cb8..a1aab1e38e 100644
--- a/tests/ref/fate/matroska-stereo_mode
+++ b/tests/ref/fate/matroska-stereo_mode
@@ -134,6 +134,9 @@ type=side by side
inverted=0
view=packed
primary_eye=none
+baseline=0
+horizontal_disparity_adjustment=0/0
+horizontal_field_of_view=0
[/SIDE_DATA]
[/STREAM]
[STREAM]
@@ -151,6 +154,9 @@ type=top and bottom
inverted=1
view=packed
primary_eye=none
+baseline=0
+horizontal_disparity_adjustment=0/0
+horizontal_field_of_view=0
[/SIDE_DATA]
[/STREAM]
[STREAM]
@@ -166,6 +172,9 @@ type=interleaved lines
inverted=1
view=packed
primary_eye=none
+baseline=0
+horizontal_disparity_adjustment=0/0
+horizontal_field_of_view=0
[/SIDE_DATA]
[/STREAM]
[STREAM]
@@ -182,6 +191,9 @@ type=interleaved columns
inverted=1
view=packed
primary_eye=none
+baseline=0
+horizontal_disparity_adjustment=0/0
+horizontal_field_of_view=0
[/SIDE_DATA]
[/STREAM]
[STREAM]
diff --git a/tests/ref/fate/matroska-vp8-alpha-remux
b/tests/ref/fate/matroska-vp8-alpha-remux
index e54304cafd..ea8a089cec 100644
--- a/tests/ref/fate/matroska-vp8-alpha-remux
+++ b/tests/ref/fate/matroska-vp8-alpha-remux
@@ -37,5 +37,8 @@ type=2D
inverted=0
view=packed
primary_eye=none
+baseline=0
+horizontal_disparity_adjustment=0/0
+horizontal_field_of_view=0
[/SIDE_DATA]
[/STREAM]
--
2.45.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avutil/timestamp: avoid possible FPE when 0 is passed to av_ts_make_time_string2()
On Tue, 18 Jun 2024, Rémi Denis-Courmont wrote:
Le 17 juin 2024 22:33:01 GMT+02:00, Marton Balint a écrit :
Signed-off-by: Marton Balint
---
libavutil/timestamp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavutil/timestamp.c b/libavutil/timestamp.c
index 2a3e3012a4..6c231a517d 100644
--- a/libavutil/timestamp.c
+++ b/libavutil/timestamp.c
@@ -24,7 +24,7 @@ char *av_ts_make_time_string2(char *buf, int64_t ts,
AVRational tb)
snprintf(buf, AV_TS_MAX_STRING_SIZE, "NOPTS");
} else {
double val = av_q2d(tb) * ts;
-double log = floor(log10(fabs(val)));
+double log = (fpclassify(val) == FP_ZERO ? -INFINITY :
floor(log10(fabs(val;
int precision = (isfinite(log) && log < 0) ? -log + 5 : 6;
Can the log be infinite anymore?
Yes, in case of zero value we explicitly set it to -INFINITY, but implicit
infinity or NaN is also possible, because av_q2d can return both.
Regards,
Marton
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 1/3] avutil/ambient_viewing_environment: set a sane default value for AVRational fields
Prevent potential divisions by 0 when using them immediately after allocation.
Signed-off-by: James Almer
---
libavutil/ambient_viewing_environment.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/libavutil/ambient_viewing_environment.c
b/libavutil/ambient_viewing_environment.c
index c47458cfa8..e359727776 100644
--- a/libavutil/ambient_viewing_environment.c
+++ b/libavutil/ambient_viewing_environment.c
@@ -21,6 +21,13 @@
#include "ambient_viewing_environment.h"
#include "mem.h"
+static void get_defaults(AVAmbientViewingEnvironment *env)
+{
+env->ambient_illuminance =
+env->ambient_light_x =
+env->ambient_light_y = (AVRational) { 0, 1 };
+}
+
AVAmbientViewingEnvironment *av_ambient_viewing_environment_alloc(size_t *size)
{
AVAmbientViewingEnvironment *env =
@@ -28,6 +35,8 @@ AVAmbientViewingEnvironment
*av_ambient_viewing_environment_alloc(size_t *size)
if (!env)
return NULL;
+get_defaults(env);
+
if (size)
*size = sizeof(*env);
@@ -44,6 +53,7 @@ AVAmbientViewingEnvironment
*av_ambient_viewing_environment_create_side_data(AVF
return NULL;
memset(side_data->data, 0, side_data->size);
+get_defaults((AVAmbientViewingEnvironment *)side_data->data);
return (AVAmbientViewingEnvironment *)side_data->data;
}
--
2.45.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 2/3] avutil/mastering_display_metadata: set a sane default value for AVRational fields
Prevent potential divisions by 0 when using them immediately after allocation.
Signed-off-by: James Almer
---
libavutil/mastering_display_metadata.c | 18 --
1 file changed, 16 insertions(+), 2 deletions(-)
diff --git a/libavutil/mastering_display_metadata.c
b/libavutil/mastering_display_metadata.c
index ea41f13f9d..73a36c661e 100644
--- a/libavutil/mastering_display_metadata.c
+++ b/libavutil/mastering_display_metadata.c
@@ -25,9 +25,15 @@
#include "mastering_display_metadata.h"
#include "mem.h"
-AVMasteringDisplayMetadata *av_mastering_display_metadata_alloc(void)
+static void get_defaults(AVMasteringDisplayMetadata *mastering)
{
-return av_mallocz(sizeof(AVMasteringDisplayMetadata));
+for (int i = 0; i < 3; i++)
+for (int j = 0; j < 2; j++)
+mastering->display_primaries[i][j] = (AVRational) { 0, 1 };
+mastering->white_point[0] =
+mastering->white_point[1] =
+mastering->min_luminance =
+mastering->max_luminance = (AVRational) { 0, 1 };
}
AVMasteringDisplayMetadata *av_mastering_display_metadata_alloc_size(size_t
*size)
@@ -36,12 +42,19 @@ AVMasteringDisplayMetadata
*av_mastering_display_metadata_alloc_size(size_t *siz
if (!mastering)
return NULL;
+get_defaults(mastering);
+
if (size)
*size = sizeof(*mastering);
return mastering;
}
+AVMasteringDisplayMetadata *av_mastering_display_metadata_alloc(void)
+{
+return av_mastering_display_metadata_alloc_size(NULL);
+}
+
AVMasteringDisplayMetadata
*av_mastering_display_metadata_create_side_data(AVFrame *frame)
{
AVFrameSideData *side_data = av_frame_new_side_data(frame,
@@ -51,6 +64,7 @@ AVMasteringDisplayMetadata
*av_mastering_display_metadata_create_side_data(AVFra
return NULL;
memset(side_data->data, 0, sizeof(AVMasteringDisplayMetadata));
+get_defaults((AVMasteringDisplayMetadata *)side_data->data);
return (AVMasteringDisplayMetadata *)side_data->data;
}
--
2.45.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 3/3] avutil/stereo3d: set a sane default value for AVRational fields
Prevent potential divisions by 0 when using them immediately after allocation.
Signed-off-by: James Almer
---
libavutil/stereo3d.c | 14 +-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/libavutil/stereo3d.c b/libavutil/stereo3d.c
index a40a9439bb..19e81e4124 100644
--- a/libavutil/stereo3d.c
+++ b/libavutil/stereo3d.c
@@ -26,9 +26,20 @@
#include "mem.h"
#include "stereo3d.h"
+static void get_defaults(AVStereo3D *stereo)
+{
+stereo->horizontal_disparity_adjustment = (AVRational) { 0, 1 };
+}
+
AVStereo3D *av_stereo3d_alloc(void)
{
-return av_mallocz(sizeof(AVStereo3D));
+AVStereo3D *stereo = av_mallocz(sizeof(AVStereo3D));
+if (!stereo)
+return NULL;
+
+get_defaults(stereo);
+
+return stereo;
}
AVStereo3D *av_stereo3d_create_side_data(AVFrame *frame)
@@ -40,6 +51,7 @@ AVStereo3D *av_stereo3d_create_side_data(AVFrame *frame)
return NULL;
memset(side_data->data, 0, sizeof(AVStereo3D));
+get_defaults((AVStereo3D *)side_data->data);
return (AVStereo3D *)side_data->data;
}
--
2.45.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v3 0/5] avcodec/dovi - disable metadata compression by default
On Thu, 23 May 2024 19:50:23 + Cosmin Stejerean via ffmpeg-devel wrote: > From: Cosmin Stejerean > > not all clients support metadata compression, output when > vdr_dm_metadata_changed fails the DV verifier. > > Compared to v2 this makes the dovi field name a parameter of the > DOVI_ENCODING_OPTS macro as requested. It also splits up the commits into > introducing the macro, guarding compression by it, and then leveraging it in > the encoder. > > I split up each encoder into a separate patch since the original support was > added in separate patches but this could also be squashed when applying if > that's better. > > Cosmin Stejerean (5): > avcodec/dovi_rpu - add field to disable metadata compression > avcodec/dovi_rpuenc - guard metadata compression by enable_compression > avcodec/libaomenc - switch DolbyVision options to DOVI_ENCODING_OPTS > avcodec/libsvtav1 - switch DolbyVision options to DOVI_ENCODING_OPTS > avcodec/libx265 - switch DolbyVision options to DOVI_ENCODING_OPTS > > libavcodec/dovi_rpu.h| 10 ++ > libavcodec/dovi_rpuenc.c | 8 ++-- > libavcodec/libaomenc.c | 3 +-- > libavcodec/libsvtav1.c | 3 +-- > libavcodec/libx265.c | 3 +-- > 5 files changed, 19 insertions(+), 8 deletions(-) > > -- > 2.42.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". I suppose this series is redundant now with the compression changes from my BSF patchset? Unless we want to preserve the macro for purely stylistic reasons, but we can probably stomach the duplication of only a single option field. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v3 0/2] avcodec/dovi - correctly read el_bit_depth_minus8 and ext_mapping_idc
On Wed, 22 May 2024 15:50:34 + Cosmin Stejerean via ffmpeg-devel wrote: > From: Cosmin Stejerean > > Some DolbyVision samples fail to parse currently due to mis-reading the > el_bit_depth_minus8 field. Upon investigation it seems that the RPU syntax has > been extended in an as of yet undocumented way by adding ext_mapping_idc and > coding it together with el_bit_depth_minus8 together into a single 16 bit > integer with the upper 8 bits for ext_mapping_idc and the lower 8 bits for > el_bit_depth_minus8. > > This can be observed in the output of the DoVi verifier, which shows how this > is laid out. This patchset adds the new fields to dovi_meta and implements the > code to parse and write this back out. > > Compared to the previous version it moves the fields to the end for ABI > compatibility, bumps the minor version in lavu and splits this into a separate > commit. > > Cosmin Stejerean (2): > lavu/dovi_meta - add fields for ext_mapping_idc > avcodec/dovi - correctly read el_bit_depth_minus8 and ext_mapping_idc > > libavcodec/dovi_rpudec.c | 7 ++- > libavcodec/dovi_rpuenc.c | 4 +++- > libavutil/dovi_meta.h| 2 ++ > libavutil/version.h | 2 +- > 4 files changed, 12 insertions(+), 3 deletions(-) > > -- > 2.42.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". As discussed on IRC, this needs an extra patch to update the `last field` entry in `dovi_rpu.c`. Apart from that, LGTM. Will apply tomorrow (with the mentioned change) if there is no objection. ___ 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 0/8] DoVi metadata compression
Moves metadata compression out of the codecs and into a bitstream filter. This is required by design, because keyframes must have compression disabled (for obvious reasons). Therefore, we _must_ generate the dolby vision RPUs after encoding. The downside of this approach is that it requires "redundantly" encoding + decoding RPUs in between the codec and the bsf. However, the tradeoff is that it allows us to also strip/modify DV metadata when not transcoding (-c:v copy). Such a feature has a legitimate use case, as it allows enabling/disabling Dolby Vision compression on existing streams (to e.g. minimize size, or to maximize compatibility). If we wanted to avoid this overhead, we could hypothetically introduce a new packet side data type for dolby vision metadata, and have the codec merely copy the frame side data to the packet. But I am somewhat unwilling to add yet more packet side data types that are aliases of frame side data types, and I don't think the overhead is significant. ___ 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/8] avcodec/dovi_rpudec: clarify semantics
From: Niklas Haas
ff_dovi_rpu_parse() and ff_dovi_rpu_generate() are a bit inconsistent in
that they expect different levels of encapsulation, due to the nature of
how this is handled in the context of different APIs. Clarify the status
quo. (And fix an incorrect reference to the RPU payload bytes as 'RBSP')
---
libavcodec/dovi_rpu.h| 5 +++--
libavcodec/dovi_rpudec.c | 2 +-
2 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/libavcodec/dovi_rpu.h b/libavcodec/dovi_rpu.h
index bfb118d6b5..205d16ffbc 100644
--- a/libavcodec/dovi_rpu.h
+++ b/libavcodec/dovi_rpu.h
@@ -95,8 +95,9 @@ void ff_dovi_ctx_unref(DOVIContext *s);
void ff_dovi_ctx_flush(DOVIContext *s);
/**
- * Parse the contents of a Dovi RPU NAL and update the parsed values in the
- * DOVIContext struct.
+ * Parse the contents of a Dolby Vision RPU and update the parsed values in the
+ * DOVIContext struct. This function should receive the decoded unit payload,
+ * without any T.35 or NAL unit headers.
*
* Returns 0 or an error code.
*
diff --git a/libavcodec/dovi_rpudec.c b/libavcodec/dovi_rpudec.c
index cae4dc4c3c..b34c3116b7 100644
--- a/libavcodec/dovi_rpudec.c
+++ b/libavcodec/dovi_rpudec.c
@@ -360,7 +360,7 @@ int ff_dovi_rpu_parse(DOVIContext *s, const uint8_t *rpu,
size_t rpu_size,
emdf_protection = get_bits(gb, 5 + 12);
VALIDATE(emdf_protection, 0x400, 0x400);
} else {
-/* NAL RBSP with prefix and trailing zeroes */
+/* NAL unit with prefix and trailing zeroes */
VALIDATE(rpu[0], 25, 25); /* NAL prefix */
rpu++;
rpu_size--;
--
2.45.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/8] avcodec/dovi_rpuenc: also copy ext blocks to dovi ctx
From: Niklas Haas
As the comment implies, DOVIContext.ext_blocks should also reflect the
current state after ff_dovi_rpu_generate().
Fluff for now, but will be needed once we start implementing metadata
compression for extension blocks as well.
---
libavcodec/dovi_rpuenc.c | 12
1 file changed, 12 insertions(+)
diff --git a/libavcodec/dovi_rpuenc.c b/libavcodec/dovi_rpuenc.c
index a6262844d4..45fcd9a86c 100644
--- a/libavcodec/dovi_rpuenc.c
+++ b/libavcodec/dovi_rpuenc.c
@@ -506,6 +506,12 @@ int ff_dovi_rpu_generate(DOVIContext *s, const
AVDOVIMetadata *metadata,
}
}
+if (metadata->num_ext_blocks && !s->ext_blocks) {
+s->ext_blocks = ff_refstruct_allocz(sizeof(AVDOVIDmData) *
AV_DOVI_MAX_EXT_BLOCKS);
+if (!s->ext_blocks)
+return AVERROR(ENOMEM);
+}
+
vdr_dm_metadata_present = memcmp(color, &ff_dovi_color_default,
sizeof(*color));
use_prev_vdr_rpu = !memcmp(s->vdr[vdr_rpu_id], mapping, sizeof(*mapping));
if (num_ext_blocks_v1 || num_ext_blocks_v2)
@@ -635,6 +641,7 @@ int ff_dovi_rpu_generate(DOVIContext *s, const
AVDOVIMetadata *metadata,
}
if (vdr_dm_metadata_present) {
+size_t ext_sz;
const int denom = profile == 4 ? (1 << 30) : (1 << 28);
set_ue_golomb(pb, color->dm_metadata_id); /* affected_dm_id */
set_ue_golomb(pb, color->dm_metadata_id); /* current_dm_id */
@@ -672,6 +679,11 @@ int ff_dovi_rpu_generate(DOVIContext *s, const
AVDOVIMetadata *metadata,
for (int i = 0; i < metadata->num_ext_blocks; i++)
generate_ext_v2(pb, av_dovi_get_ext(metadata, i));
}
+
+ext_sz = FFMIN(sizeof(AVDOVIDmData), metadata->ext_block_size);
+for (int i = 0; i < metadata->num_ext_blocks; i++)
+memcpy(&s->ext_blocks[i], av_dovi_get_ext(metadata, i), ext_sz);
+s->num_ext_blocks = metadata->num_ext_blocks;
} else {
s->color = &ff_dovi_color_default;
s->num_ext_blocks = 0;
--
2.45.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 3/8] avcodec/dovi_rpuenc: try to re-use existing vdr_rpu_id
From: Niklas Haas
And only override it if we either have an exact match, or if we still
have unused metadata slots (to avoid an overwrite).
---
libavcodec/dovi_rpuenc.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavcodec/dovi_rpuenc.c b/libavcodec/dovi_rpuenc.c
index 45fcd9a86c..0d49a128fd 100644
--- a/libavcodec/dovi_rpuenc.c
+++ b/libavcodec/dovi_rpuenc.c
@@ -463,12 +463,12 @@ int ff_dovi_rpu_generate(DOVIContext *s, const
AVDOVIMetadata *metadata,
return AVERROR_INVALIDDATA;
}
-vdr_rpu_id = -1;
+vdr_rpu_id = mapping->vdr_rpu_id;
for (int i = 0; i <= DOVI_MAX_DM_ID; i++) {
if (s->vdr[i] && !memcmp(s->vdr[i], mapping, sizeof(*mapping))) {
vdr_rpu_id = i;
break;
-} else if (vdr_rpu_id < 0 && (!s->vdr[i] || i == DOVI_MAX_DM_ID)) {
+} else if (s->vdr[vdr_rpu_id] && !s->vdr[i]) {
vdr_rpu_id = i;
}
}
--
2.45.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 4/8] avcodec/dovi_rpuenc: add `flags` to ff_dovi_rpu_generate()
From: Niklas Haas
Will be used to control compression, encapsulation etc.
---
libavcodec/dovi_rpu.h| 2 +-
libavcodec/dovi_rpuenc.c | 2 +-
libavcodec/libaomenc.c | 2 +-
libavcodec/libsvtav1.c | 2 +-
libavcodec/libx265.c | 3 ++-
5 files changed, 6 insertions(+), 5 deletions(-)
diff --git a/libavcodec/dovi_rpu.h b/libavcodec/dovi_rpu.h
index 205d16ffbc..65a4529106 100644
--- a/libavcodec/dovi_rpu.h
+++ b/libavcodec/dovi_rpu.h
@@ -135,7 +135,7 @@ int ff_dovi_configure(DOVIContext *s, AVCodecContext
*avctx);
* including the EMDF header (profile 10) or NAL encapsulation (otherwise).
*/
int ff_dovi_rpu_generate(DOVIContext *s, const AVDOVIMetadata *metadata,
- uint8_t **out_rpu, int *out_size);
+ int flags, uint8_t **out_rpu, int *out_size);
/***
diff --git a/libavcodec/dovi_rpuenc.c b/libavcodec/dovi_rpuenc.c
index 0d49a128fd..d8f113c5c4 100644
--- a/libavcodec/dovi_rpuenc.c
+++ b/libavcodec/dovi_rpuenc.c
@@ -435,7 +435,7 @@ static void generate_ext_v2(PutBitContext *pb, const
AVDOVIDmData *dm)
}
int ff_dovi_rpu_generate(DOVIContext *s, const AVDOVIMetadata *metadata,
- uint8_t **out_rpu, int *out_size)
+ int flags, uint8_t **out_rpu, int *out_size)
{
PutBitContext *pb = &(PutBitContext){0};
const AVDOVIRpuDataHeader *hdr;
diff --git a/libavcodec/libaomenc.c b/libavcodec/libaomenc.c
index dec74ebecd..aa51c89e29 100644
--- a/libavcodec/libaomenc.c
+++ b/libavcodec/libaomenc.c
@@ -1294,7 +1294,7 @@ FF_ENABLE_DEPRECATION_WARNINGS
const AVDOVIMetadata *metadata = (const AVDOVIMetadata *)sd->data;
uint8_t *t35;
int size;
-if ((res = ff_dovi_rpu_generate(&ctx->dovi, metadata, &t35,
&size)) < 0)
+if ((res = ff_dovi_rpu_generate(&ctx->dovi, metadata, 0, &t35,
&size)) < 0)
return res;
res = aom_img_add_metadata(rawimg, OBU_METADATA_TYPE_ITUT_T35,
t35, size, AOM_MIF_ANY_FRAME);
diff --git a/libavcodec/libsvtav1.c b/libavcodec/libsvtav1.c
index 2fef8c8971..b6db63fd7a 100644
--- a/libavcodec/libsvtav1.c
+++ b/libavcodec/libsvtav1.c
@@ -541,7 +541,7 @@ static int eb_send_frame(AVCodecContext *avctx, const
AVFrame *frame)
const AVDOVIMetadata *metadata = (const AVDOVIMetadata *)sd->data;
uint8_t *t35;
int size;
-if ((ret = ff_dovi_rpu_generate(&svt_enc->dovi, metadata, &t35,
&size)) < 0)
+if ((ret = ff_dovi_rpu_generate(&svt_enc->dovi, metadata, 0, &t35,
&size)) < 0)
return ret;
ret = svt_add_metadata(headerPtr, EB_AV1_METADATA_TYPE_ITUT_T35, t35,
size);
av_free(t35);
diff --git a/libavcodec/libx265.c b/libavcodec/libx265.c
index 0dc7ab6eeb..4302c3d587 100644
--- a/libavcodec/libx265.c
+++ b/libavcodec/libx265.c
@@ -783,7 +783,8 @@ static int libx265_encode_frame(AVCodecContext *avctx,
AVPacket *pkt,
sd = av_frame_get_side_data(pic, AV_FRAME_DATA_DOVI_METADATA);
if (ctx->dovi.cfg.dv_profile && sd) {
const AVDOVIMetadata *metadata = (const AVDOVIMetadata *)sd->data;
-ret = ff_dovi_rpu_generate(&ctx->dovi, metadata,
&x265pic.rpu.payload,
+ret = ff_dovi_rpu_generate(&ctx->dovi, metadata, 0,
+ &x265pic.rpu.payload,
&x265pic.rpu.payloadSize);
if (ret < 0) {
free_picture(ctx, &x265pic);
--
2.45.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 5/8] avcodec/dovi_rpuenc: make encapsulation optional
From: Niklas Haas
And move the choice of desired container to `flags`. This is needed to
handle differing API requirements (e.g. libx265 requires the NAL RBSP,
but CBS BSF requires the unescaped bytes).
---
libavcodec/dovi_rpu.h| 16 ++--
libavcodec/dovi_rpuenc.c | 22 ++
libavcodec/libaomenc.c | 3 ++-
libavcodec/libsvtav1.c | 3 ++-
libavcodec/libx265.c | 2 +-
5 files changed, 25 insertions(+), 21 deletions(-)
diff --git a/libavcodec/dovi_rpu.h b/libavcodec/dovi_rpu.h
index 65a4529106..226a769bff 100644
--- a/libavcodec/dovi_rpu.h
+++ b/libavcodec/dovi_rpu.h
@@ -123,16 +123,20 @@ int ff_dovi_attach_side_data(DOVIContext *s, AVFrame
*frame);
*/
int ff_dovi_configure(DOVIContext *s, AVCodecContext *avctx);
+enum {
+FF_DOVI_WRAP_NAL= 1 << 0, ///< wrap inside NAL RBSP
+FF_DOVI_WRAP_T35= 1 << 1, ///< wrap inside T.35+EMDF
+};
+
/**
- * Synthesize a Dolby Vision RPU reflecting the current state. Note that this
- * assumes all previous calls to `ff_dovi_rpu_generate` have been appropriately
- * signalled, i.e. it will not re-send already transmitted redundant data.
+ * Synthesize a Dolby Vision RPU reflecting the current state. By default, the
+ * RPU is not encapsulated (see `flags` for more options). Note that this
+ * assumes all previous calls to `ff_dovi_rpu_generate` have been
+ * appropriately signalled, i.e. it will not re-send already transmitted
+ * redundant data.
*
* Mutates the internal state of DOVIContext to reflect the change.
* Returns 0 or a negative error code.
- *
- * This generates a fully formed RPU ready for inclusion in the bitstream,
- * including the EMDF header (profile 10) or NAL encapsulation (otherwise).
*/
int ff_dovi_rpu_generate(DOVIContext *s, const AVDOVIMetadata *metadata,
int flags, uint8_t **out_rpu, int *out_size);
diff --git a/libavcodec/dovi_rpuenc.c b/libavcodec/dovi_rpuenc.c
index d8f113c5c4..65c36ed0ae 100644
--- a/libavcodec/dovi_rpuenc.c
+++ b/libavcodec/dovi_rpuenc.c
@@ -697,9 +697,7 @@ int ff_dovi_rpu_generate(DOVIContext *s, const
AVDOVIMetadata *metadata,
flush_put_bits(pb);
rpu_size = put_bytes_output(pb);
-switch (s->cfg.dv_profile) {
-case 10:
-/* AV1 uses T.35 OBU with EMDF header */
+if (flags & FF_DOVI_WRAP_T35) {
*out_rpu = av_malloc(rpu_size + 15);
if (!*out_rpu)
return AVERROR(ENOMEM);
@@ -726,10 +724,8 @@ int ff_dovi_rpu_generate(DOVIContext *s, const
AVDOVIMetadata *metadata,
flush_put_bits(pb);
*out_size = put_bytes_output(pb);
return 0;
-
-case 5:
-case 8:
-*out_rpu = dst = av_malloc(1 + rpu_size * 3 / 2); /* worst case */
+} else if (flags & FF_DOVI_WRAP_NAL) {
+*out_rpu = dst = av_malloc(4 + rpu_size * 3 / 2); /* worst case */
if (!*out_rpu)
return AVERROR(ENOMEM);
*dst++ = 25; /* NAL prefix */
@@ -752,10 +748,12 @@ int ff_dovi_rpu_generate(DOVIContext *s, const
AVDOVIMetadata *metadata,
}
*out_size = dst - *out_rpu;
return 0;
-
-default:
-/* Should be unreachable */
-av_assert0(0);
-return AVERROR_BUG;
+} else {
+/* Return intermediate buffer directly */
+*out_rpu = s->rpu_buf;
+*out_size = rpu_size;
+s->rpu_buf = NULL;
+s->rpu_buf_sz = 0;
+return 0;
}
}
diff --git a/libavcodec/libaomenc.c b/libavcodec/libaomenc.c
index aa51c89e29..fd9bea2505 100644
--- a/libavcodec/libaomenc.c
+++ b/libavcodec/libaomenc.c
@@ -1294,7 +1294,8 @@ FF_ENABLE_DEPRECATION_WARNINGS
const AVDOVIMetadata *metadata = (const AVDOVIMetadata *)sd->data;
uint8_t *t35;
int size;
-if ((res = ff_dovi_rpu_generate(&ctx->dovi, metadata, 0, &t35,
&size)) < 0)
+if ((res = ff_dovi_rpu_generate(&ctx->dovi, metadata,
FF_DOVI_WRAP_T35,
+&t35, &size)) < 0)
return res;
res = aom_img_add_metadata(rawimg, OBU_METADATA_TYPE_ITUT_T35,
t35, size, AOM_MIF_ANY_FRAME);
diff --git a/libavcodec/libsvtav1.c b/libavcodec/libsvtav1.c
index b6db63fd7a..e7b12fb488 100644
--- a/libavcodec/libsvtav1.c
+++ b/libavcodec/libsvtav1.c
@@ -541,7 +541,8 @@ static int eb_send_frame(AVCodecContext *avctx, const
AVFrame *frame)
const AVDOVIMetadata *metadata = (const AVDOVIMetadata *)sd->data;
uint8_t *t35;
int size;
-if ((ret = ff_dovi_rpu_generate(&svt_enc->dovi, metadata, 0, &t35,
&size)) < 0)
+if ((ret = ff_dovi_rpu_generate(&svt_enc->dovi, metadata,
FF_DOVI_WRAP_T35,
+&t35, &size)) < 0)
return ret;
ret = svt_add_metadata(headerPtr, EB_AV1_METADATA_TYPE_ITUT_T35, t35,
size);
av_free(t35);
diff --git a/libavcodec/libx265.c b/libavcodec/libx265.c
[FFmpeg-devel] [PATCH 6/8] avcodec/dovi_rpuenc: disable metadata compression by default
From: Niklas Haas
Keyframes must reset the metadata compression state, so we cannot enable
metadata compression inside the encoders. Solve this by adding a new
flag, rather than removing it entirely, because I plan on adding
a bitstream filter for metadata compression.
---
libavcodec/dovi_rpu.h| 3 +++
libavcodec/dovi_rpuenc.c | 27 +++
2 files changed, 22 insertions(+), 8 deletions(-)
diff --git a/libavcodec/dovi_rpu.h b/libavcodec/dovi_rpu.h
index 226a769bff..f0d9c24379 100644
--- a/libavcodec/dovi_rpu.h
+++ b/libavcodec/dovi_rpu.h
@@ -126,6 +126,9 @@ int ff_dovi_configure(DOVIContext *s, AVCodecContext
*avctx);
enum {
FF_DOVI_WRAP_NAL= 1 << 0, ///< wrap inside NAL RBSP
FF_DOVI_WRAP_T35= 1 << 1, ///< wrap inside T.35+EMDF
+
+FF_DOVI_COMPRESS_VDR= 1 << 2, ///< enable VDR RPU compression
+FF_DOVI_COMPRESS_ALL= FF_DOVI_COMPRESS_VDR,
};
/**
diff --git a/libavcodec/dovi_rpuenc.c b/libavcodec/dovi_rpuenc.c
index 65c36ed0ae..631733c620 100644
--- a/libavcodec/dovi_rpuenc.c
+++ b/libavcodec/dovi_rpuenc.c
@@ -20,6 +20,8 @@
* Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
*/
+#include
+
#include "libavutil/avassert.h"
#include "libavutil/crc.h"
#include "libavutil/mem.h"
@@ -441,9 +443,10 @@ int ff_dovi_rpu_generate(DOVIContext *s, const
AVDOVIMetadata *metadata,
const AVDOVIRpuDataHeader *hdr;
const AVDOVIDataMapping *mapping;
const AVDOVIColorMetadata *color;
-int vdr_dm_metadata_present, vdr_rpu_id, use_prev_vdr_rpu, profile,
+int vdr_dm_metadata_present, vdr_rpu_id, profile,
buffer_size, rpu_size, pad, zero_run;
int num_ext_blocks_v1, num_ext_blocks_v2;
+int use_prev_vdr_rpu = false;
uint32_t crc;
uint8_t *dst;
if (!metadata) {
@@ -464,12 +467,21 @@ int ff_dovi_rpu_generate(DOVIContext *s, const
AVDOVIMetadata *metadata,
}
vdr_rpu_id = mapping->vdr_rpu_id;
-for (int i = 0; i <= DOVI_MAX_DM_ID; i++) {
-if (s->vdr[i] && !memcmp(s->vdr[i], mapping, sizeof(*mapping))) {
-vdr_rpu_id = i;
-break;
-} else if (s->vdr[vdr_rpu_id] && !s->vdr[i]) {
-vdr_rpu_id = i;
+if (flags & FF_DOVI_COMPRESS_VDR) {
+for (int i = 0; i <= DOVI_MAX_DM_ID; i++) {
+if (s->vdr[i] && !memcmp(s->vdr[i], mapping, sizeof(*mapping))) {
+use_prev_vdr_rpu = true;
+vdr_rpu_id = i;
+break;
+} else if (s->vdr[vdr_rpu_id] && !s->vdr[i]) {
+vdr_rpu_id = i;
+}
+}
+} else {
+/* Flush VDRs to avoid leaking old state after keyframe */
+for (int i = 0; i <= DOVI_MAX_DM_ID; i++) {
+if (i != vdr_rpu_id)
+ff_refstruct_unref(&s->vdr[i]);
}
}
@@ -513,7 +525,6 @@ int ff_dovi_rpu_generate(DOVIContext *s, const
AVDOVIMetadata *metadata,
}
vdr_dm_metadata_present = memcmp(color, &ff_dovi_color_default,
sizeof(*color));
-use_prev_vdr_rpu = !memcmp(s->vdr[vdr_rpu_id], mapping, sizeof(*mapping));
if (num_ext_blocks_v1 || num_ext_blocks_v2)
vdr_dm_metadata_present = 1;
--
2.45.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 7/8] avcodec/dovi_rpu: add ff_dovi_get_metadata()
From: Niklas Haas
Provides direct access to the AVDOVIMetadata without having to attach it
to a frame.
---
libavcodec/dovi_rpu.h| 9 +
libavcodec/dovi_rpudec.c | 40 +++-
2 files changed, 36 insertions(+), 13 deletions(-)
diff --git a/libavcodec/dovi_rpu.h b/libavcodec/dovi_rpu.h
index f0d9c24379..10d5c7f566 100644
--- a/libavcodec/dovi_rpu.h
+++ b/libavcodec/dovi_rpu.h
@@ -108,8 +108,17 @@ void ff_dovi_ctx_flush(DOVIContext *s);
int ff_dovi_rpu_parse(DOVIContext *s, const uint8_t *rpu, size_t rpu_size,
int err_recognition);
+/**
+ * Get the decoded AVDOVIMetadata. Ownership passes to the caller.
+ *
+ * Returns the size of *out_metadata, a negative error code, or 0 if no
+ * metadata is available to return.
+ */
+int ff_dovi_get_metadata(DOVIContext *s, AVDOVIMetadata **out_metadata);
+
/**
* Attach the decoded AVDOVIMetadata as side data to an AVFrame.
+ * Returns 0 or a negative error code.
*/
int ff_dovi_attach_side_data(DOVIContext *s, AVFrame *frame);
diff --git a/libavcodec/dovi_rpudec.c b/libavcodec/dovi_rpudec.c
index b34c3116b7..1e2ad4fd3d 100644
--- a/libavcodec/dovi_rpudec.c
+++ b/libavcodec/dovi_rpudec.c
@@ -30,10 +30,8 @@
#include "get_bits.h"
#include "refstruct.h"
-int ff_dovi_attach_side_data(DOVIContext *s, AVFrame *frame)
+int ff_dovi_get_metadata(DOVIContext *s, AVDOVIMetadata **out_metadata)
{
-AVFrameSideData *sd;
-AVBufferRef *buf;
AVDOVIMetadata *dovi;
size_t dovi_size, ext_sz;
@@ -44,7 +42,32 @@ int ff_dovi_attach_side_data(DOVIContext *s, AVFrame *frame)
if (!dovi)
return AVERROR(ENOMEM);
-buf = av_buffer_create((uint8_t *) dovi, dovi_size, NULL, NULL, 0);
+/* Copy only the parts of these structs known to us at compiler-time. */
+#define COPY(t, a, b, last) memcpy(a, b, offsetof(t, last) + sizeof((b)->last))
+COPY(AVDOVIRpuDataHeader, av_dovi_get_header(dovi), &s->header,
disable_residual_flag);
+COPY(AVDOVIDataMapping, av_dovi_get_mapping(dovi), s->mapping, nlq_pivots);
+COPY(AVDOVIColorMetadata, av_dovi_get_color(dovi), s->color,
source_diagonal);
+ext_sz = FFMIN(sizeof(AVDOVIDmData), dovi->ext_block_size);
+for (int i = 0; i < s->num_ext_blocks; i++)
+memcpy(av_dovi_get_ext(dovi, i), &s->ext_blocks[i], ext_sz);
+dovi->num_ext_blocks = s->num_ext_blocks;
+
+*out_metadata = dovi;
+return dovi_size;
+}
+
+int ff_dovi_attach_side_data(DOVIContext *s, AVFrame *frame)
+{
+AVFrameSideData *sd;
+AVDOVIMetadata *dovi;
+AVBufferRef *buf;
+int size;
+
+size = ff_dovi_get_metadata(s, &dovi);
+if (size <= 0)
+return size;
+
+buf = av_buffer_create((uint8_t *) dovi, size, NULL, NULL, 0);
if (!buf) {
av_free(dovi);
return AVERROR(ENOMEM);
@@ -56,15 +79,6 @@ int ff_dovi_attach_side_data(DOVIContext *s, AVFrame *frame)
return AVERROR(ENOMEM);
}
-/* Copy only the parts of these structs known to us at compiler-time. */
-#define COPY(t, a, b, last) memcpy(a, b, offsetof(t, last) + sizeof((b)->last))
-COPY(AVDOVIRpuDataHeader, av_dovi_get_header(dovi), &s->header,
disable_residual_flag);
-COPY(AVDOVIDataMapping, av_dovi_get_mapping(dovi), s->mapping, nlq_pivots);
-COPY(AVDOVIColorMetadata, av_dovi_get_color(dovi), s->color,
source_diagonal);
-ext_sz = FFMIN(sizeof(AVDOVIDmData), dovi->ext_block_size);
-for (int i = 0; i < s->num_ext_blocks; i++)
-memcpy(av_dovi_get_ext(dovi, i), &s->ext_blocks[i], ext_sz);
-dovi->num_ext_blocks = s->num_ext_blocks;
return 0;
}
--
2.45.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 8/8] avcodec/bsf/dovi_rpu: add new bitstream filter
From: Niklas Haas
This can be used to strip dovi metadata, or enable/disable dovi
metadata compression. Possibly more use cases in the future.
---
configure | 1 +
doc/bitstream_filters.texi | 21 +++
libavcodec/bitstream_filters.c | 1 +
libavcodec/bsf/Makefile| 1 +
libavcodec/bsf/dovi_rpu.c | 258 +
5 files changed, 282 insertions(+)
create mode 100644 libavcodec/bsf/dovi_rpu.c
diff --git a/configure b/configure
index 95565994fe..b432a1c11c 100755
--- a/configure
+++ b/configure
@@ -3437,6 +3437,7 @@ aac_adtstoasc_bsf_select="adts_header mpeg4audio"
av1_frame_merge_bsf_select="cbs_av1"
av1_frame_split_bsf_select="cbs_av1"
av1_metadata_bsf_select="cbs_av1"
+dovi_rpu_bsf_select="cbs_h265 cbs_av1 dovi_rpudec dovi_rpuenc"
dts2pts_bsf_select="cbs_h264 h264parse"
eac3_core_bsf_select="ac3_parser"
evc_frame_merge_bsf_select="evcparse"
diff --git a/doc/bitstream_filters.texi b/doc/bitstream_filters.texi
index c03f04f858..918735e8c5 100644
--- a/doc/bitstream_filters.texi
+++ b/doc/bitstream_filters.texi
@@ -101,6 +101,27 @@ Remove zero padding at the end of a packet.
Extract the core from a DCA/DTS stream, dropping extensions such as
DTS-HD.
+@section dovi_rpu
+
+Manipulate Dolby Vision metadata in a HEVC/AV1 bitstream, optionally enabling
+metadata compression.
+
+@table @option
+@item strip
+If enabled, strip all Dolby Vision metadata (configuration record + RPU data
+blocks) from the stream.
+@item compression
+A bit mask of compression methods to enable.
+@table @samp
+@item none
+No compression. Selected automatically for keyframes.
+@item vdr
+Compress VDR metadata (color reshaping / data mapping parameters).
+@item all
+Enable all implemented compression methods. This is the default.
+@end table
+@end table
+
@section dump_extra
Add extradata to the beginning of the filtered packets except when
diff --git a/libavcodec/bitstream_filters.c b/libavcodec/bitstream_filters.c
index 138246c50e..f923411bee 100644
--- a/libavcodec/bitstream_filters.c
+++ b/libavcodec/bitstream_filters.c
@@ -31,6 +31,7 @@ extern const FFBitStreamFilter ff_av1_metadata_bsf;
extern const FFBitStreamFilter ff_chomp_bsf;
extern const FFBitStreamFilter ff_dump_extradata_bsf;
extern const FFBitStreamFilter ff_dca_core_bsf;
+extern const FFBitStreamFilter ff_dovi_rpu_bsf;
extern const FFBitStreamFilter ff_dts2pts_bsf;
extern const FFBitStreamFilter ff_dv_error_marker_bsf;
extern const FFBitStreamFilter ff_eac3_core_bsf;
diff --git a/libavcodec/bsf/Makefile b/libavcodec/bsf/Makefile
index fb70ad0c21..40b7fc6e9b 100644
--- a/libavcodec/bsf/Makefile
+++ b/libavcodec/bsf/Makefile
@@ -19,6 +19,7 @@ OBJS-$(CONFIG_H264_MP4TOANNEXB_BSF) +=
bsf/h264_mp4toannexb.o
OBJS-$(CONFIG_H264_REDUNDANT_PPS_BSF) += bsf/h264_redundant_pps.o
OBJS-$(CONFIG_HAPQA_EXTRACT_BSF) += bsf/hapqa_extract.o
OBJS-$(CONFIG_HEVC_METADATA_BSF) += bsf/h265_metadata.o
+OBJS-$(CONFIG_DOVI_RPU_BSF) += bsf/dovi_rpu.o
OBJS-$(CONFIG_HEVC_MP4TOANNEXB_BSF) += bsf/hevc_mp4toannexb.o
OBJS-$(CONFIG_IMX_DUMP_HEADER_BSF)+= bsf/imx_dump_header.o
OBJS-$(CONFIG_MEDIA100_TO_MJPEGB_BSF) += bsf/media100_to_mjpegb.o
diff --git a/libavcodec/bsf/dovi_rpu.c b/libavcodec/bsf/dovi_rpu.c
new file mode 100644
index 00..c57c3d87dd
--- /dev/null
+++ b/libavcodec/bsf/dovi_rpu.c
@@ -0,0 +1,258 @@
+/*
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include "libavutil/common.h"
+#include "libavutil/mem.h"
+#include "libavutil/opt.h"
+
+#include "bsf.h"
+#include "bsf_internal.h"
+#include "cbs.h"
+#include "cbs_bsf.h"
+#include "cbs_av1.h"
+#include "cbs_h265.h"
+#include "dovi_rpu.h"
+#include "h2645data.h"
+#include "h265_profile_level.h"
+#include "itut35.h"
+
+#include "hevc/hevc.h"
+
+typedef struct DoviRpuContext {
+CBSBSFContext common;
+DOVIContext dec;
+DOVIContext enc;
+
+int strip;
+int compression;
+} DoviRpuContext;
+
+static int update_rpu(AVBSFContext *bsf, const AVPacket *pkt, int flags,
+ const uint8_t *rpu, size_t rpu_size,
+ uint8_t **out_rpu, int *out_size)
+{
+DoviRpuContext *s = bsf->priv_data;
+AVDOVIMetadata *metadata = NULL
Re: [FFmpeg-devel] [PATCH 3/8] avcodec/dovi_rpuenc: try to re-use existing vdr_rpu_id
On Tue, 18 Jun 2024 21:35:33 +0200 Niklas Haas wrote:
> From: Niklas Haas
>
> And only override it if we either have an exact match, or if we still
> have unused metadata slots (to avoid an overwrite).
> ---
> libavcodec/dovi_rpuenc.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/libavcodec/dovi_rpuenc.c b/libavcodec/dovi_rpuenc.c
> index 45fcd9a86c..0d49a128fd 100644
> --- a/libavcodec/dovi_rpuenc.c
> +++ b/libavcodec/dovi_rpuenc.c
> @@ -463,12 +463,12 @@ int ff_dovi_rpu_generate(DOVIContext *s, const
> AVDOVIMetadata *metadata,
> return AVERROR_INVALIDDATA;
> }
>
> -vdr_rpu_id = -1;
> +vdr_rpu_id = mapping->vdr_rpu_id;
> for (int i = 0; i <= DOVI_MAX_DM_ID; i++) {
> if (s->vdr[i] && !memcmp(s->vdr[i], mapping, sizeof(*mapping))) {
> vdr_rpu_id = i;
> break;
> -} else if (vdr_rpu_id < 0 && (!s->vdr[i] || i == DOVI_MAX_DM_ID)) {
> +} else if (s->vdr[vdr_rpu_id] && !s->vdr[i]) {
> vdr_rpu_id = i;
> }
> }
> --
> 2.45.1
>
I just noticed this check is wrong either way, because the `vdr_rpu_id`
is also included as part of `mapping`. If we reshuffle VDR IDs, we also
need to change the contents of `mapping` when updating the vdrs, as well
as omitting it when doing the `memcmp`.
Effectively this loop currently does nothing, since the only field that
can succeed is in the case `i == mapping->vdr_rpu_id`.
Will fix for v2.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 2/2] swscale/aarch64: Add bgra/rgba to yuv
On Sat, 15 Jun 2024, Zhao Zhili wrote:
From: Zhao Zhili
Test on Apple M1 with kperf
bgra_to_uv_8_c: 13.4
bgra_to_uv_8_neon: 37.4
bgra_to_uv_128_c: 155.9
bgra_to_uv_128_neon: 91.7
bgra_to_uv_1080_c: 1173.2
bgra_to_uv_1080_neon: 822.7
bgra_to_uv_1920_c: 2078.2
bgra_to_uv_1920_neon: 1437.7
bgra_to_uv_half_8_c: 17.9
bgra_to_uv_half_8_neon: 37.4
bgra_to_uv_half_128_c: 103.9
bgra_to_uv_half_128_neon: 73.9
bgra_to_uv_half_1080_c: 850.2
bgra_to_uv_half_1080_neon: 484.2
bgra_to_uv_half_1920_c: 1479.2
bgra_to_uv_half_1920_neon: 824.2
bgra_to_y_8_c: 8.2
bgra_to_y_8_neon: 18.2
bgra_to_y_128_c: 101.4
bgra_to_y_128_neon: 74.9
bgra_to_y_1080_c: 739.4
bgra_to_y_1080_neon: 613.4
bgra_to_y_1920_c: 1298.7
bgra_to_y_1920_neon: 918.7
---
libswscale/aarch64/input.S | 81 +++-
libswscale/aarch64/swscale.c | 16 +++
2 files changed, 86 insertions(+), 11 deletions(-)
diff --git a/libswscale/aarch64/input.S b/libswscale/aarch64/input.S
index 2b956fe5c2..37f1158504 100644
--- a/libswscale/aarch64/input.S
+++ b/libswscale/aarch64/input.S
@@ -20,8 +20,12 @@
#include "libavutil/aarch64/asm.S"
-.macro rgb_to_yuv_load_rgb src
+.macro rgb_to_yuv_load_rgb src, element=3
+.if \element == 3
ld3 { v16.16b, v17.16b, v18.16b }, [\src]
+.else
+ld4 { v16.16b, v17.16b, v18.16b, v19.16b }, [\src]
+.endif
uxtlv19.8h, v16.8b // v19: r
uxtlv20.8h, v17.8b // v20: g
uxtlv21.8h, v18.8b // v21: b
@@ -43,7 +47,7 @@
sqshrn2 \dst\().8h, \dst2\().4s, \right_shift // dst_higher_half =
dst2 >> right_shift
.endm
-.macro rgbToY bgr
+.macro rgbToY bgr, element=3
cmp w4, #0 // check width > 0
.if \bgr
ldr w12, [x5] // w12: ry
@@ -67,11 +71,15 @@
dup v2.8h, w12
b.lt2f
1:
-rgb_to_yuv_load_rgb x1
+rgb_to_yuv_load_rgb x1, \element
rgb_to_yuv_product v19, v20, v21, v25, v26, v16, v0, v1, v2, #9
rgb_to_yuv_product v22, v23, v24, v27, v28, v17, v0, v1, v2, #9
sub w4, w4, #16 // width -= 16
+.if \element == 3
add x1, x1, #48 // src += 48
+.else
+add x1, x1, #64
+.endif
I guess this also could be just #(16*\element)
cmp w4, #16 // width >= 16 ?
stp q16, q17, [x0], #32 // store to dst
b.ge1b
@@ -86,7 +94,7 @@
smaddl x13, w15, w12, x13 // x13 += by * b
asr w13, w13, #9// x13 >>= 9
sub w4, w4, #1 // width--
-add x1, x1, #3 // src += 3
+add x1, x1, \element
Keep the # for the immediate constant here, i.e. #\element. Perhaps it
doen't matter for most assemblers we use, but it's good to stay
consistent.
strhw13, [x0], #2 // store to dst
cbnzw4, 2b
3:
@@ -101,6 +109,14 @@ function ff_bgr24ToY_neon, export=1
rgbToY bgr=1
endfunc
+function ff_rgba32ToY_neon, export=1
+rgbToY bgr=0, element=4
+endfunc
+
+function ff_bgra32ToY_neon, export=1
+rgbToY bgr=1, element=4
+endfunc
+
.macro rgb_load_uv_coeff half, bgr
.if \bgr
ldr w12, [x6, #12]
@@ -130,7 +146,7 @@ endfunc
dup v6.4s, w9
.endm
-.macro rgbToUV_half bgr
+.macro rgbToUV_half bgr, element=3
cmp w5, #0 // check width > 0
b.le3f
@@ -139,7 +155,11 @@ endfunc
b.lt2f
// The following comments assume RGB order. The logic for RGB and BGR
is the same.
1:
+.if \element == 3
ld3 { v16.16b, v17.16b, v18.16b }, [x3]
+.else
+ld4 { v16.16b, v17.16b, v18.16b, v19.16b }, [x3]
+.endif
uaddlp v19.8h, v16.16b // v19: r
uaddlp v20.8h, v17.16b // v20: g
uaddlp v21.8h, v18.16b // v21: b
@@ -147,7 +167,11 @@ endfunc
rgb_to_yuv_product v19, v20, v21, v22, v23, v16, v0, v1, v2, #10
rgb_to_yuv_product v19, v20, v21, v24, v25, v17, v3, v4, v5, #10
sub w5, w5, #8 // width -= 8
-add x3, x3, #48 // src += 48
+.if \element == 3
+add x3, x3, #48
+.else
+add x3, x3, #64
+.endif
cmp w5, #8 // width >= 8 ?
str q16, [x0], #16 // store dst_u
str q17, [x1], #16 // store dst_v
@@ -155,9 +179,10 @@ endfunc
cbz w5, 3f
2:
ldrbw2, [x3]// w2: r1
-ldrbw4,
Re: [FFmpeg-devel] [PATCH 1/2] swscale/aarch64: Add bgr24 to yuv
On Sat, 15 Jun 2024, Zhao Zhili wrote: From: Zhao Zhili Test on Apple M1 with kperf bgr24_to_uv_8_c: 41.5 bgr24_to_uv_8_neon: 41.8 bgr24_to_uv_128_c: 133.5 bgr24_to_uv_128_neon: 94.3 bgr24_to_uv_1080_c: 960.5 bgr24_to_uv_1080_neon: 751.0 bgr24_to_uv_1920_c: 1695.3 bgr24_to_uv_1920_neon: 1357.3 bgr24_to_uv_half_8_c: 45.0 bgr24_to_uv_half_8_neon: 11.0 bgr24_to_uv_half_128_c: 130.5 bgr24_to_uv_half_128_neon: 51.8 bgr24_to_uv_half_1080_c: 877.3 bgr24_to_uv_half_1080_neon: 414.0 bgr24_to_uv_half_1920_c: 1540.0 bgr24_to_uv_half_1920_neon: 695.0 bgr24_to_y_8_c: 24.3 bgr24_to_y_8_neon: 12.8 bgr24_to_y_128_c: 94.3 bgr24_to_y_128_neon: 47.5 bgr24_to_y_1080_c: 611.5 bgr24_to_y_1080_neon: 437.5 bgr24_to_y_1920_c: 1077.3 bgr24_to_y_1920_neon: 765.3 --- libswscale/aarch64/input.S | 79 libswscale/aarch64/swscale.c | 32 +-- 2 files changed, 80 insertions(+), 31 deletions(-) This LGTM // Martin ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] swscale/aarch64: Add argb/abgr to yuv
On Sun, 16 Jun 2024, Zhao Zhili wrote:
From: Zhao Zhili
Test on Apple M1 with kperf:
abgr_to_uv_8_c: 19.4
abgr_to_uv_8_neon: 29.9
abgr_to_uv_128_c: 146.4
abgr_to_uv_128_neon: 85.1
abgr_to_uv_1080_c: 1162.6
abgr_to_uv_1080_neon: 819.6
abgr_to_uv_1920_c: 2063.6
abgr_to_uv_1920_neon: 1435.1
abgr_to_uv_half_8_c: 16.4
abgr_to_uv_half_8_neon: 35.6
abgr_to_uv_half_128_c: 108.6
abgr_to_uv_half_128_neon: 75.4
abgr_to_uv_half_1080_c: 883.4
abgr_to_uv_half_1080_neon: 460.6
abgr_to_uv_half_1920_c: 1553.6
abgr_to_uv_half_1920_neon: 817.6
abgr_to_y_8_c: 6.1
abgr_to_y_8_neon: 40.6
abgr_to_y_128_c: 99.9
abgr_to_y_128_neon: 67.4
abgr_to_y_1080_c: 735.9
abgr_to_y_1080_neon: 534.6
abgr_to_y_1920_c: 1279.4
abgr_to_y_1920_neon: 932.6
Disable vectorization in clang:
abgr_to_uv_8_c: 20.9
abgr_to_uv_8_neon: 44.1
abgr_to_uv_128_c: 555.6
abgr_to_uv_128_neon: 105.9
abgr_to_uv_1080_c: 4773.1
abgr_to_uv_1080_neon: 846.1
abgr_to_uv_1920_c: 8499.9
abgr_to_uv_1920_neon: 1436.6
abgr_to_uv_half_8_c: 13.9
abgr_to_uv_half_8_neon: 167.9
abgr_to_uv_half_128_c: 338.9
abgr_to_uv_half_128_neon: 60.6
abgr_to_uv_half_1080_c: 2906.9
abgr_to_uv_half_1080_neon: 466.1
abgr_to_uv_half_1920_c: 5084.4
abgr_to_uv_half_1920_neon: 832.9
abgr_to_y_8_c: 9.6
abgr_to_y_8_neon: 18.6
abgr_to_y_128_c: 372.4
abgr_to_y_128_neon: 61.4
abgr_to_y_1080_c: 3168.9
abgr_to_y_1080_neon: 513.9
abgr_to_y_1920_c: 6187.6
abgr_to_y_1920_neon: 918.9
---
libswscale/aarch64/input.S | 104 ---
libswscale/aarch64/swscale.c | 17 ++
2 files changed, 100 insertions(+), 21 deletions(-)
diff --git a/libswscale/aarch64/input.S b/libswscale/aarch64/input.S
index 37f1158504..b4e827dd50 100644
--- a/libswscale/aarch64/input.S
+++ b/libswscale/aarch64/input.S
@@ -34,6 +34,16 @@
uxtl2 v24.8h, v18.16b// v24: b
.endm
+.macro argb_to_yuv_load_rgb src
+ld4 { v16.16b, v17.16b, v18.16b, v19.16b }, [\src]
+uxtlv21.8h, v19.8b // v21: b
+uxtl2 v24.8h, v19.16b// v24: b
+uxtlv19.8h, v17.8b // v19: r
+uxtlv20.8h, v18.8b // v20: g
+uxtl2 v22.8h, v17.16b// v22: r
+uxtl2 v23.8h, v18.16b// v23: g
+.endm
+
.macro rgb_to_yuv_product r, g, b, dst1, dst2, dst, coef0, coef1, coef2,
right_shift
mov \dst1\().16b, v6.16b// dst1 =
const_offset
mov \dst2\().16b, v6.16b// dst2 =
const_offset
@@ -47,7 +57,7 @@
sqshrn2 \dst\().8h, \dst2\().4s, \right_shift // dst_higher_half =
dst2 >> right_shift
.endm
-.macro rgbToY bgr, element=3
+.macro rgbToY bgr, element=3, alpha_first=0
cmp w4, #0 // check width > 0
.if \bgr
ldr w12, [x5] // w12: ry
@@ -71,7 +81,11 @@
dup v2.8h, w12
b.lt2f
1:
+.if \alpha_first
+argb_to_yuv_load_rgb x1
+.else
rgb_to_yuv_load_rgb x1, \element
+.endif
rgb_to_yuv_product v19, v20, v21, v25, v26, v16, v0, v1, v2, #9
rgb_to_yuv_product v22, v23, v24, v27, v28, v17, v0, v1, v2, #9
sub w4, w4, #16 // width -= 16
@@ -85,9 +99,15 @@
b.ge1b
cbz x4, 3f
2:
+.if \alpha_first
+ldrbw13, [x1, #1] // w13: r
+ldrbw14, [x1, #2] // w14: g
+ldrbw15, [x1, #3] // w15: b
+.else
ldrbw13, [x1] // w13: r
ldrbw14, [x1, #1] // w14: g
ldrbw15, [x1, #2] // w15: b
+.endif
smaddl x13, w13, w10, x9 // x13 = ry * r + const_offset
smaddl x13, w14, w11, x13 // x13 += gy * g
@@ -101,6 +121,14 @@
ret
.endm
+function ff_argb32ToY_neon, export=1
+rgbToY bgr=0, element=4, alpha_first=1
+endfunc
+
+function ff_abgr32ToY_neon, export=1
+rgbToY bgr=1, element=4, alpha_first=1
+endfunc
+
function ff_rgb24ToY_neon, export=1
rgbToY bgr=0
endfunc
@@ -146,7 +174,21 @@ endfunc
dup v6.4s, w9
.endm
-.macro rgbToUV_half bgr, element=3
+.macro rgb_load_add_halfoff_r1, off_r2, off_g1, off_g2, off_b1, off_b2
+ldrbw2, [x3, \off_r1] // w2: r1
+ldrbw4, [x3, \off_r2] // w4: r2
Keep # for the immediate constant
Otherwise this seems ok.
// Martin
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 3/3] avutil/stereo3d: set a sane default value for AVRational fields
On Tue, Jun 18, 2024 at 04:20:34PM -0300, James Almer wrote:
> Prevent potential divisions by 0 when using them immediately after allocation.
>
> Signed-off-by: James Almer
> ---
> libavutil/stereo3d.c | 14 +-
> 1 file changed, 13 insertions(+), 1 deletion(-)
i must have applied the wrong patches locally but this fails to build
CC libavutil/stereo3d.o
libavutil/stereo3d.c: In function ‘get_defaults’:
libavutil/stereo3d.c:31:47: error: incompatible types when assigning to type
‘int32_t’ {aka ‘int’} from type ‘AVRational’ {aka ‘struct AVRational’}
31 | stereo->horizontal_disparity_adjustment = (AVRational) { 0, 1 };
| ^
make: *** [ffbuild/common.mak:81: libavutil/stereo3d.o] Error 1
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
it is not once nor twice but times without number that the same ideas make
their appearance in the world. -- 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 v2 4/4] swscale/aarch64: add neon {lum, chr}ConvertRange
On Tue, Jun 18, 2024 at 7:42 PM Ramiro Polla wrote:
>
> On Tue, Jun 11, 2024 at 2:29 PM Ramiro Polla wrote:
> >
> > chrRangeFromJpeg_8_c: 29.2
> > chrRangeFromJpeg_8_neon: 19.5
> > chrRangeFromJpeg_24_c: 80.5
> > chrRangeFromJpeg_24_neon: 34.0
> > chrRangeFromJpeg_128_c: 413.7
> > chrRangeFromJpeg_128_neon: 156.0
> > chrRangeFromJpeg_144_c: 471.0
> > chrRangeFromJpeg_144_neon: 174.2
> > chrRangeFromJpeg_256_c: 842.0
> > chrRangeFromJpeg_256_neon: 305.5
> > chrRangeFromJpeg_512_c: 1699.0
> > chrRangeFromJpeg_512_neon: 608.0
> > chrRangeToJpeg_8_c: 51.7
> > chrRangeToJpeg_8_neon: 22.7
> > chrRangeToJpeg_24_c: 149.7
> > chrRangeToJpeg_24_neon: 38.0
> > chrRangeToJpeg_128_c: 761.7
> > chrRangeToJpeg_128_neon: 176.7
> > chrRangeToJpeg_144_c: 866.2
> > chrRangeToJpeg_144_neon: 198.7
> > chrRangeToJpeg_256_c: 1516.5
> > chrRangeToJpeg_256_neon: 348.7
> > chrRangeToJpeg_512_c: 3067.2
> > chrRangeToJpeg_512_neon: 692.7
> > lumRangeFromJpeg_8_c: 24.0
> > lumRangeFromJpeg_8_neon: 17.0
> > lumRangeFromJpeg_24_c: 56.7
> > lumRangeFromJpeg_24_neon: 21.0
> > lumRangeFromJpeg_128_c: 294.5
> > lumRangeFromJpeg_128_neon: 76.7
> > lumRangeFromJpeg_144_c: 332.5
> > lumRangeFromJpeg_144_neon: 86.7
> > lumRangeFromJpeg_256_c: 586.0
> > lumRangeFromJpeg_256_neon: 152.2
> > lumRangeFromJpeg_512_c: 1190.0
> > lumRangeFromJpeg_512_neon: 298.0
> > lumRangeToJpeg_8_c: 31.7
> > lumRangeToJpeg_8_neon: 19.5
> > lumRangeToJpeg_24_c: 83.5
> > lumRangeToJpeg_24_neon: 24.2
> > lumRangeToJpeg_128_c: 440.5
> > lumRangeToJpeg_128_neon: 91.0
> > lumRangeToJpeg_144_c: 504.2
> > lumRangeToJpeg_144_neon: 101.0
> > lumRangeToJpeg_256_c: 879.7
> > lumRangeToJpeg_256_neon: 177.2
> > lumRangeToJpeg_512_c: 1794.2
> > lumRangeToJpeg_512_neon: 354.0
> > ---
> > libswscale/aarch64/Makefile | 1 +
> > libswscale/aarch64/range_convert_neon.S | 99 +
> > libswscale/aarch64/swscale.c| 21 ++
> > libswscale/swscale_internal.h | 1 +
> > libswscale/utils.c | 4 +-
> > 5 files changed, 125 insertions(+), 1 deletion(-)
> > create mode 100644 libswscale/aarch64/range_convert_neon.S
> >
> > diff --git a/libswscale/aarch64/Makefile b/libswscale/aarch64/Makefile
> > index adfd90a1b6..37ad960619 100644
> > --- a/libswscale/aarch64/Makefile
> > +++ b/libswscale/aarch64/Makefile
> > @@ -5,5 +5,6 @@ OBJS+= aarch64/rgb2rgb.o\
> > NEON-OBJS += aarch64/hscale.o \
> > aarch64/input.o \
> > aarch64/output.o \
> > + aarch64/range_convert_neon.o \
> > aarch64/rgb2rgb_neon.o \
> > aarch64/yuv2rgb_neon.o \
> > diff --git a/libswscale/aarch64/range_convert_neon.S
> > b/libswscale/aarch64/range_convert_neon.S
> > new file mode 100644
> > index 00..ea56dc2e32
> > --- /dev/null
> > +++ b/libswscale/aarch64/range_convert_neon.S
> > @@ -0,0 +1,99 @@
> > +/*
> > + * Copyright (c) 2024 Ramiro Polla
> > + *
> > + * This file is part of FFmpeg.
> > + *
> > + * FFmpeg is free software; you can redistribute it and/or
> > + * modify it under the terms of the GNU Lesser General Public
> > + * License as published by the Free Software Foundation; either
> > + * version 2.1 of the License, or (at your option) any later version.
> > + *
> > + * FFmpeg is distributed in the hope that it will be useful,
> > + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
> > + * Lesser General Public License for more details.
> > + *
> > + * You should have received a copy of the GNU Lesser General Public
> > + * License along with FFmpeg; if not, write to the Free Software
> > + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
> > 02110-1301 USA
> > + */
> > +
> > +#include "libavutil/aarch64/asm.S"
> > +
> > +.macro lumConvertRange name, max, mult, offset, shift
> > +function ff_\name, export=1
> > +.if \max != 0
> > +mov w3, #\max
> > +dup v24.8h, w3
> > +.endif
> > +mov w3, #\mult
> > +dup v25.4s, w3
> > +movzw3, \offset & 0x
> > +movkw3, (\offset >> 16) & 0x, lsl #16
> > +dup v26.4s, w3
> > +1:
> > +ld1 {v0.8h}, [x0]
> > +.if \max != 0
> > +sminv0.8h, v0.8h, v24.8h
> > +.endif
> > +mov v16.16b, v26.16b
> > +mov v18.16b, v26.16b
> > +sxtlv20.4s, v0.4h
> > +sxtl2 v22.4s, v0.8h
> > +mla v16.4s, v20.4s, v25.4s
> > +mla v18.4s, v22.4s, v25.4s
> > +shrnv0.4h, v16.4s, #\shift
> > +shrn2 v0.8h, v18.4s, #\shift
> > +subsw1, w1, #8
> > +st1 {v0.8h}, [x0], #16
> > +
Re: [FFmpeg-devel] [PATCH] avformat: split off generic NAL function helpers into their own file
On Sun, Jun 16, 2024 at 02:00:06PM -0300, James Almer wrote: > Signed-off-by: James Almer > --- > libavformat/Makefile | 2 +- > libavformat/avc.c | 164 +--- > libavformat/avc.h | 37 --- > libavformat/flvenc.c | 3 +- > libavformat/hevc.c | 7 +- > libavformat/hlsenc.c | 1 + > libavformat/matroskaenc.c | 1 + > libavformat/movenc.c | 5 +- > libavformat/movenccenc.c | 5 +- > libavformat/mxfenc.c | 3 +- > libavformat/nal.c | 190 + > libavformat/nal.h | 66 > libavformat/rtpenc_h264_hevc.c | 9 +- > libavformat/sdp.c | 5 +- > libavformat/vvc.c | 7 +- > 15 files changed, 287 insertions(+), 218 deletions(-) > create mode 100644 libavformat/nal.c > create mode 100644 libavformat/nal.h TESTsource --- ./tests/ref/fate/source 2024-06-16 09:48:55.353888202 +0200 +++ tests/data/fate/source 2024-06-18 23:22:19.071495178 +0200 @@ -25,6 +25,7 @@ compat/float/float.h compat/float/limits.h libavcodec/bitstream_template.h +libavformat/nal.h tools/decode_simple.h Use of av_clip() where av_clip_uintp2() could be used: Use of av_clip() where av_clip_intp2() could be used: [...] -- 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] avformat/iamf_parse: add missing padding to AAC extradata
On Mon, Jun 17, 2024 at 09:49:01PM -0300, James Almer wrote: > Fixes: out of array access > Fixes: > 68863/clusterfuzz-testcase-minimized-ffmpeg_dem_IAMF_fuzzer-4833546039525376 > > Found-by: continuous fuzzing process > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg > Signed-off-by: James Almer > --- > libavformat/iamf_parse.c | 5 - > 1 file changed, 4 insertions(+), 1 deletion(-) > > diff --git a/libavformat/iamf_parse.c b/libavformat/iamf_parse.c > index 312090b247..ff1b6cc75b 100644 > --- a/libavformat/iamf_parse.c > +++ b/libavformat/iamf_parse.c > @@ -92,13 +92,16 @@ static int aac_decoder_config(IAMFCodecConfig > *codec_config, > if (left <= 0) > return AVERROR_INVALIDDATA; > > -codec_config->extradata = av_malloc(left); > +// We pad extradata here because avpriv_mpeg4audio_get_config2() needs > it. > +codec_config->extradata = av_malloc(left + AV_INPUT_BUFFER_PADDING_SIZE); can this overflow ? except that, it fixes the testcase thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Modern terrorism, a quick summary: Need oil, start war with country that has oil, kill hundread thousand in war. Let country fall into chaos, be surprised about raise of fundamantalists. Drop more bombs, kill more people, be surprised about them taking revenge and drop even more bombs and strip your own citizens of their rights and freedoms. to be continued 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/9] avcodec/mpeg4audio: Check that there is enough space for the first 3 elements in ff_mpeg4audio_get_config_gb()
On Mon, Jun 17, 2024 at 07:27:16AM +0200, Andreas Rheinhardt wrote:
> Michael Niedermayer:
> > Fixes: out of array access
> > Fixes:
> > 68863/clusterfuzz-testcase-minimized-ffmpeg_dem_IAMF_fuzzer-4833546039525376
> >
> > Found-by: continuous fuzzing process
> > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> > Signed-off-by: Michael Niedermayer
> > ---
> > libavcodec/mpeg4audio.c | 4
> > 1 file changed, 4 insertions(+)
> >
> > diff --git a/libavcodec/mpeg4audio.c b/libavcodec/mpeg4audio.c
> > index fbd2a8f811a..ae18944f0d5 100644
> > --- a/libavcodec/mpeg4audio.c
> > +++ b/libavcodec/mpeg4audio.c
> > @@ -94,6 +94,10 @@ int ff_mpeg4audio_get_config_gb(MPEG4AudioConfig *c,
> > GetBitContext *gb,
> > {
> > int specific_config_bitindex, ret;
> > int start_bit_index = get_bits_count(gb);
> > +
> > +if (get_bits_left(gb) < 5+4+4)
> > +return AVERROR_INVALIDDATA;
> > +
> > c->object_type = get_object_type(gb);
> > c->sample_rate = get_sample_rate(gb, &c->sampling_index);
> > c->chan_config = get_bits(gb, 4);
>
> This is not a proper fix. The real bug seems to be that
> avpriv_mpeg4audio_get_config2() relies on the buffer to be padded, but
> iamf_parse.c does not add padding.
indeed, patch droped
james already posted a better fix
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Freedom in capitalist society always remains about the same as it was in
ancient Greek republics: Freedom for slave owners. -- Vladimir Lenin
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 37/57] avcodec/mpegutils: Don't output wrong mb skip values
On Mon, Jun 17, 2024 at 01:08:56PM +0200, Andreas Rheinhardt wrote: > Michael Niedermayer: > > On Wed, Jun 12, 2024 at 03:48:33PM +0200, Andreas Rheinhardt wrote: > >> The earlier code had two problems: > >> 1. For reference frames that are not directly output (happens unless > >> low_delay is set), the mb skip values referred to the next reference > >> frame to be decoded. > >> 2. For non-reference frames, every macroblock was always considered > >> skipped. > >> This makes the output (worse than) useless; that no one ever > >> complained about this shows that this feature is not really used. > >> It is therefore removed. > > > > I used it for statistical purposes long ago, seeing how much blocks where > > skiped and for that a +-1 frame difference is inconsequantal. Also > > i understood that B frame are handled differently, its an internal > > bitstream related number after all > > Does "long ago" mean that you agree that it is unused and can be removed? It simply means that it was usefull and a number similar could be usefull again. I dont care much about it, judging from the past i might use this once in 10 years, if its available. If its not available its not. thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Its not that you shouldnt use gotos but rather that you should write readable code and code with gotos often but not always is less readable signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC] 5 year plan & Inovation
On 17/06/2024 20:34, Michael Niedermayer wrote: On Tue, Apr 30, 2024 at 07:42:53PM +0200, Michael Niedermayer wrote: On Mon, Apr 22, 2024 at 01:32:27PM +0200, Lynne wrote: Apr 22, 2024, 13:07 by stefa...@gmail.com: On date Sunday 2024-04-21 22:12:56 -0300, James Almer wrote: On 4/17/2024 10:58 AM, Michael Niedermayer wrote: [...] A full rewrite of ffserver, using only public API, and with modern streaming in mind. It would give a lot of code in lavf some use. If this is going to happen, my advice is to use "ffstream" to stick to the ffVERB convention (with the exeption of ffmpeg, which might still be converted to ffconvert with some proper aliasing) and to avoid association with the old incompatible tool . That's basically what txproto is, only that it also does transcoding and filtering. It can accept incoming streams and output them to multiple destinations via remux or transcode. It was built as an ffmpeg.c with a scriptable interface and with dynamic switching. It doesn't do this out of the box, it's something you have to script, but that was largely the case that ffserver had. What is missing is something that ffserver had, which was that it was able to express exactly what lavf had in its context on both the sender and receiver, for which it needed private APIs. AVTransport can largely fill that niche. hmm how would we (assert(people agreeing)) go from what you describe to a (very easy to use) ffserver "2.0" in something on the ffmpeg.org download page ? also if you look at google trends, even today more people search for ffserver than txproto. In fact at every point in time more people searched for ffserver than txproto. https://trends.google.com/trends/explore?date=all&q=txproto,ffserver So even though ffserver is dead, removed and unmaintained, it has more users And this comes back to what i said many times. We should use the name FFmpeg, our domain and NOT push every bit of new inovation out into sub projects. We should put a newly developed ffserver into the main ffmpeg git. We should put wasm build support into the main ffmpeg git. We should turn ffplay into a fully competetive player. Forgot to respond to this. I agree that txproto is a stupid name which stuck around when I absolutely had to give it some name, and I hope to change it to a more suitable one, one day. I'm not sure what to call it, as it could partially fulfill the duties of ffserver, ffplay and ffmpeg all at once. Its a high level Lua, and C, wrapper around all the libraries that simply lets users dynamically link and unlink components, while handling the flow of frames and packets entirely for you. It still lets you optionally handle low-level packets and frames via callbacks, so you can still do frame-precise stuff, like applying a filter to only one specific frame. It provides a C library, and a CLI. There's even code for GUIs present, though the only functionality that code has is to present a stream of AVFrames on screen, and draw a rectangle (used for screenshot region selection). It already has handling for keyboard/mouse inputs, so it should be easy to integrated ImGui or nuklear for something more complete. Everything related to displaying is done via libplacebo. I think its possibly maybe close enough to what users have been asking us for, and a little more. I've written very well integrated backends for interfacing to the OS, so it can use them much better than ffmpeg could ever use avdevice, and lets the code do much, from local/networked transcoding, relaying, monitoring, presenting to screen and recording, which you can check out here: https://github.com/cyanreg/txproto/tree/master/DOCS/examples It could in theory perform the duties of ffplay and ffserver as well as any of them can/could. But not ffmpeg, due to the huge amount of specific handling for various cases we have there. I would be fine with moving the code under a repository administered by the project that we can all contribute, work on, and perhaps one day officially offer as software alongside all the rest of the projects we work on, if there's enough interest and consensus from the community. The codebase is completely LGPL2+ like ours, and it uses as much of all of our libraries as possible, including routines to allocate memory. I would not merge this into our main repository though, no way. It is currently used in production, though under controlled and predictable circumstances. So its not recommended to general users. There are many known issues that I'm working on fixing, and error handling is quite bad currently. OpenPGP_0xA2FEA5F03F034464.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital 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 "unsu
[FFmpeg-devel] [PATCH v2 1/2] lavc/hevcdec: Put slice address checking after hwaccel decode slice
From: Fei Wang
Slice address tab only been updated in software decode slice data.
Fixes hwaccel decoding after d725c737fe2a19091b481d4d115fd939e0a674b2.
Signed-off-by: Fei Wang
---
libavcodec/hevc/hevcdec.c | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/libavcodec/hevc/hevcdec.c b/libavcodec/hevc/hevcdec.c
index 1d2e53afc3..39beb7e4dc 100644
--- a/libavcodec/hevc/hevcdec.c
+++ b/libavcodec/hevc/hevcdec.c
@@ -2770,15 +2770,6 @@ static int decode_slice_data(HEVCContext *s, const
H2645NAL *nal, GetBitContext
const HEVCPPS *pps = s->pps;
int ret;
-if (s->sh.dependent_slice_segment_flag) {
-int ctb_addr_ts = pps->ctb_addr_rs_to_ts[s->sh.slice_ctb_addr_rs];
-int prev_rs = pps->ctb_addr_ts_to_rs[ctb_addr_ts - 1];
-if (s->tab_slice_address[prev_rs] != s->sh.slice_addr) {
-av_log(s->avctx, AV_LOG_ERROR, "Previous slice segment missing\n");
-return AVERROR_INVALIDDATA;
-}
-}
-
if (!s->sh.dependent_slice_segment_flag && s->sh.slice_type !=
HEVC_SLICE_I) {
ret = ff_hevc_slice_rpl(s);
if (ret < 0) {
@@ -2799,6 +2790,15 @@ static int decode_slice_data(HEVCContext *s, const
H2645NAL *nal, GetBitContext
return AVERROR_PATCHWELCOME;
}
+if (s->sh.dependent_slice_segment_flag) {
+int ctb_addr_ts = pps->ctb_addr_rs_to_ts[s->sh.slice_ctb_addr_rs];
+int prev_rs = pps->ctb_addr_ts_to_rs[ctb_addr_ts - 1];
+if (s->tab_slice_address[prev_rs] != s->sh.slice_addr) {
+av_log(s->avctx, AV_LOG_ERROR, "Previous slice segment missing\n");
+return AVERROR_INVALIDDATA;
+}
+}
+
s->local_ctx[0].first_qp_group = !s->sh.dependent_slice_segment_flag;
if (!pps->cu_qp_delta_enabled_flag)
--
2.25.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v2 2/2] lavc/hevcdec: Update slice index before use it to construct slice RPL
From: Fei Wang
Fixes regression from 47d34ba7fbb81
Signed-off-by: Fei Wang
---
libavcodec/hevc/hevcdec.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/libavcodec/hevc/hevcdec.c b/libavcodec/hevc/hevcdec.c
index 39beb7e4dc..8bb564f1b3 100644
--- a/libavcodec/hevc/hevcdec.c
+++ b/libavcodec/hevc/hevcdec.c
@@ -2770,6 +2770,9 @@ static int decode_slice_data(HEVCContext *s, const
H2645NAL *nal, GetBitContext
const HEVCPPS *pps = s->pps;
int ret;
+if (!s->sh.first_slice_in_pic_flag)
+s->slice_idx += !s->sh.dependent_slice_segment_flag;
+
if (!s->sh.dependent_slice_segment_flag && s->sh.slice_type !=
HEVC_SLICE_I) {
ret = ff_hevc_slice_rpl(s);
if (ret < 0) {
@@ -2807,8 +2810,6 @@ static int decode_slice_data(HEVCContext *s, const
H2645NAL *nal, GetBitContext
s->local_ctx[0].tu.cu_qp_offset_cb = 0;
s->local_ctx[0].tu.cu_qp_offset_cr = 0;
-s->slice_idx += !s->sh.dependent_slice_segment_flag;
-
if (s->avctx->active_thread_type == FF_THREAD_SLICE &&
s->sh.num_entry_point_offsets > 0&&
pps->num_tile_rows == 1 && pps->num_tile_columns == 1)
--
2.25.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v1] lavc/hevcdec: Put slice address checking after hwaccel decode slice
On Mon, 2024-06-17 at 10:05 +0200, Anton Khirnov wrote: > Quoting fei.w.wang-at-intel@ffmpeg.org (2024-06-14 10:18:19) > > From: Fei Wang > > > > Slice address tab only been updated in software decode slice data. > > > > Fixes hwaccel decoding after > > d725c737fe2a19091b481d4d115fd939e0a674b2. > > > > Signed-off-by: Fei Wang > > --- > > libavcodec/hevc/hevcdec.c | 18 +- > > 1 file changed, 9 insertions(+), 9 deletions(-) > > Looks ok Re-send in v2, together with the other fix which is base on this change. Fei 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] avformat/tls_schannel: forward AVIO_FLAG_NONBLOCK to tcp stream
On 2024-06-18 11:53 pm, Timo Rothenpieler wrote:
On 18.06.2024 18:56, Gyan Doshi wrote:
FWIW, I had to do the same for securetransport on a project a couple
of years back to get rtmps working. Worked fine, and did not get any
reports of ill-effects.
You mean the FFmpeg implementation of rtmps?
Cause if so, I think that only makes use of nonblocking mode for
receiving, not sending.
So it wouldn't run into this if it was wrong.
IIRC, the setup/handshake phase would never complete.
Adding this fixed it
+ TLSShared *s = &c->tls_shared;
+ int set_flag_nonblock = 0;
+
+ if (h->flags & AVIO_FLAG_NONBLOCK && !(s->tcp->flags &
AVIO_FLAG_NONBLOCK)) {
+ s->tcp->flags |= AVIO_FLAG_NONBLOCK;
+ set_flag_nonblock = 1;
+ }
+
int read = ffurl_read(c->tls_shared.tcp, data, requested);
+
+ if (set_flag_nonblock)
+ s->tcp->flags &= ~AVIO_FLAG_NONBLOCK;
Regards,
Gyan
___
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] avcodec/jpeg2000dec: Add support for placeholder passes, CAP, and CPF markers
First of all, I appreciate your kind review.
I'm writing to discuss the changes and would like to hear your feedback on
these.
> On Jun 18, 2024, at 23:20, Tomas Hardin wrote:
>
>
> It seems this patch combines a lot of things that might be better to
> split into separate patches for easier review
Agree. I will split this patch into several patches.
For example, the set of patches includes changes:
- only for HTJ2K (JPEG 2000 Part 15)
- only for J2K (JPEG 2000 Part 1)
- for both J2K and HTJ2K.
Do you think it makes sense?
>
>> @@ -382,6 +391,9 @@ static int get_siz(Jpeg2000DecoderContext *s)
>> } else if (ncomponents == 1 && s->precision == 8) {
>> s->avctx->pix_fmt = AV_PIX_FMT_GRAY8;
>> i = 0;
>> +} else if (ncomponents == 1 && s->precision == 12) {
>> +s->avctx->pix_fmt = AV_PIX_FMT_GRAY16LE;
>> +i = 0;
>
> Could we handle 9 <= precision <= 16 while we're at it?
>
Yes. The native J2K decoder for both lossless and lossy J2K/HTJ2K
codestreams can handle bpp from 9 to 16. This change is required to
produce the decoded images for the ISO test codestreams defined in
Part 4 (Conformance testing).
>> @@ -408,6 +420,73 @@ static int get_siz(Jpeg2000DecoderContext *s)
>> s->avctx->bits_per_raw_sample = s->precision;
>> return 0;
>> }
>> +/* get extended capabilities (CAP) marker segment */
>> +static int get_cap(Jpeg2000DecoderContext *s, Jpeg2000CodingStyle
>> *c)
>> +{
>> +uint32_t Pcap;
>> +uint16_t Ccap_i[32] = { 0 };
>> +uint16_t Ccap_15;
>> +uint8_t P;
>> +
>> +if (bytestream2_get_bytes_left(&s->g) < 6) {
>> +av_log(s->avctx, AV_LOG_ERROR, "Insufficient space for
>> CAP\n");
>> +return AVERROR_INVALIDDATA;
>> +}
>> +
>> +Pcap = bytestream2_get_be32u(&s->g);
>> +s->isHT = (Pcap >> (31 - (15 - 1))) & 1;
>> +for (int i = 0; i < 32; i++) {
>> +if ((Pcap >> (31 - i)) & 1)
>> +Ccap_i[i] = bytestream2_get_be16u(&s->g);
>> +}
>> +Ccap_15 = Ccap_i[14];
>> +if (s->isHT == 1) {
>> +av_log(s->avctx, AV_LOG_INFO, "This is an HTJ2K codestream.\n");
>> +// Bits 14-15
>> +switch ((Ccap_15 >> 14) & 0x3) {
>
> Missing indentation
>
>> +case 0x3:
>> +s->Ccap15_b14_15 = HTJ2K_MIXED;
>> +break;
>> +case 0x1:
>> +s->Ccap15_b14_15 = HTJ2K_HTDECLARED;
>> +break;
>> +case 0x0:
>> +s->Ccap15_b14_15 = HTJ2K_HTONLY;
>> +break;
>> +default:
>> +av_log(s->avctx, AV_LOG_ERROR, "Unknown CCap
>> value.\n");
>> +return AVERROR(EINVAL);
>> +break;
>> +}
>> +// Bit 13
>> +if ((Ccap_15 >> 13) & 1) {
>> +av_log(s->avctx, AV_LOG_ERROR, "MULTIHT set is not
>> supported.\n");
>> +return AVERROR_PATCHWELCOME;
>> +}
>> +// Bit 12
>> +s->Ccap15_b12 = (Ccap_15 >> 12) & 1;
>> +// Bit 11
>> +s->Ccap15_b11 = (Ccap_15 >> 11) & 1;
>> +// Bit 5
>> +s->Ccap15_b05 = (Ccap_15 >> 5) & 1;
>> +// Bit 0-4
>> +P = Ccap_15 & 0x1F;
>> +if (!P)
>> +s->HT_MAGB = 8;
>> +else if (P < 20)
>> +s->HT_MAGB = P + 8;
>> +else if (P < 31)
>> +s->HT_MAGB = 4 * (P - 19) + 27;
>> +else
>> +s->HT_MAGB = 74;
>> +
>> +if (s->HT_MAGB > 31) {
>> +av_log(s->avctx, AV_LOG_ERROR, "Available internal
>> precision is exceeded (MAGB> 31).\n");
>> +return AVERROR_PATCHWELCOME;
>> +}
>> +}
>
> Weird indentation
>
Thank you for catching these. I will fix them in the patch set.
>> @@ -802,6 +881,15 @@ static int read_crg(Jpeg2000DecoderContext *s,
>> int n)
>> bytestream2_skip(&s->g, n - 2);
>> return 0;
>> }
>> +
>> +static int read_cpf(Jpeg2000DecoderContext *s, int n)
>> +{
>> +if (bytestream2_get_bytes_left(&s->g) < (n - 2))
>> +return AVERROR_INVALIDDATA;
>> +bytestream2_skip(&s->g, n - 2);
>> +return 0;
>> +}
>
> Don't we already have code for skipping markers we don't care about?
>
The `read_cpf()` function was added for consistency with the `read_crg()`
function.
We already have `bytestream2_skip(GetByteContext *g, unsigned int size)` that
skips `size`
bytes from the compressed data.
Do you think it is better to replace those functions (= `read_cpf()` and
`read_crg()`)
with `bytestream2_skip()`?
>> +
>> /* Tile-part lengths: see ISO 15444-1:2002, section A.7.1
>> * Used to know the number of tile parts and lengths.
>> * There may be multiple TLMs in the header.
>> @@ -965,6 +1053,10 @@ static int init_tile(Jpeg2000DecoderContext *s,
>> int tileno)
>> comp->roi_shift = s->roi_shift[compno];
>> if (!codsty->init)
>> return AVERROR_INVALIDDATA;
>> +if (s->isHT && (!s->Ccap15_b05) && (!codsty->transform))
>> +av_log(s->avctx, AV_LOG_WARNING, "Transformation = 0
>> (lossy DWT) is found in HTREV HT set\n");
>> +
