date:20240320

avformat: enable UDP IPv6 multicast interface selection

localaddr option now properly works with IPv6 addresses. Properly
resolved interface index in places where default 0 interface index is
used (marked with TODO: within udp.c). Adjusted binding for multicast
sockets that are used for reading from the network. Need for this
arises from the fact that [ffx1::*] and [ffx2::*] mcast addresses need
to have a defined interface for binding to avoid ambiguity between
multiple link-local networks on the same host. Failing to set this
option causes errors on Linux systems for interface and link-local
scopes.

For mcast addresses, bind to mcast address is attempted as before.
In case that this fails, which will happen on Windows, socket is bound
to INADDR_ANY/IN6ADDR_ANY_INIT depending on address family. Actual
interface selection is performed using udp_set_multicast_interface to
point to the desired interface for sending.

Utilization of sin6_scope_id field enables usage and adequate resolving
of localaddr IPv6 addresses that utilize zone index
(e.g. fe80::1ff:fe23:4567:890a%eth2)
This is not fully supported on Windows, thus relying on this field
is not done on Windows systems.

Closes: #368

Signed-off-by: Lazar Ignjatovic 
---
V1 -> V2: SO_BINDTODEVICE -> sin6_scope_id, addressed comments

 configure |  3 ++
 libavformat/ip.c  | 49 ++
 libavformat/ip.h  |  6 
 libavformat/network.h |  6 
 libavformat/udp.c | 81 ++-
 5 files changed, 137 insertions(+), 8 deletions(-)

diff --git a/configure b/configure
index e019d1b996..08f35bbd25 100755
--- a/configure
+++ b/configure
@@ -2258,6 +2258,7 @@ HEADERS_LIST="
 valgrind_valgrind_h
 windows_h
 winsock2_h
+iphlpapi_h
 "

 INTRINSICS_LIST="
@@ -6406,6 +6407,8 @@ if ! disabled network; then
 check_struct winsock2.h "struct sockaddr" sa_len
 check_type ws2tcpip.h "struct sockaddr_in6"
 check_type ws2tcpip.h "struct sockaddr_storage"
+check_headers iphlpapi.h -liphlpapi && 
network_extralibs="$network_extralibs -liphlpapi" || disable iphlpapi_h
+check_func_headers iphlpapi.h GetBestInterfaceEx $network_extralibs
 else
 disable network
 fi
diff --git a/libavformat/ip.c b/libavformat/ip.c
index b2c7ef07e5..4b83e79298 100644
--- a/libavformat/ip.c
+++ b/libavformat/ip.c
@@ -18,6 +18,9 @@
  * 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
  */

+#define _DEFAULT_SOURCE
+#define _SVID_SOURCE
+
 #include 
 #include "ip.h"
 #include "libavutil/avstring.h"
@@ -159,3 +162,49 @@ void ff_ip_reset_filters(IPSourceFilters *filters)
 filters->nb_include_addrs = 0;
 filters->nb_exclude_addrs = 0;
 }
+
+unsigned int ff_ip_resolve_interface_index(struct sockaddr_storage *local_addr)
+{
+#if HAVE_WINSOCK2_H
+#if HAVE_IPHLPAPI_H
+DWORD retval;
+unsigned long iface;
+
+if (local_addr == NULL)
+return 0;
+
+retval = GetBestInterfaceEx((struct sockaddr*)local_addr, &iface);
+if (retval == NO_ERROR)
+return iface;
+#endif /* HAVE_IPHLPAPI_H */
+return 0;
+#else /* HAVE_WINSOCK2_H */
+struct ifaddrs *ifaddr, *ifa;
+unsigned int iface;
+
+if (local_addr == NULL)
+return 0;
+
+#if HAVE_STRUCT_SOCKADDR_IN6 && defined(IN6_IS_ADDR_LINKLOCAL)
+/* Special case for link-local addresses, relevant interface is stored in 
sin6_scope_id */
+if (local_addr->ss_family == AF_INET6) {
+iface = ((struct sockaddr_in6*)local_addr)->sin6_scope_id;
+if (iface != 0)
+return iface;
+}
+#endif /* HAVE_STRUCT_SOCKADDR_IN6 && defined(IN6_IS_ADDR_LINKLOCAL) */
+if (getifaddrs(&ifaddr) == -1)
+return 0;
+
+iface = 0;
+for (ifa = ifaddr; ifa != NULL; ifa = ifa->ifa_next) {
+if (ifa->ifa_addr != NULL && compare_addr((struct 
sockaddr_storage*)ifa->ifa_addr, local_addr) == 0) {
+iface = if_nametoindex(ifa->ifa_name);
+break;
+}
+}
+
+freeifaddrs(ifaddr);
+return iface;
+#endif /* HAVE_WINSOCK2_H */
+}
diff --git a/libavformat/ip.h b/libavformat/ip.h
index b76cdab91c..4085e96f08 100644
--- a/libavformat/ip.h
+++ b/libavformat/ip.h
@@ -69,4 +69,10 @@ int ff_ip_parse_blocks(void *log_ctx, const char *buf, 
IPSourceFilters *filters)
  */
 void ff_ip_reset_filters(IPSourceFilters *filters);

+/**
+ * Resolves IP address to an associated interface index
+ * @return interface index, 0 as default interface value on error
+ */
+unsigned int ff_ip_resolve_interface_index(struct sockaddr_storage 
*local_addr);
+
 #endif /* AVFORMAT_IP_H */
diff --git a/libavformat/network.h b/libavformat/network.h
index ca214087fc..2461b651d4 100644
--- a/libavformat/network.h
+++ b/libavformat/network.h
@@ -38,6 +38,10 @@
 #include 
 #include 

+#if HAVE_IPHLPAPI_H
+#include 
+#endif
+
 #ifndef EPROTONOSUPPORT
 #define EPROTONOSUPPORT WSAEPROTONOSUPPORT
 #endif
@@ -64,6 +68,8 @@ int ff_neterrno(void)

Re: [FFmpeg-devel] [PATCH v2] avformat: enable UDP IPv6 multicast interface selection

2024-03-20 Thread Rémi Denis-Courmont

Same fundamental problem as previous version, AFAICT.

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

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

Re: [FFmpeg-devel] [PATCH v2] avformat: enable UDP IPv6 multicast interface selection

This message has been marked as Public on 03/20/2024 11:09Z.
On Wednesday, March 20, 2024 11:51 AM Rémi Denis-Courmont wrote:

> Same fundamental problem as previous version, AFAICT.
>
> -1

Would you mind being more specific?
There are 2 problems you pointed out, one about SO_BINDTODEVICE, and another in 
respect to casting `sockaddr* ` to `sockaddr_in6*` and `sockaddr_storage*` to 
`sockaddr_in6*`.
Assuming you are reffering to the cast comment, I've addressed this in the 
other thread. That should not be an issue to my knowledge, and is done on 
multiple places throughout the codebase.
Also I've assked you for additional comments, which I'm doing again.

Lazar Ignjatović
Associate Software Engineer

Cubic Defense
cubic.com
___
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

2024-03-20 Thread Tomas Härdin

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.

While we're on the topic, it seems get_qcx() could be more strict when
it comes to the size of JPEG2000_QCD.

I see some TODOs around this stuff as well, init_band_stepsize()

/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 04/13] avformat/codec2: Don't allocate Codec2Context for muxer

2024-03-20 Thread Tomas Härdin

ons 2024-03-20 klockan 03:12 +0100 skrev Andreas Rheinhardt:
> Only the demuxers use it.
> 
> Signed-off-by: Andreas Rheinhardt 
> ---
>  libavformat/codec2.c | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/libavformat/codec2.c b/libavformat/codec2.c
> index 4a3e10c6e3..9ed57af0a8 100644
> --- a/libavformat/codec2.c
> +++ b/libavformat/codec2.c
> @@ -318,7 +318,6 @@ const FFOutputFormat ff_codec2_muxer = {
>  .p.audio_codec  = AV_CODEC_ID_CODEC2,
>  .p.video_codec  = AV_CODEC_ID_NONE,
>  .p.flags    = AVFMT_NOTIMESTAMPS,
> -    .priv_data_size = sizeof(Codec2Context),
>  .write_header   = codec2_write_header,
>  .write_packet   = ff_raw_write_packet,
>  };

Right, mode is carried in extradata. OK.

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

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

Re: [FFmpeg-devel] [PATCH v2] avformat: enable UDP IPv6 multicast interface selection

2024-03-20 Thread Rémi Denis-Courmont

Le 20 mars 2024 13:09:15 GMT+02:00, "Ignjatović, Lazar (RS)" 
 a écrit :
>
>This message has been marked as Public on 03/20/2024 11:09Z.
>On Wednesday, March 20, 2024 11:51 AM Rémi Denis-Courmont wrote:
>
>> Same fundamental problem as previous version, AFAICT.
>>
>> -1
>
>Would you mind being more specific?

You're not supposed to guess the link ID from the local address. This is 
counter-sensical. And it's entirely possible to have the same LL address 
assigned to two interfaces (e.g. using a software bridge) anyway.

Either you know the interface you want to use and you should pass it on 
directly. Or you don't and using link-local doesn't make sense.
___
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

This message has been marked as Public on 03/20/2024 11:45Z.
On Wednesday, March 20, 2024 12:30 PM Rémi Denis-Courmont wrote:

> You're not supposed to guess the link ID from the local address. This is 
> counter-sensical. And it's entirely possible to have the same LL address 
> assigned to two interfaces (e.g. using a software bridge) anyway.

You are right about the same LL on multiple interfaces, that’s why the 
`sin6_scope_id` is used. For specifying LL address, a scoped address format 
should be used to avoid ambiguity. In all other cases, determining the 
interface ID by address should be ok, while keeping the same functionality that 
`localaddr` param has with IPv6. Currently, I don't see any other way of 
specifying IPv6 multicast interface without the introduction of another query 
param like `iface` or something.

Let me know what you think.

Sincirely,
Lazar Ignjatović
Associate Software Engineer

Cubic Defense
cubic.com
___
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

2024-03-20 Thread Rémi Denis-Courmont

Le 20 mars 2024 13:45:10 GMT+02:00, "Ignjatović, Lazar (RS)" 
 a écrit :
>
>This message has been marked as Public on 03/20/2024 11:45Z.
>On Wednesday, March 20, 2024 12:30 PM Rémi Denis-Courmont wrote:
>
>> You're not supposed to guess the link ID from the local address. This is 
>> counter-sensical. And it's entirely possible to have the same LL address 
>> assigned to two interfaces (e.g. using a software bridge) anyway.
>
>You are right about the same LL on multiple interfaces, that’s why the 
>`sin6_scope_id` is used. For specifying LL address, a scoped address format 
>should be used to avoid ambiguity.

Yes, the whole point is that LL addresses are ambiguous.

> In all other cases, determining the interface ID by address should be ok,

No! The only other case is non-LL addressing, which does not require link ID at 
all.

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

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

Re: [FFmpeg-devel] [PATCH v2] avformat: enable UDP IPv6 multicast interface selection

This message has been marked as Public on 03/20/2024 12:35Z.
On Wednesday, March 20, 2024 1:18 PM Rémi Denis-Courmont wrote:

>> In all other cases, determining the interface ID by address should be
>> ok,
>
> No! The only other case is non-LL addressing, which does not require link ID 
> at all.

For IPv4 that is certainly true, but it differs for v6. 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.

Lazar Ignjatović
Associate Software Engineer

Cubic Defense
cubic.com
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [PATCH] avutil/timestamp: keep microsecond precision in av_ts_make_time_string

2024-03-20 Thread Andreas Rheinhardt

Andreas Rheinhardt:
> Marton Balint:
>> av_ts_make_time_string() used "%.6g" format in the past, but this format was
>> losing precision even when the timestamp to be printed was not that large. 
>> For
>> example for 3 hours (10800) seconds, only 1 decimal digit was printed, which
>> made this format inaccurate when it was used in e.g. the silencedetect 
>> filter.
>> Other detection filters printing timestamps had similar issues.
>>
>> So let's change the used format to "%.6f" instead, we have plenty of space in
>> the string buffer, we can somewhat imitate existing behaviour of %g by 
>> trimming
>> ending zeroes and the potential decimal point, which can be any non-numeric
>> character. In order not to trim "inf" as well, we assume that the decimal
>> point does not contain the letter "f".
>>
>> We also no longer use scientific representation to make parsing and printing
>> easier, because the theoretical maximum of INT64_MAX*INT32_MAX still fits 
>> into
>> the string buffer in normal form.
>>
>> Since the additional processing yields more code, inlineing this function no
>> longer make sense, so this commit also changes the API to actually export the
>> function instead of having it inlinable in the header.
>>
>> Thanks for Allan Cady for bringing up this issue.
>>
>> Signed-off-by: Marton Balint 
>> ---
>>  doc/APIchanges   |  3 ++
>>  libavutil/Makefile   |  1 +
>>  libavutil/timestamp.c| 33 
>>  libavutil/timestamp.h|  8 +
>>  libavutil/version.h  |  2 +-
>>  tests/ref/fate/filter-metadata-scdet | 12 +++
>>  tests/ref/fate/filter-metadata-silencedetect |  2 +-
>>  7 files changed, 46 insertions(+), 15 deletions(-)
>>  create mode 100644 libavutil/timestamp.c
>>
>> diff --git a/doc/APIchanges b/doc/APIchanges
>> index a44c8e4f10..1afde062a5 100644
>> --- a/doc/APIchanges
>> +++ b/doc/APIchanges
>> @@ -2,6 +2,9 @@ The last version increases of all libraries were on 
>> 2024-03-07
>>  
>>  API changes, most recent first:
>>  
>> +2024-03-xx - xx - lavu 59.3.100 - timestamp.h
>> +  av_ts_make_time_string() is no longer an inline function. It is now 
>> exported.
>> +
>>  2024-03-xx - xx - lavu 59.2.100 - channel_layout.h
>>Add AV_CHANNEL_LAYOUT_RETYPE_FLAG_CANONICAL.
>>  
>> diff --git a/libavutil/Makefile b/libavutil/Makefile
>> index e7709b97d0..5e75aa1855 100644
>> --- a/libavutil/Makefile
>> +++ b/libavutil/Makefile
>> @@ -174,6 +174,7 @@ OBJS = adler32.o 
>>\
>> threadmessage.o  \
>> time.o   \
>> timecode.o   \
>> +   timestamp.o  \
>> tree.o   \
>> twofish.o\
>> utils.o  \
>> diff --git a/libavutil/timestamp.c b/libavutil/timestamp.c
>> new file mode 100644
>> index 00..06fb47e94c
>> --- /dev/null
>> +++ b/libavutil/timestamp.c
>> @@ -0,0 +1,33 @@
>> +/*
>> + * This file is part of FFmpeg.
>> + *
>> + * FFmpeg is free software; you can redistribute it and/or
>> + * modify it under the terms of the GNU Lesser General Public
>> + * License as published by the Free Software Foundation; either
>> + * version 2.1 of the License, or (at your option) any later version.
>> + *
>> + * FFmpeg is distributed in the hope that it will be useful,
>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
>> + * Lesser General Public License for more details.
>> + *
>> + * You should have received a copy of the GNU Lesser General Public
>> + * License along with FFmpeg; if not, write to the Free Software
>> + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 
>> USA
>> + */
>> +
>> +#include "timestamp.h"
>> +
>> +char *av_ts_make_time_string(char *buf, int64_t ts, const AVRational *tb)
>> +{
>> +if (ts == AV_NOPTS_VALUE) {
>> +snprintf(buf, AV_TS_MAX_STRING_SIZE, "NOPTS");
>> +} else {
>> +int last = snprintf(buf, AV_TS_MAX_STRING_SIZE, "%.6f", av_q2d(*tb) 
>> * ts);
>> +last = FFMIN(last, AV_TS_MAX_STRING_SIZE - 1) - 1;
>> +for (; last && buf[last] == '0'; last--);
>> +for (; last && buf[last] != 'f' && (buf[last] < '0' || buf[0] > 
>> '9'); last--);
>> +buf[last + 1] = '\0';
>> +}
>> +return buf;
>> +}
> 
> As has already been said before: Simply using %.6f will discard
> significant digits for small timestamps. E.g. 10^-7 will simply print
> 0.00, which will then be conver

Re: [FFmpeg-devel] [PATCH 3/3] Revert "avcodec/h264_mp4toannexb_bsf: fix missing PS before IDR frames"

On Wed, Mar 20, 2024 at 02:41:05PM +0800, Zhao Zhili wrote:
> 
> 
> > On Mar 20, 2024, at 10:19, Michael Niedermayer  
> > wrote:
> > 
> > This reverts commit d3aa0cd16f5e952bc346b7c74b4dcba95151a63a.
> > 
> > Fixes: out of array write
> > Fixes: 
> > 64407/clusterfuzz-testcase-minimized-ffmpeg_BSF_H264_MP4TOANNEXB_fuzzer-4966763443650560
> > 
> > The bsf code performs 2 iterations, the first counts how much space is 
> > needed
> > than allocates
> > and the 2nd pass copies into teh allocated space
> > 
> > The reverted code reallocates sps/pps in the first pass in a data dependant 
> > way that leaves
> > the 2nd pass in a different state then the first
> 
> Sorry for the break. How to access the fuzz report details?

ossfuzz made this one public already
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=64407

thx

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

Modern terrorism, a quick summary: Need oil, start war with country that
has oil, kill hundread thousand in war. Let country fall into chaos,
be surprised about raise of fundamantalists. Drop more bombs, kill more
people, be surprised about them taking revenge and drop even more bombs
and strip your own citizens of their rights and freedoms. to be continued

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

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

Re: [FFmpeg-devel] [PATCH 1/4] avcodec/jpeg2000htdec: Check M_b / magp before using it in a shift

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

thx

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

If a bugfix only changes things apparently unrelated to the bug with no
further explanation, that is a good sign that the bugfix is wrong.


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 v5 1/4] avformat/rcwtdec: add RCWT Closed Captions demuxer

On date Tuesday 2024-03-19 12:39:10 -0500, Marth64 wrote:
> Signed-off-by: Marth64 
> ---
>  Changelog|   2 +-
>  doc/demuxers.texi|  29 
>  libavformat/Makefile |   1 +
>  libavformat/allformats.c |   1 +
>  libavformat/rcwtdec.c| 148 +++
>  5 files changed, 180 insertions(+), 1 deletion(-)
>  create mode 100644 libavformat/rcwtdec.c
> 
> diff --git a/Changelog b/Changelog
> index e3ca52430c..be871f75cd 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
> +- Raw Captions with Time (RCWT) closed caption 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..26d4ba18a1 100644
> --- a/doc/demuxers.texi
> +++ b/doc/demuxers.texi
> @@ -1038,6 +1038,35 @@ 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.
> +It can be used to archive the original, raw CC bitstream and to produce
> +a source file for later CC processing or conversion. This demuxer can process
> +RCWT sources created by ccextractor or FFmpeg. 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 ASSA (using FFmpeg's CC decoder):

ASS ??

> +@example
> +ffmpeg -i CC.rcwt.bin CC.ass
> +@end example
> +
> +@item

> +Convert an RCWT backup to SCC:

for the sake of exclicitness, I'd avoid more acronyms, I'd guess this
is source Closed Caption?

[...]

Looks good to me otherwise, thanks.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [PATCH v5 4/4] doc/indevs: update CC extraction example to use RCWT muxer

On date Tuesday 2024-03-19 12:39:13 -0500, Marth64 wrote:
> Signed-off-by: Marth64 
> ---
>  doc/indevs.texi | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/doc/indevs.texi b/doc/indevs.texi
> index d1b2bacf8b..fc14737181 100644
> --- a/doc/indevs.texi
> +++ b/doc/indevs.texi
> @@ -1069,9 +1069,9 @@ ffplay -f lavfi 
> "movie=test.avi[out0];amovie=test.wav[out1]"
>  @end example
>  
>  @item
> -Dump decoded frames to images and closed captions to a file (experimental):
> +Dump decoded frames to images and Closed Captions to an RCWT backup:
>  @example
> -ffmpeg -f lavfi -i "movie=test.ts[out0+subcc]" -map v frame%08d.png -map s 
> -c copy -f rawvideo subcc.bin
> +ffmpeg -f lavfi -i "movie=test.ts[out0+subcc]" -map v frame%08d.png -map s 
> -c copy subcc.bin
>  @end example

Other patches look good as well. Once you update the first one, we can
wait a few more days for comments and eventually apply them.
___
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 1/4] avformat/rcwtdec: add RCWT Closed Captions demuxer

2024-03-20 Thread Andreas Rheinhardt

Marth64:
> Raw Captions With Time (RCWT) is a format native to ccextractor, a commonly
> used open source tool for processing 608/708 Closed Captions (CC) sources.
> RCWT can be used to archive the original 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 interoperate
> with ccextractor (which produces RCWT). Using the muxer/demuxer combination,
> the CC bits can be kept for further processing or rendering with either tool.
> This can be an effective approach to backup original CC presentations.
> 
> Prior to this, the next best solution was FFmpeg's SCC muxer, but SCC itself
> is not compatible with ccextractor (which is a de facto OSS CC processing 
> tool)
> and it is a proprietary format.
> 
> Tests will follow.
> 
> Signed-off-by: Marth64 
> ---
>  Changelog|   2 +-
>  libavformat/Makefile |   1 +
>  libavformat/allformats.c |   1 +
>  libavformat/rcwtdec.c| 150 +++
>  4 files changed, 153 insertions(+), 1 deletion(-)
>  create mode 100644 libavformat/rcwtdec.c
> 
> diff --git a/Changelog b/Changelog
> index e3ca52430c..abe5f79b85 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/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..0d9eba025a
> --- /dev/null
> +++ b/libavformat/rcwtdec.c
> @@ -0,0 +1,150 @@
> +/*
> + * 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 Lesser General Public
> + * License along with FFmpeg; if not, write to the Free Software
> + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 
> USA
> + */
> +
> +/*
> + * 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.
> + *
> + * This demuxer implements the specification as of March 2024, which has
> + * been stable and unchanged since April 2014.
> + *
> + * A free specification of RCWT can be found here:
> + * 
> @url{https://github.com/CCExtractor/ccextractor/blob/master/docs/BINARY_FILE_FORMAT.TXT}
> + */
> +
> +#include "avformat.h"
> +#include "demux.h"
> +#include "internal.h"
> +#include "subtitles.h"
> +#include "libavutil/intreadwrite.h"
> +
> +#define RCWT_CLUSTER_MAX_BLOCKS 65535
> +#define RCWT_BLOCK_SIZE 3
> +#define RCWT_HEADER_SIZE11
> +
> +typedef struct RCWTContext {
> +FFDemuxSubtitlesQueue q;
> +} RCWTContext;
> +
> +static int rcwt_read_header(AVFormatContext *avf)
> +{
> +RCWTContext *rcwt = avf->priv_data;
> +
> +AVPacket  *sub = NULL;
> +AVStream  *st;
> +

Re: [FFmpeg-devel] [PATCH 2/2] avfilter/vf_scale2ref: switch to FFFrameSync

2024-03-20 Thread Niklas Haas

On Tue, 19 Mar 2024 22:55:56 +0100 Michael Niedermayer  
wrote:
> is it neccessary to drop compatibility to the old syntax ?

Only if we want to use framesync. If we don't care about synchronizing
the streams, then we could drop FS and just use a custom activate
function which forwards output status only to the *corresponding* input.

Maybe also with printing a warning if the refstream parameters do happen
to change, since at that point we know it wouldn't be in sync.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [PATCH] lavc/vvc: Fix check whether QG is in first tile col

2024-03-20 Thread Nuo Mi

On Wed, Mar 20, 2024 at 3:48 AM Frank Plowman  wrote:

> The second part of this condition is intended to check whether the
> current quantisation group is in the first CTU column of the current
> tile.  The issue is that ctb_to_col_bd gives the x-ordinate of the first
> column of the current tile *in CTUs*, while xQg gives the x-ordinate of
> the quantisation group *in samples*.  Rectify this by shifting xQg by
> ctb_log2_size to get xQg in CTUs before comparing.
>
> Fixes FFVVC issues #201 and #203.
>
Thank you, Frank.
Pushed.

> ---
>  libavcodec/vvc/vvc_ctu.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavcodec/vvc/vvc_ctu.c b/libavcodec/vvc/vvc_ctu.c
> index 519bd1ba76..8ba12c8d9f 100644
> --- a/libavcodec/vvc/vvc_ctu.c
> +++ b/libavcodec/vvc/vvc_ctu.c
> @@ -96,7 +96,7 @@ static int get_qp_y_pred(const VVCLocalContext *lc)
>  if (lc->na.cand_up) {
>  const int first_qg_in_ctu = !(xQg & ctb_size_mask) &&  !(yQg &
> ctb_size_mask);
>  const int qPy_up  = fc->tab.qp[LUMA][x_cb + (y_cb - 1) *
> min_cb_width];
> -if (first_qg_in_ctu && pps->ctb_to_col_bd[xQg >> ctb_log2_size]
> == xQg)
> +if (first_qg_in_ctu && pps->ctb_to_col_bd[xQg >> ctb_log2_size]
> == xQg >> ctb_log2_size)
>  return qPy_up;
>  }
>
> --
> 2.42.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 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 1/4] avformat/rcwtdec: add RCWT Closed Captions demuxer

On date Tuesday 2024-03-19 17:44:26 -0500, Marth64 wrote:
> Raw Captions With Time (RCWT) is a format native to ccextractor, a commonly
> used open source tool for processing 608/708 Closed Captions (CC) sources.
> RCWT can be used to archive the original 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 interoperate
> with ccextractor (which produces RCWT). Using the muxer/demuxer combination,
> the CC bits can be kept for further processing or rendering with either tool.
> This can be an effective approach to backup original CC presentations.
> 
> Prior to this, the next best solution was FFmpeg's SCC muxer, but SCC itself
> is not compatible with ccextractor (which is a de facto OSS CC processing 
> tool)
> and it is a proprietary format.
> 
> Tests will follow.
> 
> Signed-off-by: Marth64 
> ---
>  Changelog|   2 +-
>  libavformat/Makefile |   1 +
>  libavformat/allformats.c |   1 +
>  libavformat/rcwtdec.c| 150 +++

missing docs in the update?

>  4 files changed, 153 insertions(+), 1 deletion(-)
>  create mode 100644 libavformat/rcwtdec.c
> 
> diff --git a/Changelog b/Changelog
> index e3ca52430c..abe5f79b85 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/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..0d9eba025a
> --- /dev/null
> +++ b/libavformat/rcwtdec.c
> @@ -0,0 +1,150 @@
> +/*
> + * 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 Lesser General Public
> + * License along with FFmpeg; if not, write to the Free Software
> + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 
> USA
> + */
> +
> +/*
> + * 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.
> + *
> + * This demuxer implements the specification as of March 2024, which has
> + * been stable and unchanged since April 2014.
> + *
> + * A free specification of RCWT can be found here:
> + * 
> @url{https://github.com/CCExtractor/ccextractor/blob/master/docs/BINARY_FILE_FORMAT.TXT}
> + */
> +
> +#include "avformat.h"
> +#include "demux.h"
> +#include "internal.h"
> +#include "subtitles.h"
> +#include "libavutil/intreadwrite.h"
> +
> +#define RCWT_CLUSTER_MAX_BLOCKS 65535
> +#define RCWT_BLOCK_SIZE 3
> +#define RCWT_HEADER_SIZE11
> +
> +typedef struct RCWTContext {
> +FFDemuxSubtitlesQueue q;
> +} RCWTContext;
> +
> +static int rcwt_read_header(AVFormatContext *avf)
> +{
> +RCWTContext *rcwt = avf->pr

Re: [FFmpeg-devel] [PATCH v6 3/4] doc/{muxers, demuxers}: add RCWT demuxer doc and refresh the muxer's doc to be consistent

On date Tuesday 2024-03-19 17:44:28 -0500, Marth64 wrote:
> Signed-off-by: Marth64 
> ---
>  doc/demuxers.texi | 26 ++
>  doc/muxers.texi   | 29 +++--
>  2 files changed, 45 insertions(+), 10 deletions(-)
> 
> diff --git a/doc/demuxers.texi b/doc/demuxers.texi
> index b70f3a38d7..47e82eda55 100644
> --- a/doc/demuxers.texi
> +++ b/doc/demuxers.texi
> @@ -1038,6 +1038,32 @@ 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 ASSA (using FFmpeg's CC decoder):

what is ASSA?

> +@example
> +ffmpeg -i CC.rcwt.bin CC.ass
> +@end example
> +
> +@item

> +Convert an RCWT backup to SCC:

let's expand SCC

> +@example
> +ffmpeg -i CC.rcwt.bin -c:s copy CC.scc
> +@end example
> +@end itemize
> +
LGTM otheriwse, thanks.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [PATCH] Changelog: Add libtorch

On date Wednesday 2024-03-20 16:01:36 +0800, 
wenbin.chen-at-intel@ffmpeg.org wrote:
> From: Wenbin Chen 
> 
> Signed-off-by: Wenbin Chen 
> ---
>  Changelog | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/Changelog b/Changelog
> index e3ca52430c..d0c41887f3 100644
> --- a/Changelog
> +++ b/Changelog
> @@ -35,6 +35,7 @@ version :
>  - AEA muxer
>  - ffmpeg CLI loopback decoders

>  - Support PacketTypeMetadata of PacketType in enhanced flv format

> +- Support libtorch as DNN backend

missing context, my take:
libtorch backend in dnn filter

or:
dnn filter libtorch backend

usually there is no capitalization and no verb in the items, but a
description of the introduced feature
___
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/4] lavf/gxfenc: consistently use snake_case in function names

---
 libavformat/gxfenc.c | 20 ++--
 1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/libavformat/gxfenc.c b/libavformat/gxfenc.c
index 7495924722..9ea24c2f27 100644
--- a/libavformat/gxfenc.c
+++ b/libavformat/gxfenc.c
@@ -137,7 +137,7 @@ static void gxf_write_padding(AVIOContext *pb, int64_t 
to_pad)
 ffio_fill(pb, 0, to_pad);
 }
 
-static int64_t updatePacketSize(AVIOContext *pb, int64_t pos)
+static int64_t update_packet_size(AVIOContext *pb, int64_t pos)
 {
 int64_t curpos;
 int size;
@@ -154,7 +154,7 @@ static int64_t updatePacketSize(AVIOContext *pb, int64_t 
pos)
 return curpos - pos;
 }
 
-static int64_t updateSize(AVIOContext *pb, int64_t pos)
+static int64_t update_size(AVIOContext *pb, int64_t pos)
 {
 int64_t curpos;
 
@@ -300,7 +300,7 @@ static int gxf_write_track_description(AVFormatContext *s, 
GXFStreamContext *sc,
 avio_w8(pb, 4);
 avio_wb32(pb, sc->fields);
 
-return updateSize(pb, pos);
+return update_size(pb, pos);
 }
 
 static int gxf_write_material_data_section(AVFormatContext *s)
@@ -351,7 +351,7 @@ static int gxf_write_material_data_section(AVFormatContext 
*s)
 avio_w8(pb, 4);
 avio_wb32(pb, avio_size(pb) / 1024);
 
-return updateSize(pb, pos);
+return update_size(pb, pos);
 }
 
 static int gxf_write_track_description_section(AVFormatContext *s)
@@ -368,7 +368,7 @@ static int 
gxf_write_track_description_section(AVFormatContext *s)
 
 gxf_write_track_description(s, &gxf->timecode_track, s->nb_streams);
 
-return updateSize(pb, pos);
+return update_size(pb, pos);
 }
 
 static int gxf_write_map_packet(AVFormatContext *s, int rewrite)
@@ -400,7 +400,7 @@ static int gxf_write_map_packet(AVFormatContext *s, int 
rewrite)
 gxf_write_material_data_section(s);
 gxf_write_track_description_section(s);
 
-return updatePacketSize(pb, pos);
+return update_packet_size(pb, pos);
 }
 
 static int gxf_write_flt_packet(AVFormatContext *s)
@@ -424,7 +424,7 @@ static int gxf_write_flt_packet(AVFormatContext *s)
 
 ffio_fill(pb, 0, (1000 - i) * 4);
 
-return updatePacketSize(pb, pos);
+return update_packet_size(pb, pos);
 }
 
 static int gxf_write_umf_material_description(AVFormatContext *s)
@@ -643,7 +643,7 @@ static int gxf_write_umf_packet(AVFormatContext *s)
 gxf->umf_track_size = gxf_write_umf_track_description(s);
 gxf->umf_media_size = gxf_write_umf_media_description(s);
 gxf->umf_length = avio_tell(pb) - gxf->umf_start_offset;
-return updatePacketSize(pb, pos);
+return update_packet_size(pb, pos);
 }
 
 static void gxf_init_timecode_track(GXFStreamContext *sc, GXFStreamContext 
*vsc)
@@ -823,7 +823,7 @@ static int gxf_write_eos_packet(AVIOContext *pb)
 int64_t pos = avio_tell(pb);
 
 gxf_write_packet_header(pb, PKT_EOS);
-return updatePacketSize(pb, pos);
+return update_packet_size(pb, pos);
 }
 
 static int gxf_write_trailer(AVFormatContext *s)
@@ -956,7 +956,7 @@ static int gxf_write_packet(AVFormatContext *s, AVPacket 
*pkt)
 gxf->nb_fields += 2; // count fields
 }
 
-updatePacketSize(pb, pos);
+update_packet_size(pb, pos);
 
 gxf->packet_count++;
 if (gxf->packet_count == 100) {
-- 
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 2/4] lavf/gcfenc: return proper error codes in case of failure

---
 libavformat/gxfenc.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/libavformat/gxfenc.c b/libavformat/gxfenc.c
index 9ea24c2f27..0aea7bd7c2 100644
--- a/libavformat/gxfenc.c
+++ b/libavformat/gxfenc.c
@@ -692,7 +692,7 @@ static int gxf_write_header(AVFormatContext *s)
 
 if (!(pb->seekable & AVIO_SEEKABLE_NORMAL)) {
 av_log(s, AV_LOG_ERROR, "gxf muxer does not support streamed output, 
patch welcome\n");
-return -1;
+return AVERROR_PATCHWELCOME;
 }
 
 gxf->flags |= 0x0008; /* material is simple clip */
@@ -707,15 +707,15 @@ static int gxf_write_header(AVFormatContext *s)
 if (st->codecpar->codec_type == AVMEDIA_TYPE_AUDIO) {
 if (st->codecpar->codec_id != AV_CODEC_ID_PCM_S16LE) {
 av_log(s, AV_LOG_ERROR, "only 16 BIT PCM LE allowed for 
now\n");
-return -1;
+return AVERROR(EINVAL);
 }
 if (st->codecpar->sample_rate != 48000) {
 av_log(s, AV_LOG_ERROR, "only 48000hz sampling rate is 
allowed\n");
-return -1;
+return AVERROR(EINVAL);
 }
 if (st->codecpar->ch_layout.nb_channels != 1) {
 av_log(s, AV_LOG_ERROR, "only mono tracks are allowed\n");
-return -1;
+return AVERROR(EINVAL);
 }
 ret = ff_stream_add_bitstream_filter(st, "pcm_rechunk", 
"n="AV_STRINGIFY(GXF_SAMPLES_PER_FRAME));
 if (ret < 0)
@@ -733,7 +733,7 @@ static int gxf_write_header(AVFormatContext *s)
 } else if (st->codecpar->codec_type == AVMEDIA_TYPE_VIDEO) {
 if (i != 0) {
 av_log(s, AV_LOG_ERROR, "video stream must be the first 
track\n");
-return -1;
+return AVERROR(EINVAL);
 }
 /* FIXME check from time_base ? */
 if (st->codecpar->height == 480 || st->codecpar->height == 512) { 
/* NTSC or NTSC+VBI */
@@ -750,7 +750,7 @@ static int gxf_write_header(AVFormatContext *s)
 } else {
 av_log(s, AV_LOG_ERROR, "unsupported video resolution, "
"gxf muxer only accepts PAL or NTSC resolutions 
currently\n");
-return -1;
+return AVERROR(EINVAL);
 }
 if (!tcr)
 tcr = av_dict_get(st->metadata, "timecode", NULL, 0);
-- 
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 3/4] doc/muxers: add gxf

---
 doc/muxers.texi | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/doc/muxers.texi b/doc/muxers.texi
index d9dd72e613..25d1a5907e 100644
--- a/doc/muxers.texi
+++ b/doc/muxers.texi
@@ -1776,6 +1776,16 @@ force the @ref{image2} muxer:
 ffmpeg -i INPUT -c:v gif -f image2 "out%d.gif"
 @end example
 
+@section gxf
+General eXchange Format (GXF) muxer.
+
+GXF was developed by Grass Valley Group, then standardized by SMPTE as SMPTE
+360M and was extended in SMPTE RDD 14-2007 to include high-definition video
+resolutions.
+
+It accepts an arbitrary number of audio and video streams, but only a limited
+number of codecs and parameters are accepted.
+
 @anchor{hash}
 @section hash
 
-- 
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 4/4] doc/muxers: add hds

---
 doc/muxers.texi | 39 +++
 1 file changed, 39 insertions(+)

diff --git a/doc/muxers.texi b/doc/muxers.texi
index 25d1a5907e..e7f2a93058 100644
--- a/doc/muxers.texi
+++ b/doc/muxers.texi
@@ -1831,6 +1831,45 @@ ffmpeg -i INPUT -f hash -hash md5 -
 
 See also the @ref{framehash} muxer.
 
+@anchor{hds}
+@section hds
+HTTP Dynamic Streaming (HDS) muxer.
+
+HTTP dynamic streaming, or HDS, is an adaptive bitrate streaming method
+developed by Adobe. HDS delivers MP4 video content over HTTP connections. HDS
+can be used for on-demand streaming or live streaming.
+
+This muxer creates an .f4m (Adobe Flash Media Manifest File) manifest, an .abst
+(Adobe Bootstrap File) for each stream, and segment files in a directory
+specified as the output.
+
+These needs to be accessed by an HDS player throuhg HTTPS for it to be able to
+perform playback on the generated stream.
+
+@subsection Options
+@table @option
+@item extra_window_size @var{int}
+number of fragments kept outside of the manifest before removing from disk
+
+@item min_frag_duration @var{microseconds}
+minimum fragment duration (in microseconds), default value is 1 second
+(@code{1000})
+
+@item remove_at_exit @var{bool}
+remove all fragments when finished when set to @code{true}
+
+@item window_size @var{int}
+number of fragments kept in the manifest, if set to a value different from
+@code{0}. By default all segments are kept in the output directory.
+@end table
+
+@subsection Example
+Use @command{ffmpeg} to generate HDS files to the @file{output.hds} directory 
in
+real-time rate:
+@example
+ffmpeg -re -i INPUT -f hds -b:v 200k output.hds
+@end example
+
 @anchor{hls}
 @section hls
 
-- 
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 1/2 v3] configure: make the C and C++ standard settable

While ensuring it's at least C11, the minimum supported version.
Also, enforce C11 on the host compiler, same as we already do for C11 on the
target compiler.

Signed-off-by: James Almer 
---
Now with the new options added to CMDLINE_SET

 configure | 75 ---
 1 file changed, 66 insertions(+), 9 deletions(-)

diff --git a/configure b/configure
index e019d1b996..838929d7f3 100755
--- a/configure
+++ b/configure
@@ -387,7 +387,9 @@ Toolchain options:
   --windres=WINDRESuse windows resource compiler WINDRES 
[$windres_default]
   --x86asmexe=EXE  use nasm-compatible assembler EXE 
[$x86asmexe_default]
   --cc=CC  use C compiler CC [$cc_default]
+  --stdc=STDC  use C standard STDC [$stdc_default]
   --cxx=CXXuse C compiler CXX [$cxx_default]
+  --stdcxx=STDCXX  use C standard STDCXX [$stdcxx_default]
   --objcc=OCC  use ObjC compiler OCC [$cc_default]
   --dep-cc=DEPCC   use dependency generator DEPCC [$cc_default]
   --nvcc=NVCC  use Nvidia CUDA compiler NVCC or clang 
[$nvcc_default]
@@ -1454,6 +1456,33 @@ test_cflags_cc(){
 EOF
 }
 
+check_cflags_cc(){
+log check_cflags_cc "$@"
+flags=$1
+test_cflags_cc "$@" && add_cflags $flags
+}
+
+test_cxxflags_cc(){
+log test_cxxflags_cc "$@"
+flags=$1
+header=$2
+condition=$3
+shift 3
+set -- $($cflags_filter "$flags")
+test_cxx "$@" <
+#if !($condition)
+#error "unsatisfied condition: $condition"
+#endif
+EOF
+}
+
+check_cxxflags_cc(){
+log check_cxxflags_cc "$@"
+flags=$1
+test_cxxflags_cc "$@" && add_cxxflags $flags
+}
+
 check_lib(){
 log check_lib "$@"
 name="$1"
@@ -1695,6 +1724,27 @@ int x;
 EOF
 }
 
+test_host_cflags_cc(){
+log test_host_cflags_cc "$@"
+flags=$1
+header=$2
+condition=$3
+shift 3
+set -- $($host_cflags_filter "$flags")
+test_host_cc "$@" <
+#if !($condition)
+#error "unsatisfied condition: $condition"
+#endif
+EOF
+}
+
+check_host_cflags_cc(){
+log check_host_cflags_cc "$@"
+flags=$1
+test_host_cflags_cc "$@" && add_host_cflags $flags
+}
+
 test_host_cpp_condition(){
 log test_host_cpp_condition "$@"
 header=$1
@@ -2652,6 +2702,8 @@ CMDLINE_SET="
 random_seed
 ranlib
 samples
+stdc
+stdcxx
 strip
 sws_max_filter_size
 sysinclude
@@ -3980,6 +4032,8 @@ mandir_default='${prefix}/share/man'
 # toolchain
 ar_default="ar"
 cc_default="gcc"
+stdc_default="c11"
+stdcxx_default="c++11"
 cxx_default="g++"
 host_cc_default="gcc"
 doxygen_default="doxygen"
@@ -4587,7 +4641,7 @@ if enabled cuda_nvcc; then
 fi
 
 set_default arch cc cxx doxygen pkg_config ranlib strip sysinclude \
-target_exec x86asmexe metalcc metallib
+target_exec x86asmexe metalcc metallib stdc stdcxx
 enabled cross_compile || host_cc_default=$cc
 set_default host_cc
 
@@ -4757,7 +4811,7 @@ icl_flags(){
 # Despite what Intel's documentation says -Wall, which is supported
 # on Windows, does enable remarks so disable them here.
 -Wall)echo $flag -Qdiag-disable:remark ;;
--std=c11) echo -Qstd=c11 ;;
+-std=$stdc)   echo -Qstd=$stdc ;;
 -flto*)   echo -ipo ;;
 esac
 done
@@ -4805,7 +4859,7 @@ suncc_flags(){
 athlon*)   echo -xarch=pentium_proa  ;;
 esac
 ;;
--std=c11) echo -xc11  ;;
+-std=$stdc)   echo -x$stdc;;
 -fomit-frame-pointer) echo -xregs=frameptr;;
 -fPIC)echo -KPIC -xcode=pic32 ;;
 -W*,*)echo $flag  ;;
@@ -4894,8 +4948,8 @@ probe_cc(){
 _type=suncc
 _ident=$($_cc -V 2>&1 | head -n1 | cut -d' ' -f 2-)
 _DEPCMD='$(DEP$(1)) $(DEP$(1)FLAGS) $($(1)DEP_FLAGS) $< | sed -e 
"1s,^.*: ,$@: ," -e "\$$!s,\$$, \\\," -e "1!s,^.*: , ," > $(@:.o=.d)'
-_DEPFLAGS='-xM1 -xc11'
-_ldflags='-std=c11'
+_DEPFLAGS='-xM1 -x$stdc'
+_ldflags='-std=$stdc'
 _cflags_speed='-O5'
 _cflags_size='-O5 -xspace'
 _flags_filter=suncc_flags
@@ -5526,18 +5580,21 @@ fi
 
 add_cppflags -D_ISOC11_SOURCE
 add_cxxflags -D__STDC_CONSTANT_MACROS
-check_cxxflags -std=c++11 || check_cxxflags -std=c++0x
+check_cxxflags_cc -std=$stdcxx ctype.h "__cplusplus >= 201103L" ||
+{ check_cxxflags -std=c++11 && stdcxx="c++11" || { check_cxxflags 
-std=c++0x && stdcxx="c++0x"; }; }
 
 # some compilers silently accept -std=c11, so we also need to check that the
 # version macro is defined properly
-test_cflags_cc -std=c11 ctype.h "__STDC_VERSION__ >= 201112L" &&
-add_cflags -std=c11 || die "Compiler lacks C11 support"
+check_cflags_cc -std=$stdc ctype.h "__STDC_VERSION__ >= 201112L" ||
+{ check_cflags_cc -std=c11 c

Re: [FFmpeg-devel] [PATCH v10 00/14] encoder AVCodecContext configuration side data

On 3/18/2024 6:31 PM, Jan Ekström wrote:

Differences to v9:
1. rebased on top of current master
2. renamed the avctx AVFrameSideData array according to Anton's naming sense,
as at this point that is now OK by James as well and I just want to get this
done with.
3. removed the avctx helper to get through review.
4. added "Afterwards owned and freed by the encoder" comment into the
description of the side data array.
5. added APIchanges (missing the AVBufferRef function since that is for now to
be skipped) and avutil/avcodec bumps.
6. removed all references to "_set" from internal functions and the newly added
test. The only thing that is left around that is a set is a 100% internal
helper struct for the side_data_array test called FrameSideDataSet.

Comparison URL (mostly configure and wrappers, avutil/frame.c):
https://github.com/jeeb/ffmpeg/compare/avcodec_cll_mdcv_side_data_v9..avcodec_cll_mdcv_side_data_v10

This patch set I've now been working for a while since I felt like it was weird
we couldn't pass through information such as static HDR metadata to encoders
from decoded input. This initial version adds the necessary framework, as well
as adds static HDR metadata support for libsvtav1, libx264 as well as libx265
wrappers.

An alternative to this would be to make encoders only properly initialize when
they receive the first AVFrame, but that seems to be a bigger, nastier change
than introducing an AVFrameSideDataSet in avctx as everything seems to
presume that extradata etc are available after opening the encoder.

Note: Any opinions on whether FFCodec or AVCodec should have
handled_side_data list, so that if format specific generic logic is
added, it could be checked whether the codec itself handles this side
data? This could also be utilized to list handled side data from f.ex.
`ffmpeg -h encoder=libsvtav1`.

Jan

Jan Ekström (14):
avutil/frame: split side data list wiping out to non-AVFrame function
avutil/frame: add helper for freeing arrays of side data
avutil/frame: split side_data_from_buf to base and AVFrame func
avutil/frame: split side data removal out to non-AVFrame function
avutil/frame: add helper for adding side data to array
avutil/frame: add helper for adding existing side data to array
avutil/frame: add helper for adding side data w/ AVBufferRef to array
avutil/frame: add helper for getting side data from array
{avutil/version,APIchanges}: bump, document new AVFrameSideData
functions
avcodec: add frame side data array to AVCodecContext
ffmpeg: pass first video AVFrame's side data to encoder
avcodec/libsvtav1: add support for writing out CLL and MDCV
avcodec/libx264: add support for writing out CLL and MDCV
avcodec/libx265: add support for writing out CLL and MDCV

LGTM. Except for patch 7 which is still in discussion and is currently
not required, the rest can go in.

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

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

Re: [FFmpeg-devel] [PATCH 3/4] doc/muxers: add gxf

2024-03-20 Thread Andreas Rheinhardt

Stefano Sabatini:
> ---
>  doc/muxers.texi | 10 ++
>  1 file changed, 10 insertions(+)
> 
> diff --git a/doc/muxers.texi b/doc/muxers.texi
> index d9dd72e613..25d1a5907e 100644
> --- a/doc/muxers.texi
> +++ b/doc/muxers.texi
> @@ -1776,6 +1776,16 @@ force the @ref{image2} muxer:
>  ffmpeg -i INPUT -c:v gif -f image2 "out%d.gif"
>  @end example
>  
> +@section gxf
> +General eXchange Format (GXF) muxer.
> +
> +GXF was developed by Grass Valley Group, then standardized by SMPTE as SMPTE
> +360M and was extended in SMPTE RDD 14-2007 to include high-definition video
> +resolutions.
> +
> +It accepts an arbitrary number of audio and video streams, but only a limited

It only accepts a single video stream, see the check in line 734 of
gxfenc.c.

> +number of codecs and parameters are accepted.
> +
>  @anchor{hash}
>  @section hash
>  

___
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 v10 00/14] encoder AVCodecContext configuration side data

2024-03-20 Thread Jan Ekström

On Wed, Mar 20, 2024 at 7:00 PM James Almer  wrote:
>
> On 3/18/2024 6:31 PM, Jan Ekström wrote:
> > Differences to v9:
> > 1. rebased on top of current master
> > 2. renamed the avctx AVFrameSideData array according to Anton's naming 
> > sense,
> > as at this point that is now OK by James as well and I just want to get 
> > this
> > done with.
> > 3. removed the avctx helper to get through review.
> > 4. added "Afterwards owned and freed by the encoder" comment into the
> > description of the side data array.
> > 5. added APIchanges (missing the AVBufferRef function since that is for now 
> > to
> > be skipped) and avutil/avcodec bumps.
> > 6. removed all references to "_set" from internal functions and the newly 
> > added
> > test. The only thing that is left around that is a set is a 100% 
> > internal
> > helper struct for the side_data_array test called FrameSideDataSet.
> >
> > Comparison URL (mostly configure and wrappers, avutil/frame.c):
> > https://github.com/jeeb/ffmpeg/compare/avcodec_cll_mdcv_side_data_v9..avcodec_cll_mdcv_side_data_v10
> >
> > This patch set I've now been working for a while since I felt like it was 
> > weird
> > we couldn't pass through information such as static HDR metadata to encoders
> > from decoded input. This initial version adds the necessary framework, as 
> > well
> > as adds static HDR metadata support for libsvtav1, libx264 as well as 
> > libx265
> > wrappers.
> >
> > An alternative to this would be to make encoders only properly initialize 
> > when
> > they receive the first AVFrame, but that seems to be a bigger, nastier 
> > change
> > than introducing an AVFrameSideDataSet in avctx as everything seems to
> > presume that extradata etc are available after opening the encoder.
> >
> > Note: Any opinions on whether FFCodec or AVCodec should have
> >handled_side_data list, so that if format specific generic logic is
> >added, it could be checked whether the codec itself handles this side
> >data? This could also be utilized to list handled side data from 
> > f.ex.
> >`ffmpeg -h encoder=libsvtav1`.
> >
> > Jan
> >
> > Jan Ekström (14):
> >avutil/frame: split side data list wiping out to non-AVFrame function
> >avutil/frame: add helper for freeing arrays of side data
> >avutil/frame: split side_data_from_buf to base and AVFrame func
> >avutil/frame: split side data removal out to non-AVFrame function
> >avutil/frame: add helper for adding side data to array
> >avutil/frame: add helper for adding existing side data to array
> >avutil/frame: add helper for adding side data w/ AVBufferRef to array
> >avutil/frame: add helper for getting side data from array
> >{avutil/version,APIchanges}: bump, document new AVFrameSideData
> >  functions
> >avcodec: add frame side data array to AVCodecContext
> >ffmpeg: pass first video AVFrame's side data to encoder
> >avcodec/libsvtav1: add support for writing out CLL and MDCV
> >avcodec/libx264: add support for writing out CLL and MDCV
> >avcodec/libx265: add support for writing out CLL and MDCV
> >
> >   configure |   2 +
> >   doc/APIchanges|   8 ++
> >   fftools/ffmpeg_enc.c  |  15 +++
> >   libavcodec/avcodec.h  |  13 +++
> >   libavcodec/libsvtav1.c|  69 
> >   libavcodec/libx264.c  |  80 +
> >   libavcodec/libx265.c  |  89 +++
> >   libavcodec/options.c  |   2 +
> >   libavcodec/version.h  |   4 +-
> >   libavutil/Makefile|   1 +
> >   libavutil/frame.c | 180 +-
> >   libavutil/frame.h |  88 +++
> >   libavutil/tests/side_data_array.c | 103 +
> >   libavutil/version.h   |   2 +-
> >   tests/fate/enc_external.mak   |  15 +++
> >   tests/fate/libavutil.mak  |   4 +
> >   tests/ref/fate/libsvtav1-hdr10|  14 +++
> >   tests/ref/fate/libx264-hdr10  |  15 +++
> >   tests/ref/fate/libx265-hdr10  |  16 +++
> >   tests/ref/fate/side_data_array|  14 +++
> >   20 files changed, 701 insertions(+), 33 deletions(-)
> >   create mode 100644 libavutil/tests/side_data_array.c
> >   create mode 100644 tests/ref/fate/libsvtav1-hdr10
> >   create mode 100644 tests/ref/fate/libx264-hdr10
> >   create mode 100644 tests/ref/fate/libx265-hdr10
> >   create mode 100644 tests/ref/fate/side_data_array
>
> LGTM. Except for patch 7 which is still in discussion and is currently
> not required, the rest can go in.

Thanks.

Applied everything except for "avutil/frame: add helper for adding
side data w/ AVBufferRef to array".

Jan
___
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

Re: [FFmpeg-devel] [PATCH 3/3] Revert "avcodec/h264_mp4toannexb_bsf: fix missing PS before IDR frames"

2024-03-20 Thread Zhao Zhili



> -Original Message-
> From: ffmpeg-devel  On Behalf Of Michael 
> Niedermayer
> Sent: 2024年3月20日 21:02
> To: FFmpeg development discussions and patches 
> Subject: Re: [FFmpeg-devel] [PATCH 3/3] Revert "avcodec/h264_mp4toannexb_bsf: 
> fix missing PS before IDR frames"
> 
> On Wed, Mar 20, 2024 at 02:41:05PM +0800, Zhao Zhili wrote:
> >
> >
> > > On Mar 20, 2024, at 10:19, Michael Niedermayer  
> > > wrote:
> > >
> > > This reverts commit d3aa0cd16f5e952bc346b7c74b4dcba95151a63a.
> > >
> > > Fixes: out of array write
> > > Fixes: 
> > > 64407/clusterfuzz-testcase-minimized-ffmpeg_BSF_H264_MP4TOANNEXB_fuzzer-4966763443650560
> > >
> > > The bsf code performs 2 iterations, the first counts how much space is 
> > > needed
> > > than allocates
> > > and the 2nd pass copies into teh allocated space
> > >
> > > The reverted code reallocates sps/pps in the first pass in a data 
> > > dependant way that leaves
> > > the 2nd pass in a different state then the first
> >
> > Sorry for the break. How to access the fuzz report details?
> 
> ossfuzz made this one public already
> https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=64407

I can't open the "Detailed Report" link. Does it provide asan details?

I'm currently tied up with daily jobs, I need time to learn how to use oss-fuzz.
Feel free to revert the commit. I would be very grateful if anyone has a quick 
fix for it.
Broken file is less severity than heap-buffer-overflow, but still a serious 
problem.

> 
> thx
> 
> [...]
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
> 
> Modern terrorism, a quick summary: Need oil, start war with country that
> has oil, kill hundread thousand in war. Let country fall into chaos,
> be surprised about raise of fundamantalists. Drop more bombs, kill more
> people, be surprised about them taking revenge and drop even more bombs
> and strip your own citizens of their rights and freedoms. to be continued

___
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 3/4] doc/{muxers, demuxers}: add RCWT demuxer doc and refresh the muxer's doc to be consistent

> what is ASSA?
This should just be ASS, will update

> let's expand SCC
> for the sake of exclicitness, I'd avoid more acronyms, I'd guess this
> is source Closed Caption?
Actually SCC is a format itself (Scenarist Closed Caption) of which FFmpeg
has a muxer and demuxer.
SCC is one of the standard proprietary formats to exchange Closed Captions.
I'll update the doc to highlight the fact better that this is a different
format.

Thank you for the reviews. Working on updates, will send a v7 when ready.
___
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, 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

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

I have never wished to cater to the crowd; for what I know they do not
approve, and what they approve I do not know. -- Epicurus


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

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

Re: [FFmpeg-devel] [PATCH] avutil/timestamp: keep microsecond precision in av_ts_make_time_string

2024-03-20 Thread Marton Balint




On Wed, 20 Mar 2024, Andreas Rheinhardt wrote:


Andreas Rheinhardt:

Marton Balint:

av_ts_make_time_string() used "%.6g" format in the past, but this format was
losing precision even when the timestamp to be printed was not that large. For
example for 3 hours (10800) seconds, only 1 decimal digit was printed, which
made this format inaccurate when it was used in e.g. the silencedetect filter.
Other detection filters printing timestamps had similar issues.

So let's change the used format to "%.6f" instead, we have plenty of space in
the string buffer, we can somewhat imitate existing behaviour of %g by trimming
ending zeroes and the potential decimal point, which can be any non-numeric
character. In order not to trim "inf" as well, we assume that the decimal
point does not contain the letter "f".

We also no longer use scientific representation to make parsing and printing
easier, because the theoretical maximum of INT64_MAX*INT32_MAX still fits into
the string buffer in normal form.

Since the additional processing yields more code, inlineing this function no
longer make sense, so this commit also changes the API to actually export the
function instead of having it inlinable in the header.

Thanks for Allan Cady for bringing up this issue.

Signed-off-by: Marton Balint 
---
 doc/APIchanges   |  3 ++
 libavutil/Makefile   |  1 +
 libavutil/timestamp.c| 33 
 libavutil/timestamp.h|  8 +
 libavutil/version.h  |  2 +-
 tests/ref/fate/filter-metadata-scdet | 12 +++
 tests/ref/fate/filter-metadata-silencedetect |  2 +-
 7 files changed, 46 insertions(+), 15 deletions(-)
 create mode 100644 libavutil/timestamp.c

diff --git a/doc/APIchanges b/doc/APIchanges
index a44c8e4f10..1afde062a5 100644
--- a/doc/APIchanges
+++ b/doc/APIchanges
@@ -2,6 +2,9 @@ The last version increases of all libraries were on 2024-03-07

 API changes, most recent first:

+2024-03-xx - xx - lavu 59.3.100 - timestamp.h
+  av_ts_make_time_string() is no longer an inline function. It is now exported.
+
 2024-03-xx - xx - lavu 59.2.100 - channel_layout.h
   Add AV_CHANNEL_LAYOUT_RETYPE_FLAG_CANONICAL.

diff --git a/libavutil/Makefile b/libavutil/Makefile
index e7709b97d0..5e75aa1855 100644
--- a/libavutil/Makefile
+++ b/libavutil/Makefile
@@ -174,6 +174,7 @@ OBJS = adler32.o
\
threadmessage.o  \
time.o   \
timecode.o   \
+   timestamp.o  \
tree.o   \
twofish.o\
utils.o  \
diff --git a/libavutil/timestamp.c b/libavutil/timestamp.c
new file mode 100644
index 00..06fb47e94c
--- /dev/null
+++ b/libavutil/timestamp.c
@@ -0,0 +1,33 @@
+/*
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include "timestamp.h"
+
+char *av_ts_make_time_string(char *buf, int64_t ts, const AVRational *tb)
+{
+if (ts == AV_NOPTS_VALUE) {
+snprintf(buf, AV_TS_MAX_STRING_SIZE, "NOPTS");
+} else {
+int last = snprintf(buf, AV_TS_MAX_STRING_SIZE, "%.6f", av_q2d(*tb) * 
ts);
+last = FFMIN(last, AV_TS_MAX_STRING_SIZE - 1) - 1;
+for (; last && buf[last] == '0'; last--);
+for (; last && buf[last] != 'f' && (buf[last] < '0' || buf[0] > '9'); 
last--);
+buf[last + 1] = '\0';
+}
+return buf;
+}


As has already been said before: Simply using %.6f will discard
significant digits for small timestamps. E.g. 10^-7 will simply print
0.00, which will then be converted to "0" by your code. The old code
printed 1.


Admittedly we will lose precision < 10^-6 by using %.6f, but I don't 
think this will cause any real problems, so I'd rather just leave this as 
is. Or you prefer some special handling of small values? E.g. using %.9f 
or something?

Re: [FFmpeg-devel] [PATCH 3/3] Revert "avcodec/h264_mp4toannexb_bsf: fix missing PS before IDR frames"

On Thu, Mar 21, 2024 at 01:53:12AM +0800, Zhao Zhili wrote:
> 
> 
> > -Original Message-
> > From: ffmpeg-devel  On Behalf Of Michael 
> > Niedermayer
> > Sent: 2024年3月20日 21:02
> > To: FFmpeg development discussions and patches 
> > Subject: Re: [FFmpeg-devel] [PATCH 3/3] Revert 
> > "avcodec/h264_mp4toannexb_bsf: fix missing PS before IDR frames"
> > 
> > On Wed, Mar 20, 2024 at 02:41:05PM +0800, Zhao Zhili wrote:
> > >
> > >
> > > > On Mar 20, 2024, at 10:19, Michael Niedermayer  
> > > > wrote:
> > > >
> > > > This reverts commit d3aa0cd16f5e952bc346b7c74b4dcba95151a63a.
> > > >
> > > > Fixes: out of array write
> > > > Fixes: 
> > > > 64407/clusterfuzz-testcase-minimized-ffmpeg_BSF_H264_MP4TOANNEXB_fuzzer-4966763443650560
> > > >
> > > > The bsf code performs 2 iterations, the first counts how much space is 
> > > > needed
> > > > than allocates
> > > > and the 2nd pass copies into teh allocated space
> > > >
> > > > The reverted code reallocates sps/pps in the first pass in a data 
> > > > dependant way that leaves
> > > > the 2nd pass in a different state then the first
> > >
> > > Sorry for the break. How to access the fuzz report details?
> > 
> > ossfuzz made this one public already
> > https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=64407
> 
> I can't open the "Detailed Report" link. Does it provide asan details?

yes, posted them to you privately, i didnt realize that wasnt public while the 
testcase is

thx

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

Many things microsoft did are stupid, but not doing something just because
microsoft did it is even more stupid. If everything ms did were stupid they
would be bankrupt already.


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

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

Re: [FFmpeg-devel] [PATCH 2/2] avfilter/vf_scale2ref: switch to FFFrameSync

On Wed, Mar 20, 2024 at 03:23:53PM +0100, Niklas Haas wrote:
> On Tue, 19 Mar 2024 22:55:56 +0100 Michael Niedermayer 
>  wrote:
> > is it neccessary to drop compatibility to the old syntax ?
> 
> Only if we want to use framesync. If we don't care about synchronizing
> the streams, then we could drop FS and just use a custom activate
> function which forwards output status only to the *corresponding* input.

if the full bugfix cant be done in the same filter then i guess we need a 2nd
filter, maybe scale1ref

[...]

thx

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The smallest minority on earth is the individual. Those who deny 
individual rights cannot claim to be defenders of minorities. - Ayn Rand


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

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

Re: [FFmpeg-devel] [PATCH 1/2 v3] configure: make the C and C++ standard settable

On Wed, Mar 20, 2024 at 01:44:58PM -0300, James Almer wrote:
> While ensuring it's at least C11, the minimum supported version.
> Also, enforce C11 on the host compiler, same as we already do for C11 on the
> target compiler.
> 
> Signed-off-by: James Almer 
> ---
> Now with the new options added to CMDLINE_SET
> 
>  configure | 75 ---
>  1 file changed, 66 insertions(+), 9 deletions(-)

this and v2 seem working

thx

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

I have often repented speaking, but never of holding my tongue.
-- Xenocrates


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

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

Re: [FFmpeg-devel] [PATCH 1/4] avcodec/jpeg2000htdec: Check M_b / magp before using it in a shift

2024-03-20 Thread 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

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

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

[FFmpeg-devel] [PATCH] avfilter/af_volumedetect.c: Add 32bit float audio support

2024-03-20 Thread Yiğithan Yiğit



0001-avfilter-af_volumedetect.c-Add-32bit-float-audio-sup.patch
Description: Binary data
___
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

2024-03-20 Thread Paul B Mahol

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 
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".

Re: [FFmpeg-devel] [PATCH 4/4] avcodec/libx265: encode dovi RPUs

2024-03-20 Thread Jan Ekström

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 ?

Jan
___
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] sizeof(HEVCVPS)

Hi

why is sizeof(HEVCVPS) is 7463476 ?

If you think about this for a moment, a VPS in the bit stream is what, 5 bytes ?

Now iam not even talking about someone proving you a 10mb file with a million 
VPSs
7TB allocation, memsets memcpies, ...

But even with a totally normal file 7mb is easily bigger than the frame buffer
that wastes memory, it wastes cpu time, it wastes data cache

thx

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Frequently ignored answer#1 FFmpeg bugs should be sent to our bugtracker. User
questions about the command line tools should be sent to the ffmpeg-user ML.
And questions about how to use libav* should be sent to the libav-user ML.


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

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

Re: [FFmpeg-devel] [PATCH] avfilter/af_volumedetect.c: Add 32bit float audio support

2024-03-20 Thread Yiğithan Yiğit

> 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 
> 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.

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".

Re: [FFmpeg-devel] sizeof(HEVCVPS)

2024-03-20 Thread Lynne

Mar 20, 2024, 23:24 by mich...@niedermayer.cc:

> Hi
>
> why is sizeof(HEVCVPS) is 7463476 ?
>
> If you think about this for a moment, a VPS in the bit stream is what, 5 
> bytes ?
>
> Now iam not even talking about someone proving you a 10mb file with a million 
> VPSs
> 7TB allocation, memsets memcpies, ...
>
> But even with a totally normal file 7mb is easily bigger than the frame buffer
> that wastes memory, it wastes cpu time, it wastes data cache
>

As discussed on IRC, Vulkan ran into this.
The size of all HEVC structs (SPS, VPS, PPS) at their maximum array sizes is 
~120 Mb.
That's why there's a function in Vulkan to allocate them on demand.
___
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] avcodec/hevc_ps: fix setting HEVCHdrParams fields

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, 
&hdr->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, 
&hdr->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..88d6f617b

[FFmpeg-devel] [PATCH 2/2] avcodec/hevc_ps: use bitfields to slightly reduce the size of some structs

Signed-off-by: James Almer 
---
 libavcodec/hevc_ps.h | 190 +--
 1 file changed, 91 insertions(+), 99 deletions(-)

diff --git a/libavcodec/hevc_ps.h b/libavcodec/hevc_ps.h
index 88d6f617b5..9cdec9b6c1 100644
--- a/libavcodec/hevc_ps.h
+++ b/libavcodec/hevc_ps.h
@@ -48,10 +48,10 @@ typedef struct HEVCHdrFlagParams {
 
 typedef struct HEVCHdrParams {
 HEVCHdrFlagParams flags;
-uint8_t nal_hrd_parameters_present_flag;
-uint8_t vcl_hrd_parameters_present_flag;
-uint8_t sub_pic_hrd_params_present_flag;
-uint8_t sub_pic_cpb_params_in_pic_timing_sei_flag;
+uint8_t nal_hrd_parameters_present_flag : 1;
+uint8_t vcl_hrd_parameters_present_flag : 1;
+uint8_t sub_pic_hrd_params_present_flag : 1;
+uint8_t sub_pic_cpb_params_in_pic_timing_sei_flag : 1;
 
 uint8_t tick_divisor_minus2;
 uint8_t du_cpb_removal_delay_increment_length_minus1;
@@ -93,31 +93,28 @@ typedef struct HEVCWindow {
 
 typedef struct VUI {
 H2645VUI common;
-
-int neutra_chroma_indication_flag;
-
-int field_seq_flag;
-int frame_field_info_present_flag;
-
-int default_display_window_flag;
 HEVCWindow def_disp_win;
 
-int vui_timing_info_present_flag;
 uint32_t vui_num_units_in_tick;
 uint32_t vui_time_scale;
-int vui_poc_proportional_to_timing_flag;
 int vui_num_ticks_poc_diff_one_minus1;
-int vui_hrd_parameters_present_flag;
-
-int bitstream_restriction_flag;
-int tiles_fixed_structure_flag;
-int motion_vectors_over_pic_boundaries_flag;
-int restricted_ref_pic_lists_flag;
 int min_spatial_segmentation_idc;
 int max_bytes_per_pic_denom;
 int max_bits_per_min_cu_denom;
 int log2_max_mv_length_horizontal;
 int log2_max_mv_length_vertical;
+
+uint8_t neutra_chroma_indication_flag : 1;
+uint8_t field_seq_flag : 1;
+uint8_t frame_field_info_present_flag : 1;
+uint8_t default_display_window_flag : 1;
+uint8_t vui_timing_info_present_flag : 1;
+uint8_t vui_poc_proportional_to_timing_flag : 1;
+uint8_t vui_hrd_parameters_present_flag : 1;
+uint8_t bitstream_restriction_flag : 1;
+uint8_t tiles_fixed_structure_flag : 1;
+uint8_t motion_vectors_over_pic_boundaries_flag : 1;
+uint8_t restricted_ref_pic_lists_flag : 1;
 } VUI;
 
 typedef struct PTLCommon {
@@ -125,21 +122,21 @@ typedef struct PTLCommon {
 uint8_t tier_flag;
 uint8_t profile_idc;
 uint8_t profile_compatibility_flag[32];
-uint8_t progressive_source_flag;
-uint8_t interlaced_source_flag;
-uint8_t non_packed_constraint_flag;
-uint8_t frame_only_constraint_flag;
-uint8_t max_12bit_constraint_flag;
-uint8_t max_10bit_constraint_flag;
-uint8_t max_8bit_constraint_flag;
-uint8_t max_422chroma_constraint_flag;
-uint8_t max_420chroma_constraint_flag;
-uint8_t max_monochrome_constraint_flag;
-uint8_t intra_constraint_flag;
-uint8_t one_picture_only_constraint_flag;
-uint8_t lower_bit_rate_constraint_flag;
-uint8_t max_14bit_constraint_flag;
-uint8_t inbld_flag;
+uint8_t progressive_source_flag : 1;
+uint8_t interlaced_source_flag : 1;
+uint8_t non_packed_constraint_flag : 1;
+uint8_t frame_only_constraint_flag : 1;
+uint8_t max_12bit_constraint_flag : 1;
+uint8_t max_10bit_constraint_flag : 1;
+uint8_t max_8bit_constraint_flag : 1;
+uint8_t max_422chroma_constraint_flag : 1;
+uint8_t max_420chroma_constraint_flag : 1;
+uint8_t max_monochrome_constraint_flag : 1;
+uint8_t intra_constraint_flag : 1;
+uint8_t one_picture_only_constraint_flag : 1;
+uint8_t lower_bit_rate_constraint_flag : 1;
+uint8_t max_14bit_constraint_flag : 1;
+uint8_t inbld_flag : 1;
 uint8_t level_idc;
 } PTLCommon;
 
@@ -155,21 +152,22 @@ typedef struct HEVCVPS {
 unsigned int vps_id;
 HEVCHdrParams hdr[HEVC_MAX_LAYER_SETS];
 
-uint8_t vps_temporal_id_nesting_flag;
+uint8_t vps_temporal_id_nesting_flag : 1;
+uint8_t vps_sub_layer_ordering_info_present_flag : 1;
+uint8_t vps_timing_info_present_flag : 1;
+uint8_t vps_poc_proportional_to_timing_flag : 1;
 int vps_max_layers;
 int vps_max_sub_layers; ///< vps_max_temporal_layers_minus1 + 1
 
 PTL ptl;
-int vps_sub_layer_ordering_info_present_flag;
-unsigned int vps_max_dec_pic_buffering[HEVC_MAX_SUB_LAYERS];
-unsigned int vps_num_reorder_pics[HEVC_MAX_SUB_LAYERS];
+
+uint8_t vps_max_dec_pic_buffering[HEVC_MAX_SUB_LAYERS];
+uint8_t vps_num_reorder_pics[HEVC_MAX_SUB_LAYERS];
 unsigned int vps_max_latency_increase[HEVC_MAX_SUB_LAYERS];
 int vps_max_layer_id;
 int vps_num_layer_sets; ///< vps_num_layer_sets_minus1 + 1
-uint8_t vps_timing_info_present_flag;
 uint32_t vps_num_units_in_tick;
 uint32_t vps_time_scale;
-uint8_t vps_poc_proportional_to_timing_flag;
 int vps_num_ticks_poc_diff_one; ///< vps_num_ticks_poc_diff_one_minus1 + 1
 int vps_num_hrd_paramete

[FFmpeg-devel] [PATCH] avcodec/hevc_ps: allocate only the required HEVCHdrParams within a VPS

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(&vps->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, &vps->hdr[i],
+
+decode_hrd(gb, common_inf_present, hdr,
vps->vps_max_sub_layers);
 }
 }
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 = &vps->hdr[i];
+const HEVCHdrParams *src = vps->hdr[i];
 
 sls_hdr[i] = (StdVideoH265HrdParameters) {
 .flags = (StdVideoH265HrdFlags) {
-- 
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 2/2] avcodec/hevc_ps: use bitfields to slightly reduce the size of some structs


On 3/20/2024 8:17 PM, James Almer wrote:

Signed-off-by: James Almer 
---
  libavcodec/hevc_ps.h | 190 +--
  1 file changed, 91 insertions(+), 99 deletions(-)

diff --git a/libavcodec/hevc_ps.h b/libavcodec/hevc_ps.h
index 88d6f617b5..9cdec9b6c1 100644
--- a/libavcodec/hevc_ps.h
+++ b/libavcodec/hevc_ps.h
@@ -48,10 +48,10 @@ typedef struct HEVCHdrFlagParams {


This patch is not really worth applying after i came up with 
"avcodec/hevc_ps: allocate only the required HEVCHdrParams within a 
VPS", so i guess i'll withdraw it.

___
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] sizeof(HEVCVPS)


On 3/20/2024 7:23 PM, Michael Niedermayer wrote:

Hi

why is sizeof(HEVCVPS) is 7463476 ?

If you think about this for a moment, a VPS in the bit stream is what, 5 bytes ?

Now iam not even talking about someone proving you a 10mb file with a million 
VPSs
7TB allocation, memsets memcpies, ...

But even with a totally normal file 7mb is easily bigger than the frame buffer
that wastes memory, it wastes cpu time, it wastes data cache

thx


Posted a patch for this.
___
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/4] avcodec/mscc: move frame allocates to later

Fixes: Timeout
Fixes: 
66964/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_SRGC_fuzzer-5413170363564032

Found-by: continuous fuzzing process 
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer 
---
 libavcodec/mscc.c | 43 +--
 1 file changed, 21 insertions(+), 22 deletions(-)

diff --git a/libavcodec/mscc.c b/libavcodec/mscc.c
index d1d23e6751..1e9fd35f03 100644
--- a/libavcodec/mscc.c
+++ b/libavcodec/mscc.c
@@ -142,28 +142,6 @@ static int decode_frame(AVCodecContext *avctx, AVFrame 
*frame,
 if (avpkt->size < 3)
 return buf_size;
 
-if ((ret = ff_get_buffer(avctx, frame, 0)) < 0)
-return ret;
-
-if (avctx->pix_fmt == AV_PIX_FMT_PAL8) {
-size_t size;
-const uint8_t *pal = av_packet_get_side_data(avpkt, 
AV_PKT_DATA_PALETTE, &size);
-
-if (pal && size == AVPALETTE_SIZE) {
-#if FF_API_PALETTE_HAS_CHANGED
-FF_DISABLE_DEPRECATION_WARNINGS
-frame->palette_has_changed = 1;
-FF_ENABLE_DEPRECATION_WARNINGS
-#endif
-for (j = 0; j < 256; j++)
-s->pal[j] = 0xFF00 | AV_RL32(pal + j * 4);
-} else if (pal) {
-av_log(avctx, AV_LOG_ERROR,
-   "Palette size %"SIZE_SPECIFIER" is wrong\n", size);
-}
-memcpy(frame->data[1], s->pal, AVPALETTE_SIZE);
-}
-
 ret = inflateReset(zstream);
 if (ret != Z_OK) {
 av_log(avctx, AV_LOG_ERROR, "Inflate reset error: %d\n", ret);
@@ -191,6 +169,27 @@ inflate_error:
 av_log(avctx, AV_LOG_ERROR, "Inflate error: %d\n", ret);
 return AVERROR_UNKNOWN;
 }
+if ((ret = ff_get_buffer(avctx, frame, 0)) < 0)
+return ret;
+
+if (avctx->pix_fmt == AV_PIX_FMT_PAL8) {
+size_t size;
+const uint8_t *pal = av_packet_get_side_data(avpkt, 
AV_PKT_DATA_PALETTE, &size);
+
+if (pal && size == AVPALETTE_SIZE) {
+#if FF_API_PALETTE_HAS_CHANGED
+FF_DISABLE_DEPRECATION_WARNINGS
+frame->palette_has_changed = 1;
+FF_ENABLE_DEPRECATION_WARNINGS
+#endif
+for (j = 0; j < 256; j++)
+s->pal[j] = 0xFF00 | AV_RL32(pal + j * 4);
+} else if (pal) {
+av_log(avctx, AV_LOG_ERROR,
+   "Palette size %"SIZE_SPECIFIER" is wrong\n", size);
+}
+memcpy(frame->data[1], s->pal, AVPALETTE_SIZE);
+}
 
 bytestream2_init(&gb, s->decomp_buf, zstream->total_out);
 bytestream2_init_writer(&pb, s->uncomp_buf, s->uncomp_size);
-- 
2.17.1

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

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

[FFmpeg-devel] [PATCH 2/4] avformat/iamf_reader: return REDO on failure to read

Fixes: null pointer derference
Fixes: 
67007/clusterfuzz-testcase-minimized-ffmpeg_dem_IAMF_fuzzer-6522819204677632

Found-by: continuous fuzzing process 
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer 
---
 libavformat/iamf_reader.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/libavformat/iamf_reader.c b/libavformat/iamf_reader.c
index 42d20f1ae6..a06aa98cdb 100644
--- a/libavformat/iamf_reader.c
+++ b/libavformat/iamf_reader.c
@@ -26,6 +26,7 @@
 #include "libavcodec/packet.h"
 #include "avformat.h"
 #include "avio_internal.h"
+#include "demux.h"
 #include "iamf.h"
 #include "iamf_parse.h"
 #include "iamf_reader.h"
@@ -322,7 +323,7 @@ int ff_iamf_read_packet(AVFormatContext *s, 
IAMFDemuxContext *c,
 break;
 }
 
-return read;
+return FFERROR_REDO;
 }
 
 void ff_iamf_read_deinit(IAMFDemuxContext *c)
-- 
2.17.1

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

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

[FFmpeg-devel] [PATCH 3/4] avcodec/cbs_h266_syntax_template: Check tile_y

Fixes: out of array access
Fixes: 
67021/clusterfuzz-testcase-minimized-ffmpeg_DEMUXER_fuzzer-4883576579489792

Found-by: continuous fuzzing process 
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer 
---
 libavcodec/cbs_h266_syntax_template.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/libavcodec/cbs_h266_syntax_template.c 
b/libavcodec/cbs_h266_syntax_template.c
index 49fb12ba77..0aae9fdfd5 100644
--- a/libavcodec/cbs_h266_syntax_template.c
+++ b/libavcodec/cbs_h266_syntax_template.c
@@ -2072,6 +2072,8 @@ static int FUNC(pps) (CodedBitstreamContext *ctx, 
RWContext *rw,
 
 tile_x = tile_idx % current->num_tile_columns;
 tile_y = tile_idx / current->num_tile_columns;
+if (tile_y >= current->num_tile_rows)
+return AVERROR_INVALIDDATA;
 
 ctu_x = 0, ctu_y = 0;
 for (j = 0; j < tile_x; j++) {
-- 
2.17.1

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

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

[FFmpeg-devel] [PATCH 4/4] avformat/iamf: Check language_label

Fixes: null pointer dereference
Fixes: 
67023/clusterfuzz-testcase-minimized-ffmpeg_dem_IAMF_fuzzer-6011025237278720

Found-by: continuous fuzzing process 
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer 
---
 libavformat/iamf.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/libavformat/iamf.c b/libavformat/iamf.c
index 5de70dc082..f2c22ce3aa 100644
--- a/libavformat/iamf.c
+++ b/libavformat/iamf.c
@@ -89,9 +89,10 @@ void ff_iamf_free_mix_presentation(IAMFMixPresentation 
**pmix_presentation)
 if (!mix_presentation)
 return;
 
-for (int i = 0; i < mix_presentation->count_label; i++)
-av_free(mix_presentation->language_label[i]);
-av_free(mix_presentation->language_label);
+if (mix_presentation->language_label)
+for (int i = 0; i < mix_presentation->count_label; i++)
+av_free(mix_presentation->language_label[i]);
+av_freep(&mix_presentation->language_label);
 av_iamf_mix_presentation_free(&mix_presentation->mix);
 av_freep(pmix_presentation);
 }
-- 
2.17.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 4/4] avformat/iamf: Check language_label


On 3/20/2024 10:15 PM, Michael Niedermayer wrote:

Fixes: null pointer dereference
Fixes: 
67023/clusterfuzz-testcase-minimized-ffmpeg_dem_IAMF_fuzzer-6011025237278720

Found-by: continuous fuzzing process 
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer 
---
  libavformat/iamf.c | 7 ---
  1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/libavformat/iamf.c b/libavformat/iamf.c
index 5de70dc082..f2c22ce3aa 100644
--- a/libavformat/iamf.c
+++ b/libavformat/iamf.c
@@ -89,9 +89,10 @@ void ff_iamf_free_mix_presentation(IAMFMixPresentation 
**pmix_presentation)
  if (!mix_presentation)
  return;
  
-for (int i = 0; i < mix_presentation->count_label; i++)

-av_free(mix_presentation->language_label[i]);
-av_free(mix_presentation->language_label);
+if (mix_presentation->language_label)


If count_label is not 0, then language_label should be allocated.


+for (int i = 0; i < mix_presentation->count_label; i++)
+av_free(mix_presentation->language_label[i]);
+av_freep(&mix_presentation->language_label);
  av_iamf_mix_presentation_free(&mix_presentation->mix);
  av_freep(pmix_presentation);
  }


Can you test the following?


diff --git a/libavformat/iamf_parse.c b/libavformat/iamf_parse.c
index cb49cf0a57..e29c2c6b6c 100644
--- a/libavformat/iamf_parse.c
+++ b/libavformat/iamf_parse.c
@@ -822,6 +822,7 @@ static int mix_presentation_obu(void *s, IAMFContext *c, 
AVIOContext *pb, int le
 mix_presentation->language_label = av_calloc(mix_presentation->count_label,
  
sizeof(*mix_presentation->language_label));
 if (!mix_presentation->language_label) {
+mix_presentation->count_label = 0;
 ret = AVERROR(ENOMEM);
 goto fail;
 }


___
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/4] avformat/iamf_reader: return REDO on failure to read


On 3/20/2024 10:15 PM, Michael Niedermayer wrote:

Fixes: null pointer derference
Fixes: 
67007/clusterfuzz-testcase-minimized-ffmpeg_dem_IAMF_fuzzer-6522819204677632

Found-by: continuous fuzzing process 
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer 
---
  libavformat/iamf_reader.c | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/libavformat/iamf_reader.c b/libavformat/iamf_reader.c
index 42d20f1ae6..a06aa98cdb 100644
--- a/libavformat/iamf_reader.c
+++ b/libavformat/iamf_reader.c
@@ -26,6 +26,7 @@
  #include "libavcodec/packet.h"
  #include "avformat.h"
  #include "avio_internal.h"
+#include "demux.h"
  #include "iamf.h"
  #include "iamf_parse.h"
  #include "iamf_reader.h"
@@ -322,7 +323,7 @@ int ff_iamf_read_packet(AVFormatContext *s, 
IAMFDemuxContext *c,
  break;
  }
  
-return read;

+return FFERROR_REDO;


Where is the null pointer dereference happening? I don't particularly 
like this approach because ff_iamf_read_packet() is also called by the 
mov demuxer.



  }
  
  void ff_iamf_read_deinit(IAMFDemuxContext *c)


Does the following also help?


diff --git a/libavformat/iamf_reader.c b/libavformat/iamf_reader.c
index 42d20f1ae6..4e79691a03 100644
--- a/libavformat/iamf_reader.c
+++ b/libavformat/iamf_reader.c
@@ -311,8 +311,7 @@ int ff_iamf_read_packet(AVFormatContext *s, 
IAMFDemuxContext *c,
 } else {
 int64_t offset = avio_skip(pb, obu_size);
 if (offset < 0) {
-ret = offset;
-break;
+return offset;
 }
 }
 max_size -= len;


Setting ret there and breaking the loop was wrong, as the scope of ret 
doesn't reach outside loop.

___
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] Changelog: Add libtorch

2024-03-20 Thread wenbin . chen-at-intel . com

From: Wenbin Chen 

Signed-off-by: Wenbin Chen 
---
 Changelog | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Changelog b/Changelog
index e3ca52430c..4af55ff537 100644
--- a/Changelog
+++ b/Changelog
@@ -35,6 +35,7 @@ version :
 - AEA muxer
 - ffmpeg CLI loopback decoders
 - Support PacketTypeMetadata of PacketType in enhanced flv format
+- dnn filter libtorch backend
 
 
 version 6.1:
-- 
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".

Re: [FFmpeg-devel] [PATCH] Changelog: Add libtorch

2024-03-20 Thread Chen, Wenbin

> On date Wednesday 2024-03-20 16:01:36 +0800, wenbin.chen-at-
> intel@ffmpeg.org wrote:
> > From: Wenbin Chen 
> >
> > Signed-off-by: Wenbin Chen 
> > ---
> >  Changelog | 1 +
> >  1 file changed, 1 insertion(+)
> >
> > diff --git a/Changelog b/Changelog
> > index e3ca52430c..d0c41887f3 100644
> > --- a/Changelog
> > +++ b/Changelog
> > @@ -35,6 +35,7 @@ version :
> >  - AEA muxer
> >  - ffmpeg CLI loopback decoders
> 
> >  - Support PacketTypeMetadata of PacketType in enhanced flv format
> 
> > +- Support libtorch as DNN backend
> 
> missing context, my take:
> libtorch backend in dnn filter
> 
> or:
> dnn filter libtorch backend
> 
> usually there is no capitalization and no verb in the items, but a
> description of the introduced feature

I update it in the new patch.

Thanks
Wenbin

> ___
> 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 2/4] avformat/iamf_reader: return REDO on failure to read

On Wed, Mar 20, 2024 at 11:22:11PM -0300, James Almer wrote:
> On 3/20/2024 10:15 PM, Michael Niedermayer wrote:
> > Fixes: null pointer derference
> > Fixes: 
> > 67007/clusterfuzz-testcase-minimized-ffmpeg_dem_IAMF_fuzzer-6522819204677632
> > 
> > Found-by: continuous fuzzing process 
> > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> > Signed-off-by: Michael Niedermayer 
> > ---
> >   libavformat/iamf_reader.c | 3 ++-
> >   1 file changed, 2 insertions(+), 1 deletion(-)
> > 
> > diff --git a/libavformat/iamf_reader.c b/libavformat/iamf_reader.c
> > index 42d20f1ae6..a06aa98cdb 100644
> > --- a/libavformat/iamf_reader.c
> > +++ b/libavformat/iamf_reader.c
> > @@ -26,6 +26,7 @@
> >   #include "libavcodec/packet.h"
> >   #include "avformat.h"
> >   #include "avio_internal.h"
> > +#include "demux.h"
> >   #include "iamf.h"
> >   #include "iamf_parse.h"
> >   #include "iamf_reader.h"
> > @@ -322,7 +323,7 @@ int ff_iamf_read_packet(AVFormatContext *s, 
> > IAMFDemuxContext *c,
> >   break;
> >   }
> > -return read;
> > +return FFERROR_REDO;
> 
> Where is the null pointer dereference happening? I don't particularly like
> this approach because ff_iamf_read_packet() is also called by the mov
> demuxer.

==8458==ERROR: AddressSanitizer: SEGV on unknown address 0x (pc 
0x00703a8b bp 0x7ffc691161f0 sp 0x7ffc69116000 T0)
==8458==The signal is caused by a READ memory access.
==8458==Hint: address points to the zero page.
#0 0x703a8a in ff_read_packet ffmpeg/libavformat/demux.c:671:15
#1 0x7074cc in read_frame_internal ffmpeg/libavformat/demux.c:1346:15
#2 0x704a07 in av_read_frame ffmpeg/libavformat/demux.c:1550:17
#3 0x4c844f in LLVMFuzzerTestOneInput 
ffmpeg/tools/target_dem_fuzzer.c:211:15


SCARINESS: 10 (null-deref)
#0 0x60b7cc in ff_read_packet /src/ffmpeg/libavformat/demux.c:683:15
#1 0x60cbcb in read_frame_internal /src/ffmpeg/libavformat/demux.c:1358:15
#2 0x60c59b in av_read_frame /src/ffmpeg/libavformat/demux.c:1569:17
#3 0x57808a in LLVMFuzzerTestOneInput 
/src/ffmpeg/tools/target_dem_fuzzer.c:211:15
#4 0x449183 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, 
unsigned long) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:611:15
#5 0x4348e2 in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*, unsigned 
long) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:324:6
#6 0x43a18c in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char 
const*, unsigned long)) 
/src/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:860:9
#7 0x4636c2 in main 
/src/llvm-project/compiler-rt/lib/fuzzer/FuzzerMain.cpp:20:10
#8 0x7854642cc082 in __libc_start_main 
/build/glibc-SzIz7B/glibc-2.31/csu/libc-start.c:308:16
#9 0x42aaad in _start

Either way the iamf demuxer returns no packet but the caller believes it
returns a packet. WHen that gets used things crash


> 
> >   }
> >   void ff_iamf_read_deinit(IAMFDemuxContext *c)
> 
> Does the following also help?
> 
> > diff --git a/libavformat/iamf_reader.c b/libavformat/iamf_reader.c
> > index 42d20f1ae6..4e79691a03 100644
> > --- a/libavformat/iamf_reader.c
> > +++ b/libavformat/iamf_reader.c
> > @@ -311,8 +311,7 @@ int ff_iamf_read_packet(AVFormatContext *s, 
> > IAMFDemuxContext *c,
> >  } else {
> >  int64_t offset = avio_skip(pb, obu_size);
> >  if (offset < 0) {
> > -ret = offset;
> > -break;
> > +return offset;
> >  }
> >  }
> >  max_size -= len;

yes, this seems to fix it too and is better

thx

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

Any man who breaks a law that conscience tells him is unjust and willingly 
accepts the penalty by staying in jail in order to arouse the conscience of 
the community on the injustice of the law is at that moment expressing the 
very highest respect for law. - Martin Luther King Jr


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

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

[FFmpeg-devel] [PATCH v7 0/5] RCWT Closed Captions demuxer (meta)

Since v7:
* Demuxer is simplified, reduced to 92 LOC
* Documentation feedback addressed

Signed-off-by: Marth64 
-- 
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 v7 1/5] avformat/subtitles: extend ff_subtitles_queue_insert() to support empty events

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;
 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);
 }
 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
  * @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
-- 
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 v7 2/5] avformat/rcwtdec: add RCWT Closed Captions demuxer

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 Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+/*
+ * RCWT (Raw Captions With Time) is a format native to ccextractor, a commonl

[FFmpeg-devel] [PATCH v7 3/5] avformat/rcwtenc: remove repeated documentation

The high level summary of RCWT can be delegated doc/muxers, which
makes it easier to maintain and more consistent with the documentation
of the demuxer.

Signed-off-by: Marth64 
---
 libavformat/rcwtenc.c | 5 -
 1 file changed, 5 deletions(-)

diff --git a/libavformat/rcwtenc.c b/libavformat/rcwtenc.c
index ed72de81ef..a1a8c06533 100644
--- a/libavformat/rcwtenc.c
+++ b/libavformat/rcwtenc.c
@@ -21,11 +21,6 @@
 /*
  * 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.
- * It can be used to archive the original, raw CC bitstream and to produce
- * a source file for later CC processing or conversion. As a result,
- * it also allows for interopability with ccextractor for processing CC data
- * extracted via ffmpeg. The format is simple to parse and can be used
- * to retain all lines and variants of CC.
  *
  * This muxer implements the specification as of March 2024, which has
  * been stable and unchanged since April 2014.
-- 
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 v7 4/5] doc/muxers: refresh the RCWT muxer's doc to be consistent with the demuxer

Signed-off-by: Marth64 
---
 doc/muxers.texi | 29 +++--
 1 file changed, 19 insertions(+), 10 deletions(-)

diff --git a/doc/muxers.texi b/doc/muxers.texi
index d9dd72e613..0695a317d4 100644
--- a/doc/muxers.texi
+++ b/doc/muxers.texi
@@ -2987,19 +2987,18 @@ ogg files can be safely chained.
 
 @end table
 
-@anchor{rcwt}
+@anchor{rcwtenc}
 @section rcwt
 
-Raw Captions With Time (RCWT) is a format native to ccextractor, a commonly
-used open source tool for processing 608/708 closed caption (CC) sources.
-It can be used to archive the original, raw CC bitstream and to produce
-a source file for later CC processing or conversion. As a result,
-it also allows for interopability with ccextractor for processing CC data
-extracted via ffmpeg. The format is simple to parse and can be used
-to retain all lines and variants of CC.
+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.
+It can be used to archive the original extracted CC bitstream and to produce
+a source file for later processing or conversion. The format allows
+for interoperability between ccextractor and FFmpeg, is simple to parse,
+and can be used to create a backup of the CC presentation.
 
-This muxer implements the specification as of 2024-01-05, which has
-been stable and unchanged for 10 years as of this writing.
+This muxer implements the specification as of March 2024, which has
+been stable and unchanged since April 2014.
 
 This muxer will have some nuances from the way that ccextractor muxes RCWT.
 No compatibility issues when processing the output with ccextractor
@@ -3009,6 +3008,16 @@ and outputs will not be a bit-exact match.
 A free specification of RCWT can be found here:
 
@url{https://github.com/CCExtractor/ccextractor/blob/master/docs/BINARY_FILE_FORMAT.TXT}
 
+@subsection Examples
+
+@itemize
+@item
+Extract Closed Captions to RCWT using lavfi:
+@example
+ffmpeg -f lavfi -i "movie=INPUT.mkv[out+subcc]" -map 0:s:0 -c:s copy 
CC.rcwt.bin
+@end example
+@end itemize
+
 @anchor{segment}
 @section segment, stream_segment, ssegment
 
-- 
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 v7 5/5] doc/indevs: update CC extraction example to use RCWT muxer

Signed-off-by: Marth64 
---
 doc/indevs.texi | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/doc/indevs.texi b/doc/indevs.texi
index d1b2bacf8b..fc14737181 100644
--- a/doc/indevs.texi
+++ b/doc/indevs.texi
@@ -1069,9 +1069,9 @@ ffplay -f lavfi 
"movie=test.avi[out0];amovie=test.wav[out1]"
 @end example
 
 @item
-Dump decoded frames to images and closed captions to a file (experimental):
+Dump decoded frames to images and Closed Captions to an RCWT backup:
 @example
-ffmpeg -f lavfi -i "movie=test.ts[out0+subcc]" -map v frame%08d.png -map s -c 
copy -f rawvideo subcc.bin
+ffmpeg -f lavfi -i "movie=test.ts[out0+subcc]" -map v frame%08d.png -map s -c 
copy subcc.bin
 @end example
 
 @end itemize
-- 
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".

Re: [FFmpeg-devel] [PATCH 4/4] avformat/iamf: Check language_label

On Wed, Mar 20, 2024 at 11:17:09PM -0300, James Almer wrote:
> On 3/20/2024 10:15 PM, Michael Niedermayer wrote:
> > Fixes: null pointer dereference
> > Fixes: 
> > 67023/clusterfuzz-testcase-minimized-ffmpeg_dem_IAMF_fuzzer-6011025237278720
> > 
> > Found-by: continuous fuzzing process 
> > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> > Signed-off-by: Michael Niedermayer 
> > ---
> >   libavformat/iamf.c | 7 ---
> >   1 file changed, 4 insertions(+), 3 deletions(-)
> > 
> > diff --git a/libavformat/iamf.c b/libavformat/iamf.c
> > index 5de70dc082..f2c22ce3aa 100644
> > --- a/libavformat/iamf.c
> > +++ b/libavformat/iamf.c
> > @@ -89,9 +89,10 @@ void ff_iamf_free_mix_presentation(IAMFMixPresentation 
> > **pmix_presentation)
> >   if (!mix_presentation)
> >   return;
> > -for (int i = 0; i < mix_presentation->count_label; i++)
> > -av_free(mix_presentation->language_label[i]);
> > -av_free(mix_presentation->language_label);
> > +if (mix_presentation->language_label)
> 
> If count_label is not 0, then language_label should be allocated.
> 
> > +for (int i = 0; i < mix_presentation->count_label; i++)
> > +av_free(mix_presentation->language_label[i]);
> > +av_freep(&mix_presentation->language_label);
> >   av_iamf_mix_presentation_free(&mix_presentation->mix);
> >   av_freep(pmix_presentation);
> >   }
> 
> Can you test the following?
> 
> > diff --git a/libavformat/iamf_parse.c b/libavformat/iamf_parse.c
> > index cb49cf0a57..e29c2c6b6c 100644
> > --- a/libavformat/iamf_parse.c
> > +++ b/libavformat/iamf_parse.c
> > @@ -822,6 +822,7 @@ static int mix_presentation_obu(void *s, IAMFContext 
> > *c, AVIOContext *pb, int le
> >  mix_presentation->language_label = 
> > av_calloc(mix_presentation->count_label,
> >   
> > sizeof(*mix_presentation->language_label));
> >  if (!mix_presentation->language_label) {
> > +mix_presentation->count_label = 0;
> >  ret = AVERROR(ENOMEM);
> >  goto fail;
> >  }

that works too, i think pointers should be set to NULL on deallocation though

thx

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

Many things microsoft did are stupid, but not doing something just because
microsoft did it is even more stupid. If everything ms did were stupid they
would be bankrupt already.


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] avcodec/hevc_ps: allocate only the required HEVCHdrParams within a VPS

On Wed, Mar 20, 2024 at 08:35:25PM -0300, James Almer wrote:
> 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(-)

the 3 patches fix the timeout from (didnt test only the 3rd as it doesnt apply 
automatcially alone)
64033/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_HEVC_fuzzer-5332101272305664

feel free to apply

thx


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

Good people do not need laws to tell them to act responsibly, while bad
people will find a way around the laws. -- Plato


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

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

Re: [FFmpeg-devel] [PATCH v7 1/5] avformat/subtitles: extend ff_subtitles_queue_insert() to support empty events

This is in response to the last paragraph of feedback in
https://ffmpeg.org//pipermail/ffmpeg-devel/2024-March/323858.html
___
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 v8] avformat/rcwtdec: add RCWT Closed Captions demuxer