Re: [FFmpeg-devel] [PATCH] doc/community: rule to avoid conflict of interest and prejudice in TC
Ping. Anton announced to have a vote on 4th Mar for changing the rule [1]. That's long past. It is holding up the consideration of the matter I raised [2] to the TC. Regards, Gyan [1]: https://ffmpeg.org/pipermail/ffmpeg-devel/2024-March/322464.html [2]: https://ffmpeg.org/pipermail/ffmpeg-devel/2024-February/321564.html On 2024-03-03 12:52 pm, Gyan Doshi wrote: --- doc/community.texi | 15 ++- 1 file changed, 14 insertions(+), 1 deletion(-) diff --git a/doc/community.texi b/doc/community.texi index 90d2b6f366..8d5722bd7f 100644 --- a/doc/community.texi +++ b/doc/community.texi @@ -82,7 +82,20 @@ The TC has 2 modes of operation: a RFC one and an internal one. If the TC thinks it needs the input from the larger community, the TC can call for a RFC. Else, it can decide by itself. -If the disagreement involves a member of the TC, that member should recuse themselves from the decision. +Any member of the TC who has + +@itemize @bullet +@item +had a major participation in the discussion or demonstrated a partisan disposition on a disputed matter at any public venue, or +@item +a material interest in the resolution of the dispute, either directly or via current or anticipated employment or consideration +@end itemize + +should be recused from participation in the TC activities related to the concerned matter. +This recusal may be effected either directly by the TC member, or failing which, by a vote of the +Community Committee (CC) - the TC member must not participate in any such vote. Failure by the TC member +to reveal any such involvement as described above, if judged intentional and material by the CC, shall +result in exclusion of said member from all FFmpeg governance bodies for a period of no less than two years. The decision to use a RFC process or an internal discussion is a discretionary decision of the TC. ___ 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] Channels
On 3/21/2024 11:25 PM, Michael Niedermayer wrote: Hi all we have code like st->codecpar->ch_layout.nb_channels = avio_rb32(pb); and then somewhere there is some code that uses this by first allocating an array and that then hits OOM (it was this here: map = av_calloc(nb_channels, sizeof(*channel_layout->u.map));) is anyone against adding a max_channels field to AVFormatContext or something like that ? alternative is "wont fix" for all such cases, or maybe someone sees another way ? thx We have FF_SANE_NB_CHANNELS, so maybe add a check for it to mxfdec.c (Where i assume this is happening) and mov_chan.c or mov.c before continuing with such a layout. ___ 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] [RFC] Channels
Hi all we have code like st->codecpar->ch_layout.nb_channels = avio_rb32(pb); and then somewhere there is some code that uses this by first allocating an array and that then hits OOM (it was this here: map = av_calloc(nb_channels, sizeof(*channel_layout->u.map));) is anyone against adding a max_channels field to AVFormatContext or something like that ? alternative is "wont fix" for all such cases, or maybe someone sees another way ? thx -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB It is what and why we do it that matters, not just one of them. signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] doc: Add libtoch backend option to dnn_processing
> -Original Message-
> From: ffmpeg-devel On Behalf Of
> wenbin.chen-at-intel@ffmpeg.org
> Sent: Thursday, March 21, 2024 2:51 PM
> To: ffmpeg-devel@ffmpeg.org
> Subject: [FFmpeg-devel] [PATCH] doc: Add libtoch backend option to
> dnn_processing
>
> From: Wenbin Chen
>
> Signed-off-by: Wenbin Chen
> ---
> doc/filters.texi | 12 +++-
> 1 file changed, 11 insertions(+), 1 deletion(-)
>
> diff --git a/doc/filters.texi b/doc/filters.texi index 913365671d..20605e72b2
> 100644
> --- a/doc/filters.texi
> +++ b/doc/filters.texi
> @@ -12069,11 +12069,21 @@ need to build and install the OpenVINO for C
> library (see @code{--enable-libopenvino} (--extra-cflags=-I...
> --extra-ldflags=-
> L... might be needed if the header files and libraries are not installed into
> system path)
>
> +@item torch
> +Libtorch backend. To enable this backend you need to build and install
> +Libtroch for C++ library. Please download cxx11 ABI version (see
> +@url{https://pytorch.org/get-started/locally})
> +and configure FFmpeg with @code{--enable-libtorch
> +--extra-cflag=-I/libtorch_root/libtorch/include
> +--extra-cflag=-I/libtorch_root/libtorch/include/torch/csrc/api/include
"s" is missed in extra-cflags
___
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] configure: Explicitly check for static_assert
Martin Storsjö:
> On Thu, 21 Mar 2024, Andreas Rheinhardt wrote:
>
>> Andreas Rheinhardt:
>>> C11 provides static assertions via _Static_assert and
>>> provides static_assert as a convenience define for this
>>> in assert.h. MSVC 19.27 declares support for C11, but does
>>> not support _Static_assert, but somehow supports
>>> static_assert. That's therefore what we use.
>>>
>>> But apparently there are some old GCC toolchains where
>>> _Static_assert is supported, but assert.h does not provide
>>> the fallback define. Some fate boxes are affected by this
>>> [1].
>>>
>>> This commit therefore checks whether static_assert works
>>> with assert.h included; if not, it errors out. Users like
>>> the above can still add -Dstatic_assert=_Static_assert
>>> to cflags as a workaround.
>>>
>>> [1]:
>>> https://fate.ffmpeg.org/report.cgi?time=20240321123620=sh4-debian-qemu-gcc-4.7
>>>
>>> Signed-off-by: Andreas Rheinhardt
>>> ---
>>> This is what a test without fallback looks like.
>>> Posted to gather opinions on what people prefer.
>>>
>>> configure | 13 +
>>> 1 file changed, 13 insertions(+)
>>>
>>> diff --git a/configure b/configure
>>> index 6d7b33b0ff..c2d2c70c20 100755
>>> --- a/configure
>>> +++ b/configure
>>> @@ -5589,6 +5589,19 @@ check_cxxflags_cc -std=$stdcxx ctype.h
>>> "__cplusplus >= 201103L" ||
>>> check_cflags_cc -std=$stdc ctype.h "__STDC_VERSION__ >= 201112L" ||
>>> { check_cflags_cc -std=c11 ctype.h "__STDC_VERSION__ >= 201112L"
>>> && stdc="c11" || die "Compiler lacks C11 support"; }
>>>
>>> +test_cc <>> +#include
>>> +#include
>>> +struct Foo {
>>> + int a;
>>> + void *ptr;
>>> +} obj;
>>> +static_assert(offsetof(struct Foo, a) == 0,
>>> + "First element of struct does not have offset 0");
>>> +static_assert(offsetof(struct Foo, ptr) >= offsetof(struct Foo, a) +
>>> sizeof(obj.a),
>>> + "elements not properly ordered in struct");
>>> +EOF
>>> +
>>> check_cppflags -D_FILE_OFFSET_BITS=64
>>> check_cppflags -D_LARGEFILE_SOURCE
>>>
>>
>> Jan has tested old toolchains and found out that his GCC 4.7 has proper
>> C11 headers; so this seems to be unique to Michael's setup. This makes
>> me prefer this patch instead of the version with the fallback. (Michael
>> can simply add -Dstatic_assert=_Static_assert to his cflags.)
>> Of course others are still invited to share their opinions.
>
> Both patches seem to work fine with MSVC 19.27 - I vaguely prefer the v2
> version, which is simpler.
>
>
> But to me, we could also just revert the change to
> libavcodec/ccaption_dec.c, and declare that we require MSVC 19.28
> instead. MSVC 19.27, when executed with -std:c11 without -nologo, it
> prints this:
>
> /std:c11 is a preview implementation of the ISO C11 standard, and
> we're eager to hear about bugs and suggestions for improvements.
> However, note that these features are provided as-is without support.
>
> And I don't have any specific reasons for wanting to use this compiler -
> I just tested the lowest version that was supposed to be supported
> earlier and noted that it had broken recently. So to me, reverting to
> requiring _Static_assert would be quite ok as well.
>
We can actually do both: Test for static_assert and for _Static_assert
(to exclude MSVC 19.27; is 19.28 still supposed to be a preview
implementation?).
The reason I prefer static_assert in the codebase is that _Static_assert
is actually deprecated with C23 (although I don't think it will be
removed any time).
- 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] configure: Explicitly check for static_assert
On Thu, 21 Mar 2024, Andreas Rheinhardt wrote:
Andreas Rheinhardt:
C11 provides static assertions via _Static_assert and
provides static_assert as a convenience define for this
in assert.h. MSVC 19.27 declares support for C11, but does
not support _Static_assert, but somehow supports
static_assert. That's therefore what we use.
But apparently there are some old GCC toolchains where
_Static_assert is supported, but assert.h does not provide
the fallback define. Some fate boxes are affected by this
[1].
This commit therefore checks whether static_assert works
with assert.h included; if not, it errors out. Users like
the above can still add -Dstatic_assert=_Static_assert
to cflags as a workaround.
[1]:
https://fate.ffmpeg.org/report.cgi?time=20240321123620=sh4-debian-qemu-gcc-4.7
Signed-off-by: Andreas Rheinhardt
---
This is what a test without fallback looks like.
Posted to gather opinions on what people prefer.
configure | 13 +
1 file changed, 13 insertions(+)
diff --git a/configure b/configure
index 6d7b33b0ff..c2d2c70c20 100755
--- a/configure
+++ b/configure
@@ -5589,6 +5589,19 @@ check_cxxflags_cc -std=$stdcxx ctype.h "__cplusplus >=
201103L" ||
check_cflags_cc -std=$stdc ctype.h "__STDC_VERSION__ >= 201112L" ||
{ check_cflags_cc -std=c11 ctype.h "__STDC_VERSION__ >= 201112L" && stdc="c11" ||
die "Compiler lacks C11 support"; }
+test_cc <
+#include
+struct Foo {
+int a;
+void *ptr;
+} obj;
+static_assert(offsetof(struct Foo, a) == 0,
+ "First element of struct does not have offset 0");
+static_assert(offsetof(struct Foo, ptr) >= offsetof(struct Foo, a) +
sizeof(obj.a),
+ "elements not properly ordered in struct");
+EOF
+
check_cppflags -D_FILE_OFFSET_BITS=64
check_cppflags -D_LARGEFILE_SOURCE
Jan has tested old toolchains and found out that his GCC 4.7 has proper
C11 headers; so this seems to be unique to Michael's setup. This makes
me prefer this patch instead of the version with the fallback. (Michael
can simply add -Dstatic_assert=_Static_assert to his cflags.)
Of course others are still invited to share their opinions.
Both patches seem to work fine with MSVC 19.27 - I vaguely prefer the v2
version, which is simpler.
But to me, we could also just revert the change to
libavcodec/ccaption_dec.c, and declare that we require MSVC 19.28 instead.
MSVC 19.27, when executed with -std:c11 without -nologo, it prints this:
/std:c11 is a preview implementation of the ISO C11 standard, and
we're eager to hear about bugs and suggestions for improvements.
However, note that these features are provided as-is without support.
And I don't have any specific reasons for wanting to use this compiler - I
just tested the lowest version that was supposed to be supported earlier
and noted that it had broken recently. So to me, reverting to requiring
_Static_assert would be quite ok as well.
// 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] avfilter/af_volumedetect.c: Add 32bit float audio support
On Wed, Mar 20, 2024 at 11:55 PM Yiğithan Yiğit wrote: > > > On Mar 21, 2024, at 12:10 AM, Paul B Mahol wrote: > > > > Why? This is pointless. > > > > volumedetect have histogram output, float patch does not have it at all. > > Use astats filter. > > > > On Wed, Mar 20, 2024 at 9:47 PM Yiğithan Yiğit < > yigithanyigi...@gmail.com> > > wrote: > > > >> ___ > >> 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”. > > I am a beginner/student also new at open source but I love FFmpeg and > using in my daily life. From my perspective volumedetect way more user > friendly. I believe adding this patch would be useful to people such as > #9613. The reason lack of histogram output for float mostly for my > indecision about range of the histogram. I am open the suggestions and > after that I can make a new patch. > It is trivial (to some people) to add histogram per dB for float/double inputs. But this patch just does some extremely trivial math calculations so that float input have completely different output from integer ones. That is very odd and unfriendly from my perspective. Besides if you only interested in discrete sample audio peak finder in audio input use astats and measure_overall=Peak_level options. Yes they are not default on. Because more statistics are more important than single number. I'm not against adding proper and useful and correct float/double support to volumedetect, but it needs to have same/similar structure of output as integer sample format input audio, otherwise it just looks lazy and prone for users wondering what is going on when they use different sample formats in theirs graphs. > > Best Regards > Yigithan > > > ___ > 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/jpegxl_anim_dec: set pos for generic index
avpkt->pos needs to be set for generic indexing or features such as the stream_loop option will not work. Co-authored-by: Andreas Rheinhardt Signed-off-by: Leo Izen --- libavformat/jpegxl_anim_dec.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/libavformat/jpegxl_anim_dec.c b/libavformat/jpegxl_anim_dec.c index f749b378b3..78dc16017d 100644 --- a/libavformat/jpegxl_anim_dec.c +++ b/libavformat/jpegxl_anim_dec.c @@ -171,6 +171,8 @@ static int jpegxl_anim_read_packet(AVFormatContext *s, AVPacket *pkt) av_buffer_unref(>initial); } +pkt->pos = avio_tell(pb) - offset; + ret = avio_read(pb, pkt->data + offset, size - offset); if (ret < 0) return ret; -- 2.44.0 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2] avformat: enable UDP IPv6 multicast interface selection
Le torstaina 21. maaliskuuta 2024, 15.01.09 EET Ignjatović, Lazar (RS) a écrit : > > Your MR makes even less sense for multicast. For multicast there is no > > local address to match to an interface. So you just have to have the > > interface specified explicitly in addition to the LL group address. This > > is true for both egress and ingress. > > I've compared ffmpeg 5.1.2 against my MR on IPv6 multicast. Here are the > results: I don't care. That does not make your MR any less counter-sensical. If you could infer the scope ID from the IPv6 address, there wouldn't be a scope ID field in the socket address in the first place. Is it that hard to understand? If you tests show anything, it's that LL addressing is not intended for application protocols. This is consistent with the fact that nobody cared to support this combination in FFmpeg after 28 years of IPv6. Now I don't mind adding proper support, but not kludges. > So the problem to overcome here is controlling on which interface we > listen/send multicat IPv6. That "problem" was solved before FFmpeg existed by adding a separate parameter (ping6) or prepending the interface name after a percent sign (glibc). -- Rémi Denis-Courmont http://www.remlab.net/ ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2] configure: Explicitly check for static_assert
Andreas Rheinhardt:
> C11 provides static assertions via _Static_assert and
> provides static_assert as a convenience define for this
> in assert.h. MSVC 19.27 declares support for C11, but does
> not support _Static_assert, but somehow supports
> static_assert. That's therefore what we use.
>
> But apparently there are some old GCC toolchains where
> _Static_assert is supported, but assert.h does not provide
> the fallback define. Some fate boxes are affected by this
> [1].
>
> This commit therefore checks whether static_assert works
> with assert.h included; if not, it errors out. Users like
> the above can still add -Dstatic_assert=_Static_assert
> to cflags as a workaround.
>
> [1]:
> https://fate.ffmpeg.org/report.cgi?time=20240321123620=sh4-debian-qemu-gcc-4.7
>
> Signed-off-by: Andreas Rheinhardt
> ---
> This is what a test without fallback looks like.
> Posted to gather opinions on what people prefer.
>
> configure | 13 +
> 1 file changed, 13 insertions(+)
>
> diff --git a/configure b/configure
> index 6d7b33b0ff..c2d2c70c20 100755
> --- a/configure
> +++ b/configure
> @@ -5589,6 +5589,19 @@ check_cxxflags_cc -std=$stdcxx ctype.h "__cplusplus >=
> 201103L" ||
> check_cflags_cc -std=$stdc ctype.h "__STDC_VERSION__ >= 201112L" ||
> { check_cflags_cc -std=c11 ctype.h "__STDC_VERSION__ >= 201112L" &&
> stdc="c11" || die "Compiler lacks C11 support"; }
>
> +test_cc < +#include
> +#include
> +struct Foo {
> +int a;
> +void *ptr;
> +} obj;
> +static_assert(offsetof(struct Foo, a) == 0,
> + "First element of struct does not have offset 0");
> +static_assert(offsetof(struct Foo, ptr) >= offsetof(struct Foo, a) +
> sizeof(obj.a),
> + "elements not properly ordered in struct");
> +EOF
> +
> check_cppflags -D_FILE_OFFSET_BITS=64
> check_cppflags -D_LARGEFILE_SOURCE
>
Jan has tested old toolchains and found out that his GCC 4.7 has proper
C11 headers; so this seems to be unique to Michael's setup. This makes
me prefer this patch instead of the version with the fallback. (Michael
can simply add -Dstatic_assert=_Static_assert to his cflags.)
Of course others are still invited to share their opinions.
- Andreas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v2] configure: Explicitly check for static_assert
C11 provides static assertions via _Static_assert and
provides static_assert as a convenience define for this
in assert.h. MSVC 19.27 declares support for C11, but does
not support _Static_assert, but somehow supports
static_assert. That's therefore what we use.
But apparently there are some old GCC toolchains where
_Static_assert is supported, but assert.h does not provide
the fallback define. Some fate boxes are affected by this
[1].
This commit therefore checks whether static_assert works
with assert.h included; if not, it errors out. Users like
the above can still add -Dstatic_assert=_Static_assert
to cflags as a workaround.
[1]:
https://fate.ffmpeg.org/report.cgi?time=20240321123620=sh4-debian-qemu-gcc-4.7
Signed-off-by: Andreas Rheinhardt
---
This is what a test without fallback looks like.
Posted to gather opinions on what people prefer.
configure | 13 +
1 file changed, 13 insertions(+)
diff --git a/configure b/configure
index 6d7b33b0ff..c2d2c70c20 100755
--- a/configure
+++ b/configure
@@ -5589,6 +5589,19 @@ check_cxxflags_cc -std=$stdcxx ctype.h "__cplusplus >=
201103L" ||
check_cflags_cc -std=$stdc ctype.h "__STDC_VERSION__ >= 201112L" ||
{ check_cflags_cc -std=c11 ctype.h "__STDC_VERSION__ >= 201112L" &&
stdc="c11" || die "Compiler lacks C11 support"; }
+test_cc <
+#include
+struct Foo {
+int a;
+void *ptr;
+} obj;
+static_assert(offsetof(struct Foo, a) == 0,
+ "First element of struct does not have offset 0");
+static_assert(offsetof(struct Foo, ptr) >= offsetof(struct Foo, a) +
sizeof(obj.a),
+ "elements not properly ordered in struct");
+EOF
+
check_cppflags -D_FILE_OFFSET_BITS=64
check_cppflags -D_LARGEFILE_SOURCE
--
2.40.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 1/2] avcodec/hevc_ps: fix setting HEVCHdrParams fields
Mar 21, 2024, 00:17 by jamr...@gmail.com:
> These were defined in a way compatible with the Vulkan HEVC acceleration,
> which
> expects bitmasks, yet the fields were being overwritting on each loop with the
> latest read value.
>
> Signed-off-by: James Almer
> ---
> libavcodec/hevc_ps.c | 44 ++--
> libavcodec/hevc_ps.h | 15 +++---
> libavcodec/vulkan_hevc.c | 16 +++
> 3 files changed, 40 insertions(+), 35 deletions(-)
>
> diff --git a/libavcodec/hevc_ps.c b/libavcodec/hevc_ps.c
> index fb997066d9..20ceb09829 100644
> --- a/libavcodec/hevc_ps.c
> +++ b/libavcodec/hevc_ps.c
> @@ -370,7 +370,7 @@ static void decode_sublayer_hrd(GetBitContext *gb,
> unsigned int nb_cpb,
> par->bit_rate_du_value_minus1[i] = get_ue_golomb_long(gb);
> }
>
> -par->cbr_flag = get_bits1(gb);
> +par->cbr_flag |= get_bits1(gb) << i;
> }
> }
>
> @@ -378,24 +378,24 @@ static int decode_hrd(GetBitContext *gb, int
> common_inf_present,
> HEVCHdrParams *hdr, int max_sublayers)
> {
> if (common_inf_present) {
> -hdr->flags.nal_hrd_parameters_present_flag = get_bits1(gb);
> -hdr->flags.vcl_hrd_parameters_present_flag = get_bits1(gb);
> +hdr->nal_hrd_parameters_present_flag = get_bits1(gb);
> +hdr->vcl_hrd_parameters_present_flag = get_bits1(gb);
>
> -if (hdr->flags.nal_hrd_parameters_present_flag ||
> -hdr->flags.vcl_hrd_parameters_present_flag) {
> -hdr->flags.sub_pic_hrd_params_present_flag = get_bits1(gb);
> +if (hdr->nal_hrd_parameters_present_flag ||
> +hdr->vcl_hrd_parameters_present_flag) {
> +hdr->sub_pic_hrd_params_present_flag = get_bits1(gb);
>
> -if (hdr->flags.sub_pic_hrd_params_present_flag) {
> +if (hdr->sub_pic_hrd_params_present_flag) {
> hdr->tick_divisor_minus2 = get_bits(gb, 8);
> hdr->du_cpb_removal_delay_increment_length_minus1 = get_bits(gb, 5);
> -hdr->flags.sub_pic_cpb_params_in_pic_timing_sei_flag =
> get_bits1(gb);
> +hdr->sub_pic_cpb_params_in_pic_timing_sei_flag =
> get_bits1(gb);
> hdr->dpb_output_delay_du_length_minus1 = get_bits(gb, 5);
> }
>
> hdr->bit_rate_scale = get_bits(gb, 4);
> hdr->cpb_size_scale = get_bits(gb, 4);
>
> -if (hdr->flags.sub_pic_hrd_params_present_flag)
> +if (hdr->sub_pic_hrd_params_present_flag)
> hdr->cpb_size_du_scale = get_bits(gb, 4);
>
> hdr->initial_cpb_removal_delay_length_minus1 = get_bits(gb, 5);
> @@ -405,18 +405,22 @@ static int decode_hrd(GetBitContext *gb, int
> common_inf_present,
> }
>
> for (int i = 0; i < max_sublayers; i++) {
> -hdr->flags.fixed_pic_rate_general_flag = get_bits1(gb);
> +unsigned fixed_pic_rate_general_flag = get_bits1(gb);
> +unsigned fixed_pic_rate_within_cvs_flag = 0;
> +unsigned low_delay_hrd_flag = 0;
> +hdr->flags.fixed_pic_rate_general_flag |=
> fixed_pic_rate_general_flag << i;
>
> -if (!hdr->flags.fixed_pic_rate_general_flag)
> -hdr->flags.fixed_pic_rate_within_cvs_flag = get_bits1(gb);
> +if (!fixed_pic_rate_general_flag)
> +fixed_pic_rate_within_cvs_flag = get_bits1(gb);
> +hdr->flags.fixed_pic_rate_within_cvs_flag |=
> fixed_pic_rate_within_cvs_flag << i;
>
> -if (hdr->flags.fixed_pic_rate_within_cvs_flag ||
> -hdr->flags.fixed_pic_rate_general_flag)
> +if (fixed_pic_rate_within_cvs_flag || fixed_pic_rate_general_flag)
> hdr->elemental_duration_in_tc_minus1[i] = get_ue_golomb_long(gb);
> else
> -hdr->flags.low_delay_hrd_flag = get_bits1(gb);
> +low_delay_hrd_flag = get_bits1(gb);
> +hdr->flags.low_delay_hrd_flag |= low_delay_hrd_flag << i;
>
> -if (!hdr->flags.low_delay_hrd_flag) {
> +if (!low_delay_hrd_flag) {
> unsigned cpb_cnt_minus1 = get_ue_golomb_long(gb);
> if (cpb_cnt_minus1 > 31) {
> av_log(NULL, AV_LOG_ERROR, "nb_cpb %d invalid\n",
> @@ -426,13 +430,13 @@ static int decode_hrd(GetBitContext *gb, int
> common_inf_present,
> hdr->cpb_cnt_minus1[i] = cpb_cnt_minus1;
> }
>
> -if (hdr->flags.nal_hrd_parameters_present_flag)
> +if (hdr->nal_hrd_parameters_present_flag)
> decode_sublayer_hrd(gb, hdr->cpb_cnt_minus1[i]+1, >nal_params[i],
> -hdr->flags.sub_pic_hrd_params_present_flag);
> +hdr->sub_pic_hrd_params_present_flag);
>
> -if (hdr->flags.vcl_hrd_parameters_present_flag)
> +if (hdr->vcl_hrd_parameters_present_flag)
> decode_sublayer_hrd(gb, hdr->cpb_cnt_minus1[i]+1, >vcl_params[i],
> -hdr->flags.sub_pic_hrd_params_present_flag);
> +hdr->sub_pic_hrd_params_present_flag);
> }
>
> return 0;
> diff --git a/libavcodec/hevc_ps.h b/libavcodec/hevc_ps.h
> index 786c896709..88d6f617b5 100644
> ---
[FFmpeg-devel] [PATCH] [v4] avcodec/vaapi_encode: add customized surface alignment
This commit fixes issues with AMD HEVC encoding.
By default AMD hevc encoder asks for the alignment 64x16, while FFMPEG VAAPI
has 16x16.
Adding support for customized surface size from VASurfaceAttribAlignmentSize in
VAAPI version 1.21.0
Signed-off-by: Araz Iusubov
---
libavcodec/vaapi_encode.c | 11 +++
libavutil/hwcontext.h | 7 +++
libavutil/hwcontext_vaapi.c | 5 +
3 files changed, 23 insertions(+)
diff --git a/libavcodec/vaapi_encode.c b/libavcodec/vaapi_encode.c
index 940f0678a5..2a74db23b1 100644
--- a/libavcodec/vaapi_encode.c
+++ b/libavcodec/vaapi_encode.c
@@ -2711,6 +2711,17 @@ static av_cold int
vaapi_encode_create_recon_frames(AVCodecContext *avctx)
av_log(avctx, AV_LOG_DEBUG, "Using %s as format of "
"reconstructed frames.\n", av_get_pix_fmt_name(recon_format));
+if (constraints->log2_alignment) {
+ctx->surface_width = FFALIGN(avctx->width,
+ 1 << (constraints->log2_alignment & 0xf));
+ctx->surface_height = FFALIGN(avctx->height,
+ 1 << ((constraints->log2_alignment & 0xf0) >>
4));
+av_log(avctx, AV_LOG_VERBOSE, "Using customized alignment size "
+"[%dx%d].\n",
+(1 << (constraints->log2_alignment & 0xf)),
+(1 << ((constraints->log2_alignment & 0xf0) >> 4)));
+}
+
if (ctx->surface_width < constraints->min_width ||
ctx->surface_height < constraints->min_height ||
ctx->surface_width > constraints->max_width ||
diff --git a/libavutil/hwcontext.h b/libavutil/hwcontext.h
index bac30debae..1eb56aff78 100644
--- a/libavutil/hwcontext.h
+++ b/libavutil/hwcontext.h
@@ -465,6 +465,13 @@ typedef struct AVHWFramesConstraints {
*/
int max_width;
int max_height;
+
+/**
+ * The frame width/height log2 alignment when available
+ * the lower 4 bits, width; another 4 bits, height
+ * (Zero is not applied, use the default value)
+ */
+int log2_alignment;
} AVHWFramesConstraints;
/**
diff --git a/libavutil/hwcontext_vaapi.c b/libavutil/hwcontext_vaapi.c
index 56d03aa4cd..6cda0fd811 100644
--- a/libavutil/hwcontext_vaapi.c
+++ b/libavutil/hwcontext_vaapi.c
@@ -294,6 +294,11 @@ static int vaapi_frames_get_constraints(AVHWDeviceContext
*hwdev,
case VASurfaceAttribMaxHeight:
constraints->max_height = attr_list[i].value.value.i;
break;
+#if VA_CHECK_VERSION(1, 21, 0)
+case VASurfaceAttribAlignmentSize:
+constraints->log2_alignment = attr_list[i].value.value.i;
+break;
+#endif
}
}
if (pix_fmt_count == 0) {
--
2.43.0.windows.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v7 1/5] avformat/subtitles: extend ff_subtitles_queue_insert() to support empty events
Thank you Andreas, for walking me through this in detail. I will update accordingly and test. ___ 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 v7 1/5] avformat/subtitles: extend ff_subtitles_queue_insert() to support empty events
Marth64:
> If ff_subtitles_queue_insert() were to given a NULL buffer
> with 0 length, it would still attempt to grow the packet
> or memcpy depending on if merge option is enabled.
>
> In this commit, consider a NULL buffer with 0 length as
> an empty event and do not attempt to modify the packet.
> This way, if a subtitle demuxer happens to pass an empty
> cue or wants to use av_get_packet() to read bytes, there
> are no unnecessary operations on the packet after it is
> allocated.
>
> Signed-off-by: Marth64
> ---
> libavformat/subtitles.c | 4
> libavformat/subtitles.h | 2 +-
> 2 files changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/libavformat/subtitles.c b/libavformat/subtitles.c
> index 3413763c7b..38d2ffb8a9 100644
> --- a/libavformat/subtitles.c
> +++ b/libavformat/subtitles.c
> @@ -117,6 +117,8 @@ AVPacket *ff_subtitles_queue_insert(FFDemuxSubtitlesQueue
> *q,
> int old_len;
> sub = q->subs[q->nb_subs - 1];
> old_len = sub->size;
> +if (event == NULL && len == 0)
> +return sub;
Checks for NULL are typically written as !event. I'd prefer
if (!event) {
av_assert1(len == 0);
return sub;
}
as this also makes clear that !event with len > 0 must not happen and
also avoids one runtime check for ordinary users (with assert-level 0).
> if (av_grow_packet(sub, len) < 0)
> return NULL;
> memcpy(sub->data + old_len, event, len);
> @@ -140,6 +142,8 @@ AVPacket *ff_subtitles_queue_insert(FFDemuxSubtitlesQueue
> *q,
> subs[q->nb_subs++] = sub;
> sub->flags |= AV_PKT_FLAG_KEY;
> sub->pts = sub->dts = 0;
> +if (event == NULL && len == 0)
> +return sub;
> memcpy(sub->data, event, len);
This will allocate sub->data to a buffer of size
AV_INPUT_BUFFER_PADDING_SIZE and usable size of zero. This is not what
is intended: You should not allocate anything at all, i.e. skip
av_new_packet().
This small buffer (together with the AVBuffer and AVBufferRef allocated
for it) will leak with your current patch 2.
> }
> return sub;
> diff --git a/libavformat/subtitles.h b/libavformat/subtitles.h
> index 88665663c5..ba162fa503 100644
> --- a/libavformat/subtitles.h
> +++ b/libavformat/subtitles.h
> @@ -112,7 +112,7 @@ typedef struct {
> /**
> * Insert a new subtitle event.
> *
> - * @param event the subtitle line, may not be zero terminated
> + * @param event the subtitle line (not zero terminated), or NULL on empty
> event
on not yet available event
> * @param len the length of the event (in strlen() sense, so without '\0')
> * @param merge set to 1 if the current event should be concatenated with the
> * previous one instead of adding a new entry, 0 otherwise
___
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 v7 2/5] avformat/rcwtdec: add RCWT Closed Captions demuxer
Marth64:
> RCWT (Raw Captions With Time) is a format native to ccextractor,
> a commonly used OSS tool for processing 608/708 Closed Captions (CC).
> RCWT can be used to archive the original extracted CC bitstream.
> The muxer was added in January 2024. In this commit, add the demuxer.
>
> One can now demux RCWT files for rendering in ccaption_dec or interop
> with ccextractor (which produces RCWT). Using the muxer/demuxer combo,
> the CC bits can be kept for processing or rendering with either tool.
> This can be an effective way to backup an original CC stream, including
> format extensions like EIA-708 and overall original presentation.
>
> Signed-off-by: Marth64
> ---
> Changelog| 2 +-
> doc/demuxers.texi| 30 ++
> libavformat/Makefile | 1 +
> libavformat/allformats.c | 1 +
> libavformat/rcwtdec.c| 123 +++
> 5 files changed, 156 insertions(+), 1 deletion(-)
> create mode 100644 libavformat/rcwtdec.c
>
> diff --git a/Changelog b/Changelog
> index e3ca52430c..0ae05c6cce 100644
> --- a/Changelog
> +++ b/Changelog
> @@ -19,7 +19,7 @@ version :
> - lavu/eval: introduce randomi() function in expressions
> - VVC decoder
> - fsync filter
> -- Raw Captions with Time (RCWT) closed caption muxer
> +- RCWT (Raw Captions with Time) Closed Captions muxer and demuxer
> - ffmpeg CLI -bsf option may now be used for input as well as output
> - ffmpeg CLI options may now be used as -/opt , which is equivalent
>to -opt >
> diff --git a/doc/demuxers.texi b/doc/demuxers.texi
> index b70f3a38d7..b4c4daacd9 100644
> --- a/doc/demuxers.texi
> +++ b/doc/demuxers.texi
> @@ -1038,6 +1038,36 @@ the command:
> ffplay -f rawvideo -pixel_format rgb24 -video_size 320x240 -framerate 10
> input.raw
> @end example
>
> +@anchor{rcwtdec}
> +@section rcwt
> +
> +RCWT (Raw Captions With Time) is a format native to ccextractor, a commonly
> +used open source tool for processing 608/708 Closed Captions (CC) sources.
> +For more information on the format, see @ref{rcwtenc,,,ffmpeg-formats}.
> +
> +This demuxer implements the specification as of March 2024, which has
> +been stable and unchanged since April 2014.
> +
> +@subsection Examples
> +
> +@itemize
> +@item
> +Render Closed Captions to ASS, using the CC decoder (cc_dec):
> +@example
> +ffmpeg -i CC.rcwt.bin CC.ass
> +@end example
> +Note that if your output appears to be empty, you may have to manually
> +set the decoder's @option{data_field} option to pick the desired CC
> substream.
> +
> +@item
> +Convert an RCWT backup to SCC format, using the SCC muxer (scc):
> +@example
> +ffmpeg -i CC.rcwt.bin -c:s copy CC.scc
> +@end example
> +Note that the SCC format does not support all of the possible CC formats
> +that can be stored in RCWT.
> +@end itemize
> +
> @section sbg
>
> SBaGen script demuxer.
> diff --git a/libavformat/Makefile b/libavformat/Makefile
> index 94a949f555..a6de720d8c 100644
> --- a/libavformat/Makefile
> +++ b/libavformat/Makefile
> @@ -493,6 +493,7 @@ OBJS-$(CONFIG_QOA_DEMUXER) += qoadec.o
> OBJS-$(CONFIG_R3D_DEMUXER) += r3d.o
> OBJS-$(CONFIG_RAWVIDEO_DEMUXER) += rawvideodec.o
> OBJS-$(CONFIG_RAWVIDEO_MUXER)+= rawenc.o
> +OBJS-$(CONFIG_RCWT_DEMUXER) += rcwtdec.o subtitles.o
> OBJS-$(CONFIG_RCWT_MUXER)+= rcwtenc.o subtitles.o
> OBJS-$(CONFIG_REALTEXT_DEMUXER) += realtextdec.o subtitles.o
> OBJS-$(CONFIG_REDSPARK_DEMUXER) += redspark.o
> diff --git a/libavformat/allformats.c b/libavformat/allformats.c
> index e15d0fa6d7..3140018f8d 100644
> --- a/libavformat/allformats.c
> +++ b/libavformat/allformats.c
> @@ -391,6 +391,7 @@ extern const FFInputFormat ff_qoa_demuxer;
> extern const FFInputFormat ff_r3d_demuxer;
> extern const FFInputFormat ff_rawvideo_demuxer;
> extern const FFOutputFormat ff_rawvideo_muxer;
> +extern const FFInputFormat ff_rcwt_demuxer;
> extern const FFOutputFormat ff_rcwt_muxer;
> extern const FFInputFormat ff_realtext_demuxer;
> extern const FFInputFormat ff_redspark_demuxer;
> diff --git a/libavformat/rcwtdec.c b/libavformat/rcwtdec.c
> new file mode 100644
> index 00..e5cd05ea3e
> --- /dev/null
> +++ b/libavformat/rcwtdec.c
> @@ -0,0 +1,123 @@
> +/*
> + * RCWT (Raw Captions With Time) demuxer
> + *
> + * 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
[FFmpeg-devel] [PATCH] configure: Explicitly check for static_assert
C11 provides static assertions via _Static_assert and
provides static_assert as a convenience define for this
in assert.h. MSVC 19.27 declares support C11, but does
not support _Static_assert, but somehow supports
static_assert. That's therefore what we use.
But apparently there are some old GCC toolchains where
_Static_assert is supported, but assert.h does not provide
the fallback define. Some fate boxes are affected by this
[1].
This commit therefore checks whether static_assert works
with assert.h included; if not, it checks whether using
-Dstatic_assert=_Static_assert fixes it. Otherwise it errors
out.
[1]:
https://fate.ffmpeg.org/report.cgi?time=20240321123620=sh4-debian-qemu-gcc-4.7
Signed-off-by: Andreas Rheinhardt
---
configure | 15 +++
1 file changed, 15 insertions(+)
diff --git a/configure b/configure
index 6d7b33b0ff..61075608ea 100755
--- a/configure
+++ b/configure
@@ -5589,6 +5589,21 @@ check_cxxflags_cc -std=$stdcxx ctype.h "__cplusplus >=
201103L" ||
check_cflags_cc -std=$stdc ctype.h "__STDC_VERSION__ >= 201112L" ||
{ check_cflags_cc -std=c11 ctype.h "__STDC_VERSION__ >= 201112L" &&
stdc="c11" || die "Compiler lacks C11 support"; }
+for static_assert in "" _Static_assert; do
+test_cc ${static_assert:+-Dstatic_assert=$static_assert} <
+#include
+struct Foo {
+int a;
+void *ptr;
+} obj;
+static_assert(offsetof(struct Foo, a) == 0,
+ "First element of struct does not have offset 0");
+static_assert(offsetof(struct Foo, ptr) >= offsetof(struct Foo, a) +
sizeof(obj.a),
+ "elements not properly ordered in struct");
+EOF
+done || die "Compiler lacks support for C11 static_assert"
+
check_cppflags -D_FILE_OFFSET_BITS=64
check_cppflags -D_LARGEFILE_SOURCE
--
2.40.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] [FFmpeg-devel, v3] avcodec/vaapi_encode: add customized surface alignment
This commit fixes issues with AMD HEVC encoding.
By default AMD hevc encoder asks for the alignment 64x16, while FFMPEG VAAPI
has 16x16.
Adding support for customized surface size from VASurfaceAttribAlignmentSize in
VAAPI version 1.21.0
Signed-off-by: Araz Iusubov
---
libavcodec/vaapi_encode.c | 11 +++
libavutil/hwcontext.h | 7 +++
libavutil/hwcontext_vaapi.c | 5 +
3 files changed, 23 insertions(+)
diff --git a/libavcodec/vaapi_encode.c b/libavcodec/vaapi_encode.c
index 940f0678a5..2a74db23b1 100644
--- a/libavcodec/vaapi_encode.c
+++ b/libavcodec/vaapi_encode.c
@@ -2711,6 +2711,17 @@ static av_cold int
vaapi_encode_create_recon_frames(AVCodecContext *avctx)
av_log(avctx, AV_LOG_DEBUG, "Using %s as format of "
"reconstructed frames.\n", av_get_pix_fmt_name(recon_format));
+if (constraints->log2_alignment) {
+ctx->surface_width = FFALIGN(avctx->width,
+ 1 << (constraints->log2_alignment & 0xf));
+ctx->surface_height = FFALIGN(avctx->height,
+ 1 << ((constraints->log2_alignment & 0xf0) >>
4));
+av_log(avctx, AV_LOG_VERBOSE, "Using customized alignment size "
+"[%dx%d].\n",
+(1 << (constraints->log2_alignment & 0xf)),
+(1 << ((constraints->log2_alignment & 0xf0) >> 4)));
+}
+
if (ctx->surface_width < constraints->min_width ||
ctx->surface_height < constraints->min_height ||
ctx->surface_width > constraints->max_width ||
diff --git a/libavutil/hwcontext.h b/libavutil/hwcontext.h
index bac30debae..1eb56aff78 100644
--- a/libavutil/hwcontext.h
+++ b/libavutil/hwcontext.h
@@ -465,6 +465,13 @@ typedef struct AVHWFramesConstraints {
*/
int max_width;
int max_height;
+
+/**
+ * The frame width/height log2 alignment when available
+ * the lower 4 bits, width; another 4 bits, height
+ * (Zero is not applied, use the default value)
+ */
+int log2_alignment;
} AVHWFramesConstraints;
/**
diff --git a/libavutil/hwcontext_vaapi.c b/libavutil/hwcontext_vaapi.c
index 56d03aa4cd..6cda0fd811 100644
--- a/libavutil/hwcontext_vaapi.c
+++ b/libavutil/hwcontext_vaapi.c
@@ -294,6 +294,11 @@ static int vaapi_frames_get_constraints(AVHWDeviceContext
*hwdev,
case VASurfaceAttribMaxHeight:
constraints->max_height = attr_list[i].value.value.i;
break;
+#if VA_CHECK_VERSION(1, 21, 0)
+case VASurfaceAttribAlignmentSize:
+constraints->log2_alignment = attr_list[i].value.value.i;
+break;
+#endif
}
}
if (pix_fmt_count == 0) {
--
2.43.0.windows.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v6] avcodec/libx264: fix extradata when config annexb=0
Ping. Will apply this week if no more comments.
> -Original Message-
> From: ffmpeg-devel On Behalf Of Zhao Zhili
> Sent: 2024年3月17日 11:35
> To: ffmpeg-devel@ffmpeg.org
> Cc: Zhao Zhili
> Subject: [FFmpeg-devel] [PATCH v6] avcodec/libx264: fix extradata when config
> annexb=0
>
> From: Zhao Zhili
>
> ---
> v6: use av_assert2
> select golomb in configure
> conditional compile in case of CONFIG_LIBX264_ENCODER=0
> v5: Decode chroma_format_idc directly instead of
> ff_h264_decode_seq_parameter_set
> v4: Fix missing SEI in set_avcc_extradata
> v3: Remove unnecessary inclusion
>
> configure| 2 +-
> libavcodec/libx264.c | 166 ---
> 2 files changed, 143 insertions(+), 25 deletions(-)
>
> diff --git a/configure b/configure
> index 2b4c4ec9a2..d9d2183a47 100755
> --- a/configure
> +++ b/configure
> @@ -3484,7 +3484,7 @@ libwebp_encoder_deps="libwebp"
> libwebp_anim_encoder_deps="libwebp"
> libx262_encoder_deps="libx262"
> libx264_encoder_deps="libx264"
> -libx264_encoder_select="atsc_a53"
> +libx264_encoder_select="atsc_a53 golomb"
> libx264rgb_encoder_deps="libx264"
> libx264rgb_encoder_select="libx264_encoder"
> libx265_encoder_deps="libx265"
> diff --git a/libavcodec/libx264.c b/libavcodec/libx264.c
> index 0997c4e134..ddec06d960 100644
> --- a/libavcodec/libx264.c
> +++ b/libavcodec/libx264.c
> @@ -38,6 +38,7 @@
> #include "packet_internal.h"
> #include "atsc_a53.h"
> #include "sei.h"
> +#include "golomb.h"
>
> #include
> #include
> @@ -847,6 +848,144 @@ static int convert_pix_fmt(enum AVPixelFormat pix_fmt)
> return 0;
> }
>
> +static int save_sei(AVCodecContext *avctx, x264_nal_t *nal)
> +{
> +X264Context *x4 = avctx->priv_data;
> +
> +av_log(avctx, AV_LOG_INFO, "%s\n", nal->p_payload + 25);
> +x4->sei_size = nal->i_payload;
> +x4->sei = av_malloc(x4->sei_size);
> +if (!x4->sei)
> +return AVERROR(ENOMEM);
> +
> +memcpy(x4->sei, nal->p_payload, nal->i_payload);
> +
> +return 0;
> +}
> +
> +#if CONFIG_LIBX264_ENCODER
> +static int set_avcc_extradata(AVCodecContext *avctx, x264_nal_t *nal, int
> nnal)
> +{
> +X264Context *x4 = avctx->priv_data;
> +x264_nal_t *sps_nal = NULL;
> +x264_nal_t *pps_nal = NULL;
> +uint8_t *p, *sps;
> +int ret;
> +
> +/* We know it's in the order of SPS/PPS/SEI, but it's not documented in
> x264 API.
> + * The x264 param i_sps_id implies there is a single pair of SPS/PPS.
> + */
> +for (int i = 0; i < nnal; i++) {
> +switch (nal[i].i_type) {
> +case NAL_SPS:
> +sps_nal = [i];
> +break;
> +case NAL_PPS:
> +pps_nal = [i];
> +break;
> +case NAL_SEI:
> +ret = save_sei(avctx, [i]);
> +if (ret < 0)
> +return ret;
> +break;
> +}
> +}
> +if (!sps_nal || !pps_nal)
> +return AVERROR_EXTERNAL;
> +
> +avctx->extradata_size = sps_nal->i_payload + pps_nal->i_payload + 7;
> +avctx->extradata = av_mallocz(avctx->extradata_size +
> AV_INPUT_BUFFER_PADDING_SIZE);
> +if (!avctx->extradata)
> +return AVERROR(ENOMEM);
> +
> +// Now create AVCDecoderConfigurationRecord
> +p = avctx->extradata;
> +// Skip size part
> +sps = sps_nal->p_payload + 4;
> +*p++ = 1; // version
> +*p++ = sps[1]; // AVCProfileIndication
> +*p++ = sps[2]; // profile_compatibility
> +*p++ = sps[3]; // AVCLevelIndication
> +*p++ = 0xFF;
> +*p++ = 0xE0 | 0x01; // 3 bits reserved (111) + 5 bits number of sps
> +memcpy(p, sps_nal->p_payload + 2, sps_nal->i_payload - 2);
> +// Make sps has AV_INPUT_BUFFER_PADDING_SIZE padding, so it can be used
> +// with GetBitContext
> +sps = p + 2;
> +p += sps_nal->i_payload - 2;
> +*p++ = 1;
> +memcpy(p, pps_nal->p_payload + 2, pps_nal->i_payload - 2);
> +p += pps_nal->i_payload - 2;
> +
> +if (sps[3] != 66 && sps[3] != 77 && sps[3] != 88) {
> +GetBitContext gbc;
> +int chroma_format_idc;
> +int bit_depth_luma_minus8, bit_depth_chroma_minus8;
> +
> +/* It's not possible to have emulation prevention byte before
> + * bit_depth_chroma_minus8 due to the range of sps id,
> chroma_format_idc
> + * and so on. So we can read directly without need to escape
> emulation
> + * prevention byte.
> + *
> + * +4 to skip until sps id.
> + */
> +init_get_bits8(, sps + 4, sps_nal->i_payload - 4 - 4);
> +// Skip sps id
> +get_ue_golomb_31();
> +chroma_format_idc = get_ue_golomb_31();
> +if (chroma_format_idc == 3)
> +skip_bits1();
> +bit_depth_luma_minus8 = get_ue_golomb_31();
> +bit_depth_chroma_minus8 = get_ue_golomb_31();
> +
> +*p++ = 0xFC | chroma_format_idc;
> +*p++ = 0xF8 | bit_depth_luma_minus8;
> +*p++ = 0xF8 |
[FFmpeg-devel] [PATCH] [FFmpeg-devel, v2] avcodec/vaapi_encode: add customized surface alignment
This commit fixes issues with AMD HEVC encoding.
By default AMD hevc encoder asks for the alignment 64x16, while FFMPEG VAAPI
has 16x16.
Adding support for customized surface size from VASurfaceAttribAlignmentSize in
VAAPI version 1.21.0
Signed-off-by: Araz Iusubov
---
libavcodec/vaapi_encode.c | 11 +++
libavutil/hwcontext.h | 7 +++
libavutil/hwcontext_vaapi.c | 5 +
3 files changed, 23 insertions(+)
diff --git a/libavcodec/vaapi_encode.c b/libavcodec/vaapi_encode.c
index 940f0678a5..2a74db23b1 100644
--- a/libavcodec/vaapi_encode.c
+++ b/libavcodec/vaapi_encode.c
@@ -2711,6 +2711,17 @@ static av_cold int
vaapi_encode_create_recon_frames(AVCodecContext *avctx)
av_log(avctx, AV_LOG_DEBUG, "Using %s as format of "
"reconstructed frames.\n", av_get_pix_fmt_name(recon_format));
+if (constraints->log2_alignment) {
+ctx->surface_width = FFALIGN(avctx->width,
+ 1 << (constraints->log2_alignment & 0xf));
+ctx->surface_height = FFALIGN(avctx->height,
+ 1 << ((constraints->log2_alignment & 0xf0) >>
4));
+av_log(avctx, AV_LOG_VERBOSE, "Using customized alignment size "
+"[%dx%d].\n",
+(1 << (constraints->log2_alignment & 0xf)),
+(1 << ((constraints->log2_alignment & 0xf0) >> 4)));
+}
+
if (ctx->surface_width < constraints->min_width ||
ctx->surface_height < constraints->min_height ||
ctx->surface_width > constraints->max_width ||
diff --git a/libavutil/hwcontext.h b/libavutil/hwcontext.h
index bac30debae..1eb56aff78 100644
--- a/libavutil/hwcontext.h
+++ b/libavutil/hwcontext.h
@@ -465,6 +465,13 @@ typedef struct AVHWFramesConstraints {
*/
int max_width;
int max_height;
+
+/**
+ * The frame width/height log2 alignment when available
+ * the lower 4 bits, width; another 4 bits, height
+ * (Zero is not applied, use the default value)
+ */
+int log2_alignment;
} AVHWFramesConstraints;
/**
diff --git a/libavutil/hwcontext_vaapi.c b/libavutil/hwcontext_vaapi.c
index 56d03aa4cd..6cda0fd811 100644
--- a/libavutil/hwcontext_vaapi.c
+++ b/libavutil/hwcontext_vaapi.c
@@ -294,6 +294,11 @@ static int vaapi_frames_get_constraints(AVHWDeviceContext
*hwdev,
case VASurfaceAttribMaxHeight:
constraints->max_height = attr_list[i].value.value.i;
break;
+#if VA_CHECK_VERSION(1, 21, 0)
+case VASurfaceAttribAlignmentSize:
+constraints->log2_alignment = attr_list[i].value.value.i;
+break;
+#endif
}
}
if (pix_fmt_count == 0) {
--
2.43.0.windows.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 1/4] avcodec/jpeg2000htdec: Check M_b / magp before using it in a shift
ons 2024-03-20 klockan 21:35 +0100 skrev Tomas Härdin: > ons 2024-03-20 klockan 14:12 +0100 skrev Michael Niedermayer: > > On Wed, Mar 20, 2024 at 12:20:11PM +0100, Tomas Härdin wrote: > > > ons 2024-03-20 klockan 03:59 +0100 skrev Michael Niedermayer: > > > > Fixes: shift exponent -1 is negative > > > > Fixes: 65378/clusterfuzz-testcase-minimized- > > > > ffmpeg_AV_CODEC_ID_JPEG2000_fuzzer-5457678193197056 > > > > > > > > Found-by: continuous fuzzing process > > > > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg > > > > Signed-off-by: Michael Niedermayer > > > > --- > > > > libavcodec/jpeg2000htdec.c | 3 +++ > > > > 1 file changed, 3 insertions(+) > > > > > > > > diff --git a/libavcodec/jpeg2000htdec.c > > > > b/libavcodec/jpeg2000htdec.c > > > > index 6b9898d3ff..0b94bb5da2 100644 > > > > --- a/libavcodec/jpeg2000htdec.c > > > > +++ b/libavcodec/jpeg2000htdec.c > > > > @@ -1193,6 +1193,9 @@ ff_jpeg2000_decode_htj2k(const > > > > Jpeg2000DecoderContext *s, Jpeg2000CodingStyle *c > > > > > > > > int32_t M_b = magp; > > > > > > > > + if (magp >= 31) > > > > + return AVERROR_INVALIDDATA; > > > > > > This isn't where the error is, assuming it even is an error. It's > > > either expn or nguardbits that are wrong, and they should be > > > detected > > > and reported as such in jpeg2000dec.c. Checking this in every > > > call > > > to > > > ff_jpeg2000_decode_htj2k() is wasteful. > > > > > > nguardbits can be 0..7 and expn can be 0..31. Table A.11 > > > indicates > > > that > > > Ssize can be up to 38 bits, so M_b >= 31 is in fact perfectly > > > valid. > > > > > A > > > more appropriate error might be AVERROR_PATCHWELCOME. > > > > indeed, i will change it to AVERROR_PATCHWELCOME > > Please also move it further up so as to not waste cycles checking it > every time To be more precise, get_qcx() looks like the proper place for it /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] avformat/flvenc: Avoid avio_write(pb, "", 0)
On Thu, 21 Mar 2024 at 13:13, Andreas Rheinhardt < andreas.rheinha...@outlook.com> wrote: > Andreas Rheinhardt: > > When the compiler chooses to inline put_amf_string(pb, ""), > > the avio_write(pb, "", 0) can be avoided. Happens with > > Clang-17 with -O1 and higher and GCC 13 with -O2 and higher > > here. > Are you able to add a comment in the code? It's not 100% clear what you are doing. Kieran ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avformat/flvenc: Avoid avio_write(pb, "", 0)
Andreas Rheinhardt:
> When the compiler chooses to inline put_amf_string(pb, ""),
> the avio_write(pb, "", 0) can be avoided. Happens with
> Clang-17 with -O1 and higher and GCC 13 with -O2 and higher
> here.
>
> Signed-off-by: Andreas Rheinhardt
> ---
> libavformat/flvenc.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/libavformat/flvenc.c b/libavformat/flvenc.c
> index 7e410e627e..d6c9124d5d 100644
> --- a/libavformat/flvenc.c
> +++ b/libavformat/flvenc.c
> @@ -231,6 +231,8 @@ static void put_amf_string(AVIOContext *pb, const char
> *str)
> {
> size_t len = strlen(str);
> avio_wb16(pb, len);
> +if (av_builtin_constant_p(len == 0) && len == 0)
> +return;
> avio_write(pb, str, len);
> }
>
Will apply this patch tomorrow unless there are objections.
- 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] avformat: enable UDP IPv6 multicast interface selection
> Your MR makes even less sense for multicast. For multicast there is no local > address to match to an interface. So you just have to have the interface > specified explicitly in addition to the LL group address. This is true for > both egress and ingress. I've compared ffmpeg 5.1.2 against my MR on IPv6 multicast. Here are the results: Recv (on interface other than default) | Address| localaddr | 5.1.2 | MR | | -- | - | - | --- | | FF11::1| null | NO| NO | | FF11::1| iface addr| NO| YES | | FF11::1%eth0 | null | NO| YES | | FF12::1| null | NO| NO | | FF12::1| iface addr| NO| YES | | FF12::1%eth0 | null | NO| YES | | FF14::1| null | NO| NO | | FF14::1| iface addr| NO| YES | | FF14::1%eth0 | null | NO| NO | | FF15::1| null | NO| NO | | FF15::1| iface addr| NO| YES | | FF15::1%eth0 | null | NO| NO | | FF18::1| null | NO| NO | | FF18::1| iface addr| NO| YES | | FF18::1%eth0 | null | NO| NO | Send (on interface other than default) | Address| localaddr | 5.1.2 | MR | | -- | - | - | --- | | FF11::1| null | NO| NO | | FF11::1| iface addr| NO| YES | | FF11::1%eth0 | null | YES | YES | | FF12::1| null | NO| NO | | FF12::1| iface addr| NO| YES | | FF12::1%eth0 | null | YES | YES | | FF14::1| null | NO| NO | | FF14::1| iface addr| NO| YES | | FF14::1%eth0 | null | NO| NO | | FF15::1| null | NO| NO | | FF15::1| iface addr| NO| YES | | FF15::1%eth0 | null | NO| NO | | FF18::1| null | NO| NO | | FF18::1| iface addr| NO| YES | | FF18::1%eth0 | null | NO| NO | Here are the reasons why the combinations marked NO under my MR don’t work: FF11::1 -> ambiguous interface on which to listen/send FF12::1 -> ambiguous interface on which to listen/send FF14::1 -> ambiguous interface on which to listen/send, uses only default iface FF14::1%eth0 -> getaddrinfo errors as it supports %scope only for link-local FF15::1 -> ambiguous interface on which to listen/send, uses only default iface FF15::1%eth0 -> getaddrinfo errors as it supports %scope only for link-local FF18::1 -> ambiguous interface on which to listen/send, uses only default iface FF18::1%eth0 -> getaddrinfo errors as it supports %scope only for link-local So the problem to overcome here is controlling on which interface we listen/send multicat IPv6. For link local yes, %scope is the way to go. I proposed this MR as the solution to the problem, keepeng the `localaddr` parameter semantics the same as with IPv4. Other solution could be introduction of a new parameter, as I said before. In this case then, the documentation should be changed to reflect that `localaddr` is only used for IPv4 addresses, and that same functionality can be obtained with this new parameter under IPv6. There will certainly be V3 of the patch, as I've identified minor changes needed for this approach. If you have any other ideas, I'm open to hearing them. Lazar Ignjatović Associate Software Engineer Cubic Defense cubic.com This message has been marked as Public on 03/21/2024 13:01Z. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avcodec/hevc_ps: allocate only the required HEVCHdrParams within a VPS
James Almer:
> Signed-off-by: James Almer
> ---
> libavcodec/hevc_ps.c | 14 +-
> libavcodec/hevc_ps.h | 2 +-
> 2 files changed, 14 insertions(+), 2 deletions(-)
>
> diff --git a/libavcodec/hevc_ps.c b/libavcodec/hevc_ps.c
> index fb997066d9..d29cf9f372 100644
> --- a/libavcodec/hevc_ps.c
> +++ b/libavcodec/hevc_ps.c
> @@ -438,13 +438,20 @@ static int decode_hrd(GetBitContext *gb, int
> common_inf_present,
> return 0;
> }
>
> +static void uninit_vps(FFRefStructOpaque opaque, void *obj)
> +{
> +HEVCVPS *vps = obj;
> +
> +av_freep(>hdr);
> +}
> +
> int ff_hevc_decode_nal_vps(GetBitContext *gb, AVCodecContext *avctx,
> HEVCParamSets *ps)
> {
> int i,j;
> int vps_id = 0;
> ptrdiff_t nal_size;
> -HEVCVPS *vps = ff_refstruct_allocz(sizeof(*vps));
> +HEVCVPS *vps = ff_refstruct_alloc_ext(sizeof(*vps), 0, NULL, uninit_vps);
>
> if (!vps)
> return AVERROR(ENOMEM);
> @@ -533,6 +540,11 @@ int ff_hevc_decode_nal_vps(GetBitContext *gb,
> AVCodecContext *avctx,
> "vps_num_hrd_parameters %d is invalid\n",
> vps->vps_num_hrd_parameters);
> goto err;
> }
> +
> +vps->hdr = av_calloc(vps->vps_num_hrd_parameters, sizeof(*vps->hdr));
> +if (!vps->hdr)
> +goto err;
> +
> for (i = 0; i < vps->vps_num_hrd_parameters; i++) {
> int common_inf_present = 1;
>
> diff --git a/libavcodec/hevc_ps.h b/libavcodec/hevc_ps.h
> index 786c896709..87cea479e9 100644
> --- a/libavcodec/hevc_ps.h
> +++ b/libavcodec/hevc_ps.h
> @@ -152,7 +152,7 @@ typedef struct PTL {
>
> typedef struct HEVCVPS {
> unsigned int vps_id;
> -HEVCHdrParams hdr[HEVC_MAX_LAYER_SETS];
> +HEVCHdrParams *hdr;
>
> uint8_t vps_temporal_id_nesting_flag;
> int vps_max_layers;
That's what I had in mind.
- Andreas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] avcodec/hevc_ps: allocate only the required HEVCHdrParams within a VPS
Signed-off-by: James Almer
---
libavcodec/hevc_ps.c | 14 +-
libavcodec/hevc_ps.h | 2 +-
2 files changed, 14 insertions(+), 2 deletions(-)
diff --git a/libavcodec/hevc_ps.c b/libavcodec/hevc_ps.c
index fb997066d9..d29cf9f372 100644
--- a/libavcodec/hevc_ps.c
+++ b/libavcodec/hevc_ps.c
@@ -438,13 +438,20 @@ static int decode_hrd(GetBitContext *gb, int
common_inf_present,
return 0;
}
+static void uninit_vps(FFRefStructOpaque opaque, void *obj)
+{
+HEVCVPS *vps = obj;
+
+av_freep(>hdr);
+}
+
int ff_hevc_decode_nal_vps(GetBitContext *gb, AVCodecContext *avctx,
HEVCParamSets *ps)
{
int i,j;
int vps_id = 0;
ptrdiff_t nal_size;
-HEVCVPS *vps = ff_refstruct_allocz(sizeof(*vps));
+HEVCVPS *vps = ff_refstruct_alloc_ext(sizeof(*vps), 0, NULL, uninit_vps);
if (!vps)
return AVERROR(ENOMEM);
@@ -533,6 +540,11 @@ int ff_hevc_decode_nal_vps(GetBitContext *gb,
AVCodecContext *avctx,
"vps_num_hrd_parameters %d is invalid\n",
vps->vps_num_hrd_parameters);
goto err;
}
+
+vps->hdr = av_calloc(vps->vps_num_hrd_parameters, sizeof(*vps->hdr));
+if (!vps->hdr)
+goto err;
+
for (i = 0; i < vps->vps_num_hrd_parameters; i++) {
int common_inf_present = 1;
diff --git a/libavcodec/hevc_ps.h b/libavcodec/hevc_ps.h
index 786c896709..87cea479e9 100644
--- a/libavcodec/hevc_ps.h
+++ b/libavcodec/hevc_ps.h
@@ -152,7 +152,7 @@ typedef struct PTL {
typedef struct HEVCVPS {
unsigned int vps_id;
-HEVCHdrParams hdr[HEVC_MAX_LAYER_SETS];
+HEVCHdrParams *hdr;
uint8_t vps_temporal_id_nesting_flag;
int vps_max_layers;
--
2.44.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 2/2] avformat/demux: Combine "Packet corrupt" logmessages
Otherwise these statements might be torn apart by
av_logs from other threads.
Signed-off-by: Andreas Rheinhardt
---
libavformat/demux.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/libavformat/demux.c b/libavformat/demux.c
index 4345ed4c8c..e50d1a9cfe 100644
--- a/libavformat/demux.c
+++ b/libavformat/demux.c
@@ -572,14 +572,13 @@ static int handle_new_packet(AVFormatContext *s, AVPacket
*pkt, int allow_passth
if (pkt->flags & AV_PKT_FLAG_CORRUPT) {
av_log(s, AV_LOG_WARNING,
- "Packet corrupt (stream = %d, dts = %s)",
- pkt->stream_index, av_ts2str(pkt->dts));
+ "Packet corrupt (stream = %d, dts = %s)%s.\n",
+ pkt->stream_index, av_ts2str(pkt->dts),
+ s->flags & AVFMT_FLAG_DISCARD_CORRUPT ? ", dropping it" : "");
if (s->flags & AVFMT_FLAG_DISCARD_CORRUPT) {
-av_log(s, AV_LOG_WARNING, ", dropping it.\n");
av_packet_unref(pkt);
return 1;
}
-av_log(s, AV_LOG_WARNING, ".\n");
}
st = s->streams[pkt->stream_index];
--
2.40.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 1/2] avformat/demux: Restore pkt->stream_index assert check
It has been moved after "st = s->streams[pkt->stream_index]"
in b140b8332c617b0eef4f872f3ef90c469e99920f.
Deduplicate ff_read_packet() and ff_buffer_packet()
while fixing this.
This also fixes shadowing in ff_read_packet().
Signed-off-by: Andreas Rheinhardt
---
libavformat/demux.c | 75 +++--
1 file changed, 31 insertions(+), 44 deletions(-)
diff --git a/libavformat/demux.c b/libavformat/demux.c
index 4c50eb5568..4345ed4c8c 100644
--- a/libavformat/demux.c
+++ b/libavformat/demux.c
@@ -532,9 +532,6 @@ static void update_timestamps(AVFormatContext *s, AVStream
*st, AVPacket *pkt)
{
FFStream *const sti = ffstream(st);
-av_assert0(pkt->stream_index < (unsigned)s->nb_streams &&
- "Invalid stream index.\n");
-
if (update_wrap_reference(s, st, pkt->stream_index, pkt) &&
sti->pts_wrap_behavior == AV_PTS_WRAP_SUB_OFFSET) {
// correct first time stamps to negative values
if (!is_relative(sti->first_dts))
@@ -555,13 +552,24 @@ static void update_timestamps(AVFormatContext *s,
AVStream *st, AVPacket *pkt)
pkt->dts = pkt->pts = av_rescale_q(av_gettime(), AV_TIME_BASE_Q,
st->time_base);
}
-int ff_buffer_packet(AVFormatContext *s, AVPacket *pkt)
+/**
+ * Handle a new packet and either return it directly if possible and
+ * allow_passthrough is true or queue the packet (or drop the packet
+ * if corrupt).
+ *
+ * @return < 0 on error, 0 if the packet was passed through,
+ * 1 if it was queued or dropped
+ */
+static int handle_new_packet(AVFormatContext *s, AVPacket *pkt, int
allow_passthrough)
{
FFFormatContext *const si = ffformatcontext(s);
-AVStream *st = s->streams[pkt->stream_index];
-FFStream *sti = ffstream(st);
+AVStream *st;
+FFStream *sti;
int err;
+av_assert0(pkt->stream_index < (unsigned)s->nb_streams &&
+ "Invalid stream index.\n");
+
if (pkt->flags & AV_PKT_FLAG_CORRUPT) {
av_log(s, AV_LOG_WARNING,
"Packet corrupt (stream = %d, dts = %s)",
@@ -569,13 +577,19 @@ int ff_buffer_packet(AVFormatContext *s, AVPacket *pkt)
if (s->flags & AVFMT_FLAG_DISCARD_CORRUPT) {
av_log(s, AV_LOG_WARNING, ", dropping it.\n");
av_packet_unref(pkt);
-return 0;
+return 1;
}
av_log(s, AV_LOG_WARNING, ".\n");
}
+st = s->streams[pkt->stream_index];
+sti = ffstream(st);
+
update_timestamps(s, st, pkt);
+if (sti->request_probe <= 0 && allow_passthrough &&
!si->raw_packet_buffer.head)
+return 0;
+
err = avpriv_packet_list_put(>raw_packet_buffer, pkt, NULL, 0);
if (err < 0) {
av_packet_unref(pkt);
@@ -585,14 +599,18 @@ int ff_buffer_packet(AVFormatContext *s, AVPacket *pkt)
pkt = >raw_packet_buffer.tail->pkt;
si->raw_packet_buffer_size += pkt->size;
-if (sti->request_probe <= 0)
-return 0;
-
err = probe_codec(s, st, pkt);
if (err < 0)
return err;
-return 0;
+return 1;
+}
+
+int ff_buffer_packet(AVFormatContext *s, AVPacket *pkt)
+{
+int err = handle_new_packet(s, pkt, 0);
+
+return err < 0 ? err : 0;
}
int ff_read_packet(AVFormatContext *s, AVPacket *pkt)
@@ -612,9 +630,6 @@ FF_ENABLE_DEPRECATION_WARNINGS
for (;;) {
PacketListEntry *pktl = si->raw_packet_buffer.head;
-AVStream *st;
-FFStream *sti;
-const AVPacket *pkt1;
if (pktl) {
AVStream *const st = s->streams[pktl->pkt.stream_index];
@@ -656,36 +671,8 @@ FF_ENABLE_DEPRECATION_WARNINGS
return err;
}
-if (pkt->flags & AV_PKT_FLAG_CORRUPT) {
-av_log(s, AV_LOG_WARNING,
- "Packet corrupt (stream = %d, dts = %s)",
- pkt->stream_index, av_ts2str(pkt->dts));
-if (s->flags & AVFMT_FLAG_DISCARD_CORRUPT) {
-av_log(s, AV_LOG_WARNING, ", dropping it.\n");
-av_packet_unref(pkt);
-continue;
-}
-av_log(s, AV_LOG_WARNING, ".\n");
-}
-
-st = s->streams[pkt->stream_index];
-sti = ffstream(st);
-
-update_timestamps(s, st, pkt);
-
-if (!pktl && sti->request_probe <= 0)
-return 0;
-
-err = avpriv_packet_list_put(>raw_packet_buffer,
- pkt, NULL, 0);
-if (err < 0) {
-av_packet_unref(pkt);
-return err;
-}
-pkt1 = >raw_packet_buffer.tail->pkt;
-si->raw_packet_buffer_size += pkt1->size;
-
-if ((err = probe_codec(s, st, pkt1)) < 0)
+err = handle_new_packet(s, pkt, 1);
+if (err <= 0) /* Error or passthrough */
return err;
}
}
--
2.40.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit
Re: [FFmpeg-devel] [PATCH] avcodec/hevc_ps: allocate only the required HEVCHdrParams within a VPS
James Almer:
> On 3/21/2024 8:15 AM, Andreas Rheinhardt wrote:
>> James Almer:
>>> Signed-off-by: James Almer
>>> ---
>>> libavcodec/hevc_ps.c | 17 +++--
>>> libavcodec/hevc_ps.h | 2 +-
>>> libavcodec/vulkan_hevc.c | 2 +-
>>> 3 files changed, 17 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/libavcodec/hevc_ps.c b/libavcodec/hevc_ps.c
>>> index 20ceb09829..d3edc0810d 100644
>>> --- a/libavcodec/hevc_ps.c
>>> +++ b/libavcodec/hevc_ps.c
>>> @@ -442,13 +442,21 @@ static int decode_hrd(GetBitContext *gb, int
>>> common_inf_present,
>>> return 0;
>>> }
>>> +static void uninit_vps(FFRefStructOpaque opaque, void *obj)
>>> +{
>>> + HEVCVPS *vps = obj;
>>> +
>>> + for (int i = 0; i < vps->vps_num_hrd_parameters; i++)
>>> + ff_refstruct_unref(>hdr[i]);
>>> +}
>>> +
>>> int ff_hevc_decode_nal_vps(GetBitContext *gb, AVCodecContext *avctx,
>>> HEVCParamSets *ps)
>>> {
>>> int i,j;
>>> int vps_id = 0;
>>> ptrdiff_t nal_size;
>>> - HEVCVPS *vps = ff_refstruct_allocz(sizeof(*vps));
>>> + HEVCVPS *vps = ff_refstruct_alloc_ext(sizeof(*vps), 0, NULL,
>>> uninit_vps);
>>> if (!vps)
>>> return AVERROR(ENOMEM);
>>> @@ -538,12 +546,17 @@ int ff_hevc_decode_nal_vps(GetBitContext *gb,
>>> AVCodecContext *avctx,
>>> goto err;
>>> }
>>> for (i = 0; i < vps->vps_num_hrd_parameters; i++) {
>>> + HEVCHdrParams *hdr = ff_refstruct_allocz(sizeof(*hdr));
>>> int common_inf_present = 1;
>>> + if (!hdr)
>>> + return AVERROR(ENOMEM);
>>> +
>>> get_ue_golomb_long(gb); // hrd_layer_set_idx
>>> if (i)
>>> common_inf_present = get_bits1(gb);
>>> - decode_hrd(gb, common_inf_present, >hdr[i],
>>> +
>>> + decode_hrd(gb, common_inf_present, hdr,
>>> vps->vps_max_sub_layers);
>>> }
>>
>> Why do you allocate the HEVCHdrParams separately when you know
>> vps_num_hrd_parameters before allocating the first one?
>
> You want me to allocate all of them with a single ff_refstruct_allocz()
> and store individual pointers for each?
>
No, I want you to allocate them jointly and access them via "const
HEVCHdrParams *src = >hdr[i]".
(Removing the individual pointers is precisely the point.)
Furthermore, there is no reason to allocate it via RefStruct. A simple
av_calloc() is enough (they have one owner: The containing HEVCVPS; that
said HEVCVPS can have multiple owners doesn't change this).
>>
>>> }
>>> diff --git a/libavcodec/hevc_ps.h b/libavcodec/hevc_ps.h
>>> index 9cdec9b6c1..ff94f90a5e 100644
>>> --- a/libavcodec/hevc_ps.h
>>> +++ b/libavcodec/hevc_ps.h
>>> @@ -150,7 +150,7 @@ typedef struct PTL {
>>> typedef struct HEVCVPS {
>>> unsigned int vps_id;
>>> - HEVCHdrParams hdr[HEVC_MAX_LAYER_SETS];
>>> + HEVCHdrParams *hdr[HEVC_MAX_LAYER_SETS];
>>> uint8_t vps_temporal_id_nesting_flag : 1;
>>> uint8_t vps_sub_layer_ordering_info_present_flag : 1;
>>> diff --git a/libavcodec/vulkan_hevc.c b/libavcodec/vulkan_hevc.c
>>> index 239bff75e5..a89d09a372 100644
>>> --- a/libavcodec/vulkan_hevc.c
>>> +++ b/libavcodec/vulkan_hevc.c
>>> @@ -563,7 +563,7 @@ static void set_vps(const HEVCVPS *vps,
>>> HEVCHeaderVPSSet sls[])
>>> {
>>> for (int i = 0; i < vps->vps_num_hrd_parameters; i++) {
>>> - const HEVCHdrParams *src = >hdr[i];
>>> + const HEVCHdrParams *src = vps->hdr[i];
>>> sls_hdr[i] = (StdVideoH265HrdParameters) {
>>> .flags = (StdVideoH265HrdFlags) {
>>
>> ___
>> ffmpeg-devel mailing list
>> ffmpeg-devel@ffmpeg.org
>> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>>
>> To unsubscribe, visit link above, or email
>> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v4 00/13] AFGS1 film grain support
On Mon, 18 Mar 2024 17:54:08 +0100 Niklas Haas wrote: > Changes since v3: > > - Moved metadata into common AVFilmGrainParams struct, as per James > Almer's recommendation > - Fixed width/height field validation > - Signal this metadata for AV1 (instead of setting it to unspecified) > - Implement ffprobe/showinfo support for the new fields Will push this version at the end of the week if there are no objections. ___ 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/4] fftools/ffmpeg_enc: strip DOVI config record for AV1
On Thu, 21 Mar 2024 11:16:57 +0100 Anton Khirnov wrote: > Quoting Niklas Haas (2024-03-19 20:16:39) > > From: Niklas Haas > > > > AV1 streams don't use configuration records, so delete them when > > encoding to AV1. Ideally this would be, as the comment suggests, handled > > at the frame-level (and stripped by the av1 encoder), but given the > > status quo of copying the packet-level data here directly, we should > > definitely make an effort to strip it. > > --- > > fftools/ffmpeg_enc.c | 25 ++--- > > 1 file changed, 14 insertions(+), 11 deletions(-) > > I'm very much not a fan of having codec-specific code in ffmpeg CLI. It > implies that every single caller must now be aware of this > (undocumented?) interaction of this specific side data with this > specific codec ID. Note: This is an existing bug, not introduced by this series. This series just makes it obvious. The status quo is that, beacuse of this logic in ffmpeg_enc.c, we incorrectly forward dolby vision configuration records when transcoding to AV1. Or, indeed, when transcoding to *any* format - since current FFmpeg also does not propagate dolby vision RPUs, we generate broken files pretty much always when transcoding dolby vision. So we definitely need to strip the metadata from the stream muxer *somewhere*. Where else comes to mind? This also gets into another topic I wanted to touch on, which is that the presence of dynamic dolby vision metadata currently hinders the ability of libavfilter to treat the video primaries/gamma as a negotiable colorspace property (the way it is done currently for YUV matrix/range). This is because when interpreted as such, DV metadata fundamentally changes the colorspace of the incoming video stream. Ideally we would like some way to negotiate DV metadata on the query_formats() level. Ideally, we'd want something like AVCOL_SPC_DOLBYVISION, but we can't easily introduce that without breaking ISO/IEC 23091 compatibility.. --- P.s. I accidentally sent a duplicate of this email from a different (wrong) mail address, please ignore. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avcodec/hevc_ps: allocate only the required HEVCHdrParams within a VPS
On 3/21/2024 8:15 AM, Andreas Rheinhardt wrote:
James Almer:
Signed-off-by: James Almer
---
libavcodec/hevc_ps.c | 17 +++--
libavcodec/hevc_ps.h | 2 +-
libavcodec/vulkan_hevc.c | 2 +-
3 files changed, 17 insertions(+), 4 deletions(-)
diff --git a/libavcodec/hevc_ps.c b/libavcodec/hevc_ps.c
index 20ceb09829..d3edc0810d 100644
--- a/libavcodec/hevc_ps.c
+++ b/libavcodec/hevc_ps.c
@@ -442,13 +442,21 @@ static int decode_hrd(GetBitContext *gb, int
common_inf_present,
return 0;
}
+static void uninit_vps(FFRefStructOpaque opaque, void *obj)
+{
+HEVCVPS *vps = obj;
+
+for (int i = 0; i < vps->vps_num_hrd_parameters; i++)
+ff_refstruct_unref(>hdr[i]);
+}
+
int ff_hevc_decode_nal_vps(GetBitContext *gb, AVCodecContext *avctx,
HEVCParamSets *ps)
{
int i,j;
int vps_id = 0;
ptrdiff_t nal_size;
-HEVCVPS *vps = ff_refstruct_allocz(sizeof(*vps));
+HEVCVPS *vps = ff_refstruct_alloc_ext(sizeof(*vps), 0, NULL, uninit_vps);
if (!vps)
return AVERROR(ENOMEM);
@@ -538,12 +546,17 @@ int ff_hevc_decode_nal_vps(GetBitContext *gb,
AVCodecContext *avctx,
goto err;
}
for (i = 0; i < vps->vps_num_hrd_parameters; i++) {
+HEVCHdrParams *hdr = ff_refstruct_allocz(sizeof(*hdr));
int common_inf_present = 1;
+if (!hdr)
+return AVERROR(ENOMEM);
+
get_ue_golomb_long(gb); // hrd_layer_set_idx
if (i)
common_inf_present = get_bits1(gb);
-decode_hrd(gb, common_inf_present, >hdr[i],
+
+decode_hrd(gb, common_inf_present, hdr,
vps->vps_max_sub_layers);
}
Why do you allocate the HEVCHdrParams separately when you know
vps_num_hrd_parameters before allocating the first one?
You want me to allocate all of them with a single ff_refstruct_allocz()
and store individual pointers for each?
}
diff --git a/libavcodec/hevc_ps.h b/libavcodec/hevc_ps.h
index 9cdec9b6c1..ff94f90a5e 100644
--- a/libavcodec/hevc_ps.h
+++ b/libavcodec/hevc_ps.h
@@ -150,7 +150,7 @@ typedef struct PTL {
typedef struct HEVCVPS {
unsigned int vps_id;
-HEVCHdrParams hdr[HEVC_MAX_LAYER_SETS];
+HEVCHdrParams *hdr[HEVC_MAX_LAYER_SETS];
uint8_t vps_temporal_id_nesting_flag : 1;
uint8_t vps_sub_layer_ordering_info_present_flag : 1;
diff --git a/libavcodec/vulkan_hevc.c b/libavcodec/vulkan_hevc.c
index 239bff75e5..a89d09a372 100644
--- a/libavcodec/vulkan_hevc.c
+++ b/libavcodec/vulkan_hevc.c
@@ -563,7 +563,7 @@ static void set_vps(const HEVCVPS *vps,
HEVCHeaderVPSSet sls[])
{
for (int i = 0; i < vps->vps_num_hrd_parameters; i++) {
-const HEVCHdrParams *src = >hdr[i];
+const HEVCHdrParams *src = vps->hdr[i];
sls_hdr[i] = (StdVideoH265HrdParameters) {
.flags = (StdVideoH265HrdFlags) {
___
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 4/4] avcodec/libx265: encode dovi RPUs
On Tue, 19 Mar 2024 19:19:29 -0400 Vittorio Giovara wrote: > On Tue, Mar 19, 2024 at 7:04 PM Niklas Haas wrote: > > > On Tue, 19 Mar 2024 21:59:53 + Cosmin Stejerean via ffmpeg-devel < > > ffmpeg-devel@ffmpeg.org> wrote: > > > > > > > > > > On Mar 19, 2024, at 2:39 PM, Derek Buitenhuis < > > derek.buitenh...@gmail.com> wrote: > > > > > > > > The reason I never implemented this back when I adde RPU side data is > > that > > > > there is a strong chance of generating broken files. > > > > > > > > That's because if we do anything to the video with swscale, etc., we're > > > > now encoding RPUs that aren't meant to be applied to that converted > > video. > > > > > > > > For example, this could end up propagating RPUs when the user is > > tonemapping. > > > > > > Would it be possible to only propagate RPUs if the color params are not > > changing? If there's any change from say PQ to HLG or HLG to PQ or > > tonemapping then we wouldn't want to propagate RPUs. If the color params > > are not changing then propagating RPUs by default seems sensible, and > > perhaps a filter can be added to explicitly clear RPUs if they should not > > be propagated. > > > > One way to accomplish this would be to simply strip the metadata in all > > filters > > that can change the colorspace. Maybe we should do the same for HDR+ etc. > > metadata. > > > > Probably it would make sense to add a common helper function for this. > > I'll see > > what I can do. > > > > In the meantime maybe just adding an encoder option to preserve existing > metadata would help? Adding a flag to the encoder to control whether to write dolby vision RPUs (defaulting to off) seems like a good idea. At some level, we fundamentally have to rely on the user to tell us whether dolby vision metadata is still valid after filtering. There is still the separate concern of how to control whether or not a dovi *configuration* record should be emitted when muxing, which should be done on a remux but should not be done on a decode or when stripping DV metadata. That said, including a dolby configuration record but without corresponding RPUs at the very least appears to be harmless, though I have not verified with actual hardware. ___ 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/4] avcodec/libx265: encode dovi RPUs
On Wed, 20 Mar 2024 23:22:03 +0200 Jan Ekström wrote:
> On Wed, Mar 20, 2024 at 9:30 PM Michael Niedermayer
> wrote:
> >
> > On Tue, Mar 19, 2024 at 08:16:42PM +0100, Niklas Haas wrote:
> > > From: Niklas Haas
> > >
> > > libx265 supports these natively, we just need to forward them to the
> > > x265picture.
> > > ---
> > > libavcodec/libx265.c | 11 +++
> > > 1 file changed, 11 insertions(+)
> >
> > breaks build here
> >
> > CC libavcodec/libx265.o
> > libavcodec/libx265.c: In function ‘free_picture’:
> > libavcodec/libx265.c:563:16: error: ‘x265_picture {aka struct
> > x265_picture}’ has no member named ‘rpu’
> > av_free(pic->rpu.payload);
> > ^~
> > libavcodec/libx265.c: In function ‘libx265_encode_frame’:
> > libavcodec/libx265.c:701:20: error: ‘x265_picture {aka struct
> > x265_picture}’ has no member named ‘rpu’
> > x265pic.rpu.payload = av_memdup(sd->data, sd->size);
> > ^
> > libavcodec/libx265.c:702:25: error: ‘x265_picture {aka struct
> > x265_picture}’ has no member named ‘rpu’
> > if (!x265pic.rpu.payload) {
> > ^
> > libavcodec/libx265.c:706:20: error: ‘x265_picture {aka struct
> > x265_picture}’ has no member named ‘rpu’
> > x265pic.rpu.payloadSize = sd->size;
> > ^
> > ffbuild/common.mak:81: recipe for target 'libavcodec/libx265.o' failed
> > make: *** [libavcodec/libx265.o] Error 1
> >
>
> The RPU structure and its location in x265_picture was added in
> 5a7d027d82821a8b4d9c768d6b8fb0560557e2bd , bumping X265_BUILD to 167
> (2018-09-27) .
>
> Configure check is currently for 89, and we already check in the
> wrapper for 130 and 159. So possibly it makes sense to just bump the
> requirement to a version from 2018? Otherwise just another #if
> X265_BUILD >= 167 ?
Added an X265_BUILD >= 167 check.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avcodec/hevc_ps: allocate only the required HEVCHdrParams within a VPS
James Almer:
> Signed-off-by: James Almer
> ---
> libavcodec/hevc_ps.c | 17 +++--
> libavcodec/hevc_ps.h | 2 +-
> libavcodec/vulkan_hevc.c | 2 +-
> 3 files changed, 17 insertions(+), 4 deletions(-)
>
> diff --git a/libavcodec/hevc_ps.c b/libavcodec/hevc_ps.c
> index 20ceb09829..d3edc0810d 100644
> --- a/libavcodec/hevc_ps.c
> +++ b/libavcodec/hevc_ps.c
> @@ -442,13 +442,21 @@ static int decode_hrd(GetBitContext *gb, int
> common_inf_present,
> return 0;
> }
>
> +static void uninit_vps(FFRefStructOpaque opaque, void *obj)
> +{
> +HEVCVPS *vps = obj;
> +
> +for (int i = 0; i < vps->vps_num_hrd_parameters; i++)
> +ff_refstruct_unref(>hdr[i]);
> +}
> +
> int ff_hevc_decode_nal_vps(GetBitContext *gb, AVCodecContext *avctx,
> HEVCParamSets *ps)
> {
> int i,j;
> int vps_id = 0;
> ptrdiff_t nal_size;
> -HEVCVPS *vps = ff_refstruct_allocz(sizeof(*vps));
> +HEVCVPS *vps = ff_refstruct_alloc_ext(sizeof(*vps), 0, NULL, uninit_vps);
>
> if (!vps)
> return AVERROR(ENOMEM);
> @@ -538,12 +546,17 @@ int ff_hevc_decode_nal_vps(GetBitContext *gb,
> AVCodecContext *avctx,
> goto err;
> }
> for (i = 0; i < vps->vps_num_hrd_parameters; i++) {
> +HEVCHdrParams *hdr = ff_refstruct_allocz(sizeof(*hdr));
> int common_inf_present = 1;
>
> +if (!hdr)
> +return AVERROR(ENOMEM);
> +
> get_ue_golomb_long(gb); // hrd_layer_set_idx
> if (i)
> common_inf_present = get_bits1(gb);
> -decode_hrd(gb, common_inf_present, >hdr[i],
> +
> +decode_hrd(gb, common_inf_present, hdr,
> vps->vps_max_sub_layers);
> }
Why do you allocate the HEVCHdrParams separately when you know
vps_num_hrd_parameters before allocating the first one?
> }
> diff --git a/libavcodec/hevc_ps.h b/libavcodec/hevc_ps.h
> index 9cdec9b6c1..ff94f90a5e 100644
> --- a/libavcodec/hevc_ps.h
> +++ b/libavcodec/hevc_ps.h
> @@ -150,7 +150,7 @@ typedef struct PTL {
>
> typedef struct HEVCVPS {
> unsigned int vps_id;
> -HEVCHdrParams hdr[HEVC_MAX_LAYER_SETS];
> +HEVCHdrParams *hdr[HEVC_MAX_LAYER_SETS];
>
> uint8_t vps_temporal_id_nesting_flag : 1;
> uint8_t vps_sub_layer_ordering_info_present_flag : 1;
> diff --git a/libavcodec/vulkan_hevc.c b/libavcodec/vulkan_hevc.c
> index 239bff75e5..a89d09a372 100644
> --- a/libavcodec/vulkan_hevc.c
> +++ b/libavcodec/vulkan_hevc.c
> @@ -563,7 +563,7 @@ static void set_vps(const HEVCVPS *vps,
> HEVCHeaderVPSSet sls[])
> {
> for (int i = 0; i < vps->vps_num_hrd_parameters; i++) {
> -const HEVCHdrParams *src = >hdr[i];
> +const HEVCHdrParams *src = vps->hdr[i];
>
> sls_hdr[i] = (StdVideoH265HrdParameters) {
> .flags = (StdVideoH265HrdFlags) {
___
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] avformat/riffdec: follow the MS docs more strictly for setting wav channel layouts
On 21/03/2024 10:40, Marton Balint wrote: On Thu, 21 Mar 2024, Tobias Rapp wrote: On 19/03/2024 20:14, Marton Balint wrote: On Tue, 19 Mar 2024, Michael Niedermayer wrote: On Sun, Mar 17, 2024 at 08:57:29PM +0100, Marton Balint wrote: - Only parse the defined masks in dwChannelMask, unless strict_std_compliance is less than normal. This matches with the behaviour of the wav muxer. - Ignore additional bits in dwChannelMasks as the MS documentation suggests [1] - Assume UNKNOWN channels for missing bits as the MS documentation suggests [1] [1] https://learn.microsoft.com/en-us/previous-versions/windows/hardware/design/dn653308(v=vs.85)#details-about-dwchannelmask Signed-off-by: Marton Balint --- libavformat/riffdec.c | 28 +--- 1 file changed, 25 insertions(+), 3 deletions(-) breaks: ./ffmpeg -i ~/tickets/2859/5.1plusdownmix.wav -ac 2 -t 100 -bitexact -c:a aac -y /tmp/2859-frenchspeack-nolibfaac.mp4 After the patch this is file will need -strict unofficial to work, since the downmix channels are not officially recognized in the dwChannelMask. I think downmix channels are part of the RF64 specification, see EBU Tech 3306 section 3.1: """ 3.1 Enhancement for a PCM stereo down mix No PCM stereo signal is included in the basic Wave Format Extensible. To include a stereo channel the following is added: #define SPEAKER_STEREO_LEFT 0x2000 #define SPEAKER_STEREO_RIGHT 0x4000 """ I was reluctant to add these, because the recommendation which superseded this, ITU BS.2088 does not mention these masks. Nevertheless, you are right, these should be recognized to support historical RF64 files. Or we should not even make the distinction of RF64? WAV files smaller than 2/4GiB could start with the usual "RIFF" bytes but still contain these mask bits. From a quick glance at ITU BS.2088 it seems it could use the "chna" chunk to achieve a mapping like "5.1 + downmix". Having said that, I have not stumbled over "X plus downmix" WAVE files in production yet. So no strong opinion from my side on whether this should work without "-strict unofficial", or not. Regards, Tobias ___ 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] [FFmpeg-cvslog] fftools/ffmpeg: add loopback decoding
Quoting Gyan Doshi (2024-03-15 05:12:41) > > > On 2024-03-14 03:46 pm, Anton Khirnov wrote: > > Quoting Gyan Doshi (2024-03-13 08:49:52) > > > >> Are there any limitations to loopback decoding e.g. would a vpx w/alpha > >> encode be decoded back to a alpha pix fmt? > > I don't know how vpx alpha works, was it a separate stream in the > > demuxer or something like that? > > The encoder attaches the coded alpha as side data to the packet. Only a > couple of containers support this SD. > The demuxer, in turn, attaches the alpha as SD upon export. The packets arrive at the decoder exactly as the encoder produced them, so if that's enough then it should work. > > Loopback decoders work exactly like normal decoders, except their > > packets arrive from an encoder instead of a demuxer. > In terms of syntax, do all LB streams have to be specified in the first > output? Actually they are not a part of the output, they form their own parsing unit equivalent to -i/output. Probably this could be documented better. > Does that output muxer have to be null, or can those packets be > routed to both output and LB? The muxer can be anything, it does not know anything about loopback decoders. The only limitation in this regard is that it is not (currently) possible to avoid muxing entirely. -- Anton Khirnov ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 1/4] fftools/ffmpeg_enc: strip DOVI config record for AV1
Quoting Niklas Haas (2024-03-19 20:16:39) > From: Niklas Haas > > AV1 streams don't use configuration records, so delete them when > encoding to AV1. Ideally this would be, as the comment suggests, handled > at the frame-level (and stripped by the av1 encoder), but given the > status quo of copying the packet-level data here directly, we should > definitely make an effort to strip it. > --- > fftools/ffmpeg_enc.c | 25 ++--- > 1 file changed, 14 insertions(+), 11 deletions(-) I'm very much not a fan of having codec-specific code in ffmpeg CLI. It implies that every single caller must now be aware of this (undocumented?) interaction of this specific side data with this specific codec ID. -- Anton Khirnov ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] V2 tests/fate/filter-audio.mak: add test for ATEMPO audio filter
Please find an updated patch for tests on the atempo audio filter From 30475d6f076d5236ee534002fffb01958ef0dfc1 Mon Sep 17 00:00:00 2001 From: Rajiv Harlalka Date: Thu, 21 Mar 2024 13:35:29 +0530 Subject: [PATCH v2] tests/fate/filter-audio.mak: add test for ATEMPO audio filter Signed-off-by: Rajiv Harlalka --- tests/fate/filter-audio.mak | 3 ++ tests/ref/fate/filter-atempo | 70 2 files changed, 73 insertions(+) create mode 100644 tests/ref/fate/filter-atempo diff --git a/tests/fate/filter-audio.mak b/tests/fate/filter-audio.mak index 308969c4ac..469c784e87 100644 --- a/tests/fate/filter-audio.mak +++ b/tests/fate/filter-audio.mak @@ -414,6 +414,9 @@ fate-filter-hdcd-s32p: CMD = md5 -i $(SRC) -af hdcd -f s32le fate-filter-hdcd-s32p: CMP = oneline fate-filter-hdcd-s32p: REF = 0c5513e83eedaa10ab6fac9ddc173cf5 +FATE_AFILTER_SAMPLES-$(call FILTERDEMDECENCMUX, ATEMPO, WAV, PCM_S16LE, PCM_S16LE, WAV) += fate-filter-atempo +fate-filter-atempo: CMD = framecrc -i $(TARGET_PATH)/tests/data/asynth-44100-1.wav -af "atempo=2.0" -ar 44100 + FATE_AFILTER-yes += fate-filter-formats fate-filter-formats: libavfilter/tests/formats$(EXESUF) fate-filter-formats: CMD = run libavfilter/tests/formats$(EXESUF) diff --git a/tests/ref/fate/filter-atempo b/tests/ref/fate/filter-atempo new file mode 100644 index 00..abedfcd618 --- /dev/null +++ b/tests/ref/fate/filter-atempo @@ -0,0 +1,70 @@ +#tb 0: 1/44100 +#media_type 0: audio +#codec_id 0: pcm_s16le +#sample_rate 0: 44100 +#channel_layout_name 0: mono +0, 0, 0, 2048, 4096, 0x9c4dffa9 +0, 2048, 2048, 2048, 4096, 0x3a11f3f6 +0, 4096, 4096, 2048, 4096, 0x9835f5a5 +0, 6144, 6144, 2048, 4096, 0x7fe7e8ab +0, 8192, 8192, 2048, 4096, 0x9450f26b +0, 10240, 10240, 2048, 4096, 0x8f95ff6a +0, 12288, 12288, 2048, 4096, 0xc9deebab +0, 14336, 14336, 2048, 4096, 0x0229ec6c +0, 16384, 16384, 2048, 4096, 0xb1b00a8c +0, 18432, 18432, 2048, 4096, 0x43e7f197 +0, 20480, 20480, 2048, 4096, 0x60580ec1 +0, 22528, 22528, 2048, 4096, 0x1a4f084c +0, 24576, 24576, 2048, 4096, 0x70d20213 +0, 26624, 26624, 2048, 4096, 0xaf9afc70 +0, 28672, 28672, 2048, 4096, 0x1212df6f +0, 30720, 30720, 2048, 4096, 0x37a8f35a +0, 32768, 32768, 2048, 4096, 0x4730f0ee +0, 34816, 34816, 2048, 4096, 0x1fe1efd8 +0, 36864, 36864, 2048, 4096, 0xdfc4149e +0, 38912, 38912, 2048, 4096, 0xe288ffd1 +0, 40960, 40960, 2048, 4096, 0xee7b0829 +0, 43008, 43008, 2048, 4096, 0xb20df4aa +0, 45056, 45056, 2048, 4096, 0x0564f254 +0, 47104, 47104, 2048, 4096, 0x92daf362 +0, 49152, 49152, 2048, 4096, 0xaab3f18b +0, 51200, 51200, 2048, 4096, 0xe2bdfcb4 +0, 53248, 53248, 2048, 4096, 0x706adab4 +0, 55296, 55296, 2048, 4096, 0x141a075b +0, 57344, 57344, 2048, 4096, 0x87aad71f +0, 59392, 59392, 2048, 4096, 0xfafd0233 +0, 61440, 61440, 2048, 4096, 0x74b1cb64 +0, 63488, 63488, 2048, 4096, 0x9ffee659 +0, 65536, 65536, 2048, 4096, 0x50dde96c +0, 67584, 67584, 2048, 4096, 0xa4f5fc36 +0, 69632, 69632, 2048, 4096, 0xd40ff139 +0, 71680, 71680, 2048, 4096, 0xe93fe12a +0, 73728, 73728, 2048, 4096, 0x747f05da +0, 75776, 75776, 2048, 4096, 0x902601d7 +0, 77824, 77824, 2048, 4096, 0xee871089 +0, 79872, 79872, 2048, 4096, 0x8fba09ee +0, 81920, 81920, 2048, 4096, 0x832afdea +0, 83968, 83968, 2048, 4096, 0x7224ec15 +0, 86016, 86016, 2048, 4096, 0xf7def9f4 +0, 88064, 88064, 2048, 4096, 0x3c8af149 +0, 90112, 90112, 2048, 4096, 0x1dc1dfcf +0, 92160, 92160, 2048, 4096, 0x8ef51140 +0, 94208, 94208, 2048, 4096, 0x4b200588 +0, 96256, 96256, 2048, 4096, 0x29e9be20 +0, 98304, 98304, 2048, 4096, 0x8298f08a +0, 100352, 100352, 2048, 4096, 0xae5ef3b3 +0, 102400, 102400, 2048, 4096, 0xa76cfbe3 +0, 104448, 104448, 2048, 4096, 0xf784fdb0 +0, 106496, 106496, 2048, 4096, 0xea70f93e +0, 108544, 108544, 2048, 4096, 0xea5ffc00 +0, 110592, 110592, 2048, 4096, 0x6c2f0350 +0, 112640, 112640, 2048, 4096, 0x5f94cf81 +0, 114688, 114688, 2048, 4096, 0x2f28fda2 +0, 116736, 116736, 2048, 4096, 0x3db0fc68 +0,
Re: [FFmpeg-devel] [PATCH 2/2] avformat/riffdec: follow the MS docs more strictly for setting wav channel layouts
On Thu, 21 Mar 2024, Tobias Rapp wrote: On 19/03/2024 20:14, Marton Balint wrote: On Tue, 19 Mar 2024, Michael Niedermayer wrote: On Sun, Mar 17, 2024 at 08:57:29PM +0100, Marton Balint wrote: - Only parse the defined masks in dwChannelMask, unless strict_std_compliance is less than normal. This matches with the behaviour of the wav muxer. - Ignore additional bits in dwChannelMasks as the MS documentation suggests [1] - Assume UNKNOWN channels for missing bits as the MS documentation suggests [1] [1] https://learn.microsoft.com/en-us/previous-versions/windows/hardware/design/dn653308(v=vs.85)#details-about-dwchannelmask Signed-off-by: Marton Balint --- libavformat/riffdec.c | 28 +--- 1 file changed, 25 insertions(+), 3 deletions(-) breaks: ./ffmpeg -i ~/tickets/2859/5.1plusdownmix.wav -ac 2 -t 100 -bitexact -c:a aac -y /tmp/2859-frenchspeack-nolibfaac.mp4 After the patch this is file will need -strict unofficial to work, since the downmix channels are not officially recognized in the dwChannelMask. I think downmix channels are part of the RF64 specification, see EBU Tech 3306 section 3.1: """ 3.1 Enhancement for a PCM stereo down mix No PCM stereo signal is included in the basic Wave Format Extensible. To include a stereo channel the following is added: #define SPEAKER_STEREO_LEFT 0x2000 #define SPEAKER_STEREO_RIGHT 0x4000 """ I was reluctant to add these, because the recommendation which superseded this, ITU BS.2088 does not mention these masks. Nevertheless, you are right, these should be recognized to support historical RF64 files. Or we should not even make the distinction of RF64? Regards, Marton ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 2/2] avformat/riffdec: follow the MS docs more strictly for setting wav channel layouts
On 19/03/2024 20:14, Marton Balint wrote: On Tue, 19 Mar 2024, Michael Niedermayer wrote: On Sun, Mar 17, 2024 at 08:57:29PM +0100, Marton Balint wrote: - Only parse the defined masks in dwChannelMask, unless strict_std_compliance is less than normal. This matches with the behaviour of the wav muxer. - Ignore additional bits in dwChannelMasks as the MS documentation suggests [1] - Assume UNKNOWN channels for missing bits as the MS documentation suggests [1] [1] https://learn.microsoft.com/en-us/previous-versions/windows/hardware/design/dn653308(v=vs.85)#details-about-dwchannelmask Signed-off-by: Marton Balint --- libavformat/riffdec.c | 28 +--- 1 file changed, 25 insertions(+), 3 deletions(-) breaks: ./ffmpeg -i ~/tickets/2859/5.1plusdownmix.wav -ac 2 -t 100 -bitexact -c:a aac -y /tmp/2859-frenchspeack-nolibfaac.mp4 After the patch this is file will need -strict unofficial to work, since the downmix channels are not officially recognized in the dwChannelMask. I think downmix channels are part of the RF64 specification, see EBU Tech 3306 section 3.1: """ 3.1 Enhancement for a PCM stereo down mix No PCM stereo signal is included in the basic Wave Format Extensible. To include a stereo channel the following is added: #define SPEAKER_STEREO_LEFT 0x2000 #define SPEAKER_STEREO_RIGHT 0x4000 """ Regards, Tobias ___ 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: enable UDP IPv6 multicast interface selection
Le 20 mars 2024 14:35:28 GMT+02:00, "Ignjatović, Lazar (RS)" a écrit : > Specifying egress interface is done by setting the > setsockopt(IPV6_MULTICAST_IF) to the value of the interface, not address. On > the other hand v4 for the similar option setsockopt(IP_MULTICAST_IF) sets it > by definig an address (not interface). Without setting IPV6_MULTICAST_IF to > the appropriate interface, default interface is chosen. We want to have > control over this, and I cant se how this can be achieved without knowing the > interface id. >For ingress IPv6 traffic, the way to filter on which interface is being >listened on is by binding to a mcast addres, which has sin6_scope_id properly >set. Your MR makes even less sense for multicast. For multicast there is no local address to match to an interface. So you just have to have the interface specified explicitly in addition to the LL group address. This is true for both egress and ingress. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] doc: Add libtoch backend option to dnn_processing
From: Wenbin Chen
Signed-off-by: Wenbin Chen
---
doc/filters.texi | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/doc/filters.texi b/doc/filters.texi
index 913365671d..20605e72b2 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -12069,11 +12069,21 @@ need to build and install the OpenVINO for C library
(see
@code{--enable-libopenvino} (--extra-cflags=-I... --extra-ldflags=-L... might
be needed if the header files and libraries are not installed into system path)
+@item torch
+Libtorch backend. To enable this backend you need to build and install Libtroch
+for C++ library. Please download cxx11 ABI version (see
+@url{https://pytorch.org/get-started/locally})
+and configure FFmpeg with @code{--enable-libtorch
+--extra-cflag=-I/libtorch_root/libtorch/include
+--extra-cflag=-I/libtorch_root/libtorch/include/torch/csrc/api/include
+--extra-ldflags=-L/libtorch_root/libtorch/lib/}
+
@end table
@item model
Set path to model file specifying network architecture and its parameters.
-Note that different backends use different file formats. TensorFlow, OpenVINO
backend can load files for only its format.
+Note that different backends use different file formats. TensorFlow, OpenVINO
+and Libtorch backend can load files for only its format.
@item input
Set the input name of the dnn network.
--
2.34.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] tests/fate/filter-audio.mak: add test for ATEMPO audio filter
Signed-off-by: Rajiv Harlalka --- tests/fate/filter-audio.mak | 3 ++ tests/ref/fate/filter-atempo | 70 2 files changed, 73 insertions(+) create mode 100644 tests/ref/fate/filter-atempo diff --git a/tests/fate/filter-audio.mak b/tests/fate/filter-audio.mak index 308969c4ac..469c784e87 100644 --- a/tests/fate/filter-audio.mak +++ b/tests/fate/filter-audio.mak @@ -414,6 +414,9 @@ fate-filter-hdcd-s32p: CMD = md5 -i $(SRC) -af hdcd -f s32le fate-filter-hdcd-s32p: CMP = oneline fate-filter-hdcd-s32p: REF = 0c5513e83eedaa10ab6fac9ddc173cf5 +FATE_AFILTER_SAMPLES-$(call FILTERDEMDECENCMUX, ATEMPO, WAV, PCM_S16LE, PCM_S16LE, WAV) += fate-filter-atempo +fate-filter-atempo: CMD = framecrc -i $(TARGET_PATH)/tests/data/asynth-44100-1.wav -af "atempo=2.0" -ar 44100 + FATE_AFILTER-yes += fate-filter-formats fate-filter-formats: libavfilter/tests/formats$(EXESUF) fate-filter-formats: CMD = run libavfilter/tests/formats$(EXESUF) diff --git a/tests/ref/fate/filter-atempo b/tests/ref/fate/filter-atempo new file mode 100644 index 00..abedfcd618 --- /dev/null +++ b/tests/ref/fate/filter-atempo @@ -0,0 +1,70 @@ +#tb 0: 1/44100 +#media_type 0: audio +#codec_id 0: pcm_s16le +#sample_rate 0: 44100 +#channel_layout_name 0: mono +0, 0, 0, 2048, 4096, 0x9c4dffa9 +0, 2048, 2048, 2048, 4096, 0x3a11f3f6 +0, 4096, 4096, 2048, 4096, 0x9835f5a5 +0, 6144, 6144, 2048, 4096, 0x7fe7e8ab +0, 8192, 8192, 2048, 4096, 0x9450f26b +0, 10240, 10240, 2048, 4096, 0x8f95ff6a +0, 12288, 12288, 2048, 4096, 0xc9deebab +0, 14336, 14336, 2048, 4096, 0x0229ec6c +0, 16384, 16384, 2048, 4096, 0xb1b00a8c +0, 18432, 18432, 2048, 4096, 0x43e7f197 +0, 20480, 20480, 2048, 4096, 0x60580ec1 +0, 22528, 22528, 2048, 4096, 0x1a4f084c +0, 24576, 24576, 2048, 4096, 0x70d20213 +0, 26624, 26624, 2048, 4096, 0xaf9afc70 +0, 28672, 28672, 2048, 4096, 0x1212df6f +0, 30720, 30720, 2048, 4096, 0x37a8f35a +0, 32768, 32768, 2048, 4096, 0x4730f0ee +0, 34816, 34816, 2048, 4096, 0x1fe1efd8 +0, 36864, 36864, 2048, 4096, 0xdfc4149e +0, 38912, 38912, 2048, 4096, 0xe288ffd1 +0, 40960, 40960, 2048, 4096, 0xee7b0829 +0, 43008, 43008, 2048, 4096, 0xb20df4aa +0, 45056, 45056, 2048, 4096, 0x0564f254 +0, 47104, 47104, 2048, 4096, 0x92daf362 +0, 49152, 49152, 2048, 4096, 0xaab3f18b +0, 51200, 51200, 2048, 4096, 0xe2bdfcb4 +0, 53248, 53248, 2048, 4096, 0x706adab4 +0, 55296, 55296, 2048, 4096, 0x141a075b +0, 57344, 57344, 2048, 4096, 0x87aad71f +0, 59392, 59392, 2048, 4096, 0xfafd0233 +0, 61440, 61440, 2048, 4096, 0x74b1cb64 +0, 63488, 63488, 2048, 4096, 0x9ffee659 +0, 65536, 65536, 2048, 4096, 0x50dde96c +0, 67584, 67584, 2048, 4096, 0xa4f5fc36 +0, 69632, 69632, 2048, 4096, 0xd40ff139 +0, 71680, 71680, 2048, 4096, 0xe93fe12a +0, 73728, 73728, 2048, 4096, 0x747f05da +0, 75776, 75776, 2048, 4096, 0x902601d7 +0, 77824, 77824, 2048, 4096, 0xee871089 +0, 79872, 79872, 2048, 4096, 0x8fba09ee +0, 81920, 81920, 2048, 4096, 0x832afdea +0, 83968, 83968, 2048, 4096, 0x7224ec15 +0, 86016, 86016, 2048, 4096, 0xf7def9f4 +0, 88064, 88064, 2048, 4096, 0x3c8af149 +0, 90112, 90112, 2048, 4096, 0x1dc1dfcf +0, 92160, 92160, 2048, 4096, 0x8ef51140 +0, 94208, 94208, 2048, 4096, 0x4b200588 +0, 96256, 96256, 2048, 4096, 0x29e9be20 +0, 98304, 98304, 2048, 4096, 0x8298f08a +0, 100352, 100352, 2048, 4096, 0xae5ef3b3 +0, 102400, 102400, 2048, 4096, 0xa76cfbe3 +0, 104448, 104448, 2048, 4096, 0xf784fdb0 +0, 106496, 106496, 2048, 4096, 0xea70f93e +0, 108544, 108544, 2048, 4096, 0xea5ffc00 +0, 110592, 110592, 2048, 4096, 0x6c2f0350 +0, 112640, 112640, 2048, 4096, 0x5f94cf81 +0, 114688, 114688, 2048, 4096, 0x2f28fda2 +0, 116736, 116736, 2048, 4096, 0x3db0fc68 +0, 118784, 118784, 2048, 4096, 0x15bc0c1f +0, 120832, 120832, 2048, 4096, 0x48840656 +0, 122880, 122880, 2048, 4096, 0xdf70ee6e +0, 124928, 124928, 2048, 4096, 0x2dece83a +0, 126976, 126976, 2048, 4096,
