Re: [FFmpeg-devel] STF RaptorQ
On Fri, May 23, 2025 at 5:58 AM Michael Niedermayer wrote: > Theres also the human element, where people are not machienes that can > be placed and told things arbitrary. RaptorQ is "cool", ARQ is boring > > Some people enjoy working on "cool" things, dont tell them to work on > boring things please. Its bad for them, and likely bad for the results. > > If you find RIST/SRT important, you should work on it, or fund someone > to do it or to submit a project idea to STF/GsoC/... and work on it > with their funding ... > > Also IMO if you have someone who wants to do a project that moves FFmpeg > forward, be supportive of the effort and try to find a way to make it happen > be that inside or outside STF. > Arguing against efforts to move to teh cutting edge of technology > will do only one thing and thats havig competitors take the space > and FFmpeg fall behind To be clear, I have no desire to discourage developers from working on anything that interests them. I've spoken to Lynne about her txproto work, and while I can't offer any guidance due to the NDA with my employer, I admire her initiative and really hope that research turns into something useful. This discussion though really started about what the scope of work is that can be funded by STF. My understanding is that STF intends for the funds to be used for maintenance and work that contributes toward project sustainability. At least for me personally, I am not confident I could argue that the RaptorQ work proposed falls within that definition. Devin -- Devin Heitmueller, Senior Software Engineer LTN Global Communications o: +1 (301) 363-1001 w: https://ltnglobal.com e: devin.heitmuel...@ltnglobal.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] STF RaptorQ
On Fri, May 23, 2025 at 12:33 PM Michael Niedermayer wrote: > > Hi Kieran > > On Fri, May 23, 2025 at 08:51:43AM +0100, Kieran Kunhya via ffmpeg-devel > wrote: > [...] > > I appreciate the way the 2024 organisers ran STF was not exactly stellar > > It seems every mail you post is an attack on FFmpeg or the FFmpeg Team > And its alot of different people you target. And often people who > have done good and valuable work > > Seriously, I could easily talk negatively about you in every mail i > write too but i dont, i try to be polite and positive. > > As an example i could have instead replied with a tone matching yours: > (below is a (true) example of communication in the same tone as yours > that i avoid) > > "I appreciated the stellar service you provided by providing and > hosting a trac server for FFmpeg. It had only one broken cpu core. > You only once decided to use the FFmpeg server to test some random > audio hardware. > > Its sad that our users need reliable service" Since you decided to slander me I looked at the logs. I travelled two hours each way to the office on Saturday July 4th 2015 and stayed until 8pm on your request setting up a server as an emergency. This server was in the same room as two FFmpeg committers and a third works for the same company remotely. These three contributors are known physically to the community and have met the community many times. Many other FFmpeg developers also visited our office. This is in contrast to the current hosting situation where nobody has visited, nobody knows who has access. I have no record of us ever testing an audio device in it. If we did it was a real emergency. Kieran ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] STF RaptorQ
Hello Michael, On Fri, May 23, 2025 at 5:45 AM Michael Niedermayer wrote: > On Thu, May 22, 2025 at 07:55:40PM -0400, Devin Heitmueller wrote: > > On Thu, May 22, 2025 at 7:42 PM Kieran Kunhya via ffmpeg-devel > > wrote: > > > I wanted to put on the record that adding RaptorQ to FFmpeg isn't > > > maintenance of FFmpeg. > > i agree adding RaptorQ itself is probably not maintenance Ok, so that much everybody seems to agree on. Great. > > > It's adding an obscure FEC protocol to FFmpeg, > > tornado and raptor codes are not obscure. > and FFmpeg supports hundreads of much more obscure things Sure, no disagreement there. While I've personally never used any of the codecs that support video games from the 1990's, I don't really have any problem with them being in ffmpeg. That said, in my opinion, I doubt STF would really think it's a good use of their funds to add support for new codecs for such games. > > I'm not sure I've seen any commercial gear that does RaptorQ for FEC, > > so it's not clear what the use cases are if the goal is > > interoperability. > > its IMHO for communication between tools that on both sides > use our software > > If no commercial gear uses a reliable FEC system all teh better > for us Wow, that's quite a leap to suggest that because there aren't open standards using RaptorQ that there isn't commercial video transmission gear out there that doesn't do a good job with FEC. > > If somebody really wants to be paid to work on > > reliable transport protocols, the time would be better spent improving > > the RIST or SRT integration, which is where most of the industry is > > putting their energy. > > FEC is supperior to ARQ > for ARQ, each receiver needs to request the lost packet > while for FEC the sender just needs to know or guess how many packets > where lost. > 1. FEC is lower latency > 2. FEC does not suffer from "oops the retrasmit was lost too" > 3. if you have 3 receivers one lost packet 5 one packet 8 and one packet 0 >with ARQ you need to send 3 individual packets with FEC you CAN broadcast >the same 1 packet to all 3 receivers to recover them. This is largely an academic discussion that I could argue either side of, depending on the intended use case. There are tradeoffs to both approaches, and which one is most appropriate depends on how it's being used. > Also FEC is VERY widely used, just not where you are looking. > from compact disks, to phone networks to inter planetary communication > since over 50 years its the standard, voyager in 1970 used FEC already. Please tell me that you're not seriously trying to explain to me that FEC is widely used and has been around for decades to solve lots of real-world problems. It would be difficult for me to not read that with a very condescending tone. > > I agree with Kieran that this seems to largely be outside the STF > > objectives (i.e. sustainability for open source projects). > > A new implementation of RIST, SRT, Raptor and so on may fall outside > but redesigning the protocol layer in FFmpeg would perfectly fit inside > "sustainability for open source projects" > When you want A and B and both are connected, you ask for the funding > to be for the side that fits inside the guidelines > So this STF project could be changed to center on maintaince of the > protocol layer instead of a RaptorQ/SRT/RIST implementation i think. I'm certainly not suggesting anybody implement a new version of RIST or SRT (and on a personal note I give Kieran an enormous amount of credit for building his own SRT implementation). But yeah, I think most people who have looked closely at the ffmpeg protocol layer acknowledge it could be improved, and that seems like the thing that someone could easily convince STF of. Devin -- Devin Heitmueller, Senior Software Engineer LTN Global Communications o: +1 (301) 363-1001 w: https://ltnglobal.com e: devin.heitmuel...@ltnglobal.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] STF RaptorQ
On Fri, May 23, 2025 at 3:50 PM Devin Heitmueller wrote: > > Hello Michael, > > On Fri, May 23, 2025 at 5:45 AM Michael Niedermayer > wrote: > > On Thu, May 22, 2025 at 07:55:40PM -0400, Devin Heitmueller wrote: > > > On Thu, May 22, 2025 at 7:42 PM Kieran Kunhya via ffmpeg-devel > > > wrote: > > > > I wanted to put on the record that adding RaptorQ to FFmpeg isn't > > > > maintenance of FFmpeg. > > > > i agree adding RaptorQ itself is probably not maintenance > > Ok, so that much everybody seems to agree on. Great. > > > > > It's adding an obscure FEC protocol to FFmpeg, > > > > tornado and raptor codes are not obscure. > > and FFmpeg supports hundreads of much more obscure things > > Sure, no disagreement there. While I've personally never used any of > the codecs that support video games from the 1990's, I don't really > have any problem with them being in ffmpeg. That said, in my opinion, > I doubt STF would really think it's a good use of their funds to add > support for new codecs for such games. > > > > I'm not sure I've seen any commercial gear that does RaptorQ for FEC, > > > so it's not clear what the use cases are if the goal is > > > interoperability. > > > > its IMHO for communication between tools that on both sides > > use our software > > > > If no commercial gear uses a reliable FEC system all teh better > > for us > > Wow, that's quite a leap to suggest that because there aren't open > standards using RaptorQ that there isn't commercial video transmission > gear out there that doesn't do a good job with FEC. > > > > If somebody really wants to be paid to work on > > > reliable transport protocols, the time would be better spent improving > > > the RIST or SRT integration, which is where most of the industry is > > > putting their energy. > > > > FEC is supperior to ARQ > > for ARQ, each receiver needs to request the lost packet > > while for FEC the sender just needs to know or guess how many packets > > where lost. > > 1. FEC is lower latency > > 2. FEC does not suffer from "oops the retrasmit was lost too" > > 3. if you have 3 receivers one lost packet 5 one packet 8 and one packet 0 > >with ARQ you need to send 3 individual packets with FEC you CAN broadcast > >the same 1 packet to all 3 receivers to recover them. > > This is largely an academic discussion that I could argue either side > of, depending on the intended use case. There are tradeoffs to both > approaches, and which one is most appropriate depends on how it's > being used. > > > Also FEC is VERY widely used, just not where you are looking. > > from compact disks, to phone networks to inter planetary communication > > since over 50 years its the standard, voyager in 1970 used FEC already. > > Please tell me that you're not seriously trying to explain to me that > FEC is widely used and has been around for decades to solve lots of > real-world problems. It would be difficult for me to not read that > with a very condescending tone. Michael doesn't understand the difference between block FEC and packet FEC so he's not being condescending. Kieran ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] STF RaptorQ
Hi Kieran On Fri, May 23, 2025 at 01:13:05PM +0100, Kieran Kunhya via ffmpeg-devel wrote: > On Fri, 23 May 2025, 12:33 Michael Niedermayer, > wrote: > > > Hi Kieran > > > > On Fri, May 23, 2025 at 08:51:43AM +0100, Kieran Kunhya via ffmpeg-devel > > wrote: > > [...] > > > I appreciate the way the 2024 organisers ran STF was not exactly stellar > > > > It seems every mail you post is an attack on FFmpeg or the FFmpeg Team > > And its alot of different people you target. And often people who > > have done good and valuable work > > > > STF was you and Thilo. There where several more people working on STF. If you want to spread defamation against me and thilo, at least exclude the other people > Thilo doesn't exactly have the best reputation in > this project. There was a systematic defamation campaign against thilo (and me) The people doing that, themselfs even publically called it "this may be slander" https://ffmpeg.org/pipermail/ffmpeg-devel/2024-November/336263.html Thilo as a result of all this stoped posting to ffmpeg-devel and also no longer works at fflabs. [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Awnsering whenever a program halts or runs forever is On a turing machine, in general impossible (turings halting problem). On any real computer, always possible as a real computer has a finite number of states N, and will either halt in less than N cycles or never halt. 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] doc: use av_dict_iterate in documentation example
---
libavformat/avformat.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavformat/avformat.h b/libavformat/avformat.h
index 2034d2aecc..feef317840 100644
--- a/libavformat/avformat.h
+++ b/libavformat/avformat.h
@@ -146,8 +146,8 @@
* consumed). The calling program can handle such unrecognized options as it
* wishes, e.g.
* @code
- * AVDictionaryEntry *e;
- * if (e = av_dict_get(options, "", NULL, AV_DICT_IGNORE_SUFFIX)) {
+ * const AVDictionaryEntry *e;
+ * if ((e = av_dict_iterate(options, NULL))) {
* fprintf(stderr, "Option %s not recognized by the demuxer.\n", e->key);
* abort();
* }
--
2.39.5 (Apple Git-154)
___
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] ffv1enc_vulkan: fix array overflow
Fix a crash (some GCC) or silent quit (Microsoft compiler) after
"[PATCH 06/16] ffv1enc_vulkan: switch to 2-line cache, unify prediction
code"
https://ffmpeg.org/pipermail/ffmpeg-devel/2025-May/343502.htmlFrom: Maxime Gervais
Date: Fri, 23 May 2025 16:20:41 +0200
Subject: [PATCH] ffv1enc_vulkan: fix array overflow
---
libavcodec/ffv1enc_vulkan.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/libavcodec/ffv1enc_vulkan.c b/libavcodec/ffv1enc_vulkan.c
index d9e12f5fae..15aaddac98 100644
--- a/libavcodec/ffv1enc_vulkan.c
+++ b/libavcodec/ffv1enc_vulkan.c
@@ -1358,6 +1358,8 @@ static int init_encode_shader(AVCodecContext *avctx,
FFVkSPIRVCompiler *spv)
.mem_quali = "writeonly",
.buf_content = "uint64_t slice_results[2048];",
},
+{ /* place holder for desc_set[3] */
+},
};
if (fv->is_rgb) {
AVHWFramesContext *intermediate_frames_ctx;
___
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] Percent-encode URL paths in HLS playlists
This commit closes trac ticket 10679.
Signed-off-by: Timothy Allen
---
libavformat/hls.c | 9 +
libavformat/url.c | 35 +++
libavformat/url.h | 9 +
3 files changed, 53 insertions(+)
diff --git a/libavformat/hls.c b/libavformat/hls.c
index c7b655c83c..49436d8184 100644
--- a/libavformat/hls.c
+++ b/libavformat/hls.c
@@ -1021,6 +1021,15 @@ static int parse_playlist(HLSContext *c, const char *url,
seg->key = NULL;
}
+ff_percent_encode_url(tmp_str, sizeof(tmp_str), line);
+if (!tmp_str[0]) {
+ret = AVERROR_INVALIDDATA;
+if (seg->key)
+av_free(seg->key);
+av_free(seg);
+goto fail;
+}
+strcpy(line, av_strdup(tmp_str));
ff_make_absolute_url(tmp_str, sizeof(tmp_str), url, line);
if (!tmp_str[0]) {
ret = AVERROR_INVALIDDATA;
diff --git a/libavformat/url.c b/libavformat/url.c
index d5dd6a4666..69d68d4248 100644
--- a/libavformat/url.c
+++ b/libavformat/url.c
@@ -324,6 +324,41 @@ int ff_make_absolute_url(char *buf, int size, const char
*base,
return ff_make_absolute_url2(buf, size, base, rel, HAVE_DOS_PATHS);
}
+int ff_percent_encode_url(char *buf, int size, const char *url)
+{
+const char *hex = "0123456789abcdef";
+
+av_assert0(url);
+
+int p = 0;
+int len = strlen(url);
+for (int i = 0; i < len; i++) {
+if (i + 1 < len && ':' == url[i] && '/' == url[i+1])
+buf[p++] = url[i];
+else if (('a' <= url[i] && url[i] <= 'z')
+ || ('A' <= url[i] && url[i] <= 'Z')
+ || ('0' <= url[i] && url[i] <= '9')
+ || '/' == url[i] || '.' == url[i] || '~' == url[i]
+ || '-' == url[i] || '_' == url[i] || '+' == url[i]
+ || '?' == url[i] || '=' == url[i] || '&' == url[i]
+ || '#' == url[i])
+{
+buf[p++] = url[i];
+} else if (' ' == url[i])
+{
+buf[p++] = '+';
+} else
+{
+buf[p++] = '%';
+buf[p++] = hex[url[i] >> 4];
+buf[p++] = hex[url[i] & 15];
+}
+}
+buf[p] = '\0';
+
+return 0;
+}
+
AVIODirEntry *ff_alloc_dir_entry(void)
{
AVIODirEntry *entry = av_mallocz(sizeof(AVIODirEntry));
diff --git a/libavformat/url.h b/libavformat/url.h
index 0784d77b64..85f94f06ce 100644
--- a/libavformat/url.h
+++ b/libavformat/url.h
@@ -331,6 +331,15 @@ int ff_make_absolute_url2(char *buf, int size, const char
*base,
int ff_make_absolute_url(char *buf, int size, const char *base,
const char *rel);
+/**
+ * Percent-encode a URL, to avoid it being incorrectly parsed.
+ *
+ * @param buf the buffer where output absolute url is written
+ * @param size the size of buf
+ * @param url the url to encode
+ */
+int ff_percent_encode_url(char *buf, int size, const char *url);
+
/**
* Allocate directory entry with default values.
*
--
2.43.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] STF RaptorQ
Hello Lynne, On Thu, May 22, 2025 at 11:48 PM Lynne wrote: > > I see the task on the TRAC page for STF 2025, and while intellectually > > interesting to a nerd like me who does lots of work with reliable > > protocols, I'm not confident this particular protocol makes much sense > > to work on, especially for 24,000 EUR. > > It's not a protocol. Yes, I am aware of the difference between an algorithm and a protocol, thanks. My (perhaps incorrect) assumption was that you also intended to implement the RaptorQ over RTP protocol spec (RFC 6682), since algorithms themselves aren't very useful without some form of working implementation. If your intent is to implement just the algorithm without any protocol that demonstrates it, then my concerns are even greater regarding whether this is a good use of STF funds. > > I'm not sure I've seen any commercial gear that does RaptorQ for FEC, > > so it's not clear what the use cases are if the goal is > > interoperability. If somebody really wants to be paid to work on > > reliable transport protocols, the time would be better spent improving > > the RIST or SRT integration, which is where most of the industry is > > putting their energy. > > Again, it's not a protocol. It's an FEC algorithm. No current mainstream > protocol specifies using it. It will take decades, at least, and it > definitely cannot fit into existing protocols. > > Custom closed-source video transmission protocols are using it. > But, I do believe it's the future for open-source protocols too. > > I agree with Kieran that this seems to largely be outside the STF > > objectives (i.e. sustainability for open source projects).Like I mentioned, > > I believe the STF is not maintenance-only, or so I gather. Yeah, I suspect much of this comes down to a discussion on what STF expects/requires funds to be used for. Devin -- Devin Heitmueller, Senior Software Engineer LTN Global Communications o: +1 (301) 363-1001 w: https://ltnglobal.com e: devin.heitmuel...@ltnglobal.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] STF RaptorQ
Hi Devin On Fri, May 23, 2025 at 10:50:32AM -0400, Devin Heitmueller wrote: > Hello Michael, > > On Fri, May 23, 2025 at 5:45 AM Michael Niedermayer > wrote: > > On Thu, May 22, 2025 at 07:55:40PM -0400, Devin Heitmueller wrote: > > > On Thu, May 22, 2025 at 7:42 PM Kieran Kunhya via ffmpeg-devel > > > wrote: > > > > I wanted to put on the record that adding RaptorQ to FFmpeg isn't > > > > maintenance of FFmpeg. > > > > i agree adding RaptorQ itself is probably not maintenance > > Ok, so that much everybody seems to agree on. Great. > > > > > It's adding an obscure FEC protocol to FFmpeg, > > > > tornado and raptor codes are not obscure. > > and FFmpeg supports hundreads of much more obscure things > > Sure, no disagreement there. While I've personally never used any of > the codecs that support video games from the 1990's, I don't really > have any problem with them being in ffmpeg. That said, in my opinion, > I doubt STF would really think it's a good use of their funds to add > support for new codecs for such games. yes, of course [...] > > > I agree with Kieran that this seems to largely be outside the STF > > > objectives (i.e. sustainability for open source projects). > > > > A new implementation of RIST, SRT, Raptor and so on may fall outside > > but redesigning the protocol layer in FFmpeg would perfectly fit inside > > "sustainability for open source projects" > > When you want A and B and both are connected, you ask for the funding > > to be for the side that fits inside the guidelines > > So this STF project could be changed to center on maintaince of the > > protocol layer instead of a RaptorQ/SRT/RIST implementation i think. > > I'm certainly not suggesting anybody implement a new version of RIST > or SRT (and on a personal note I give Kieran an enormous amount of > credit for building his own SRT implementation). But yeah, I think > most people who have looked closely at the ffmpeg protocol layer > acknowledge it could be improved, and that seems like the thing that > someone could easily convince STF of. So if i understand you correctly, we seem to agree here If someone wants to do a protocol layer improvment project in FFmpeg STF you agree with me that this would fall within STF. we would just need someone who wants to do that. thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB It is dangerous to be right in matters on which the established authorities are wrong. -- Voltaire signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 1/2] avformat/rtsp: parse framerate in sdp
On Fri, May 23, 2025 at 01:59:37AM +0200, Marvin Scholz wrote:
> From: Erik Linge
>
> Co-authored-by: Marvin Scholz
> ---
> libavformat/rtsp.c | 7 +++
> 1 file changed, 7 insertions(+)
>
> diff --git a/libavformat/rtsp.c b/libavformat/rtsp.c
> index 5ea471b40c..6807e1d6b5 100644
> --- a/libavformat/rtsp.c
> +++ b/libavformat/rtsp.c
> @@ -618,6 +618,13 @@ static void sdp_parse_line(AVFormatContext *s,
> SDPParseState *s1,
> s1->seen_fmtp = 1;
> av_strlcpy(s1->delayed_fmtp, buf, sizeof(s1->delayed_fmtp));
> }
> +} else if (av_strstart(p, "framerate:", &p) && s->nb_streams > 0) {
> +// RFC 8866
> +double framerate;
> +if (av_sscanf(p, "%lf%c", &framerate, &(char){}) == 1) {
> +st = s->streams[s->nb_streams - 1];
> +st->avg_frame_rate = av_d2q(framerate, INT_MAX);
> +}
mingw64:
src/libavformat/rtsp.c: In function ‘sdp_parse_line’:
src/libavformat/rtsp.c:624:58: error: empty scalar initializer
624 | if (av_sscanf(p, "%lf%c", &framerate, &(char){}) == 1) {
| ^
src/libavformat/rtsp.c:624:58: note: (near initialization for ‘(anonymous)’)
make: *** [src/ffbuild/common.mak:81: libavformat/rtsp.o] Error 1
make: *** Waiting for unfinished jobs
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
If one takes all money from those who grow wealth and gives it to those who
do not grow wealth, 10 years later, almost the same people who where wealthy
will be wealthy again, the same people who where poor will be poor again.
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2 08/17] swscale/ops_internal: add internal ops backend API
On Wed, May 21, 2025 at 02:43:54PM +0200, Niklas Haas wrote: > From: Niklas Haas > > This adds an internal API for ops backends, which are responsible for > compiling op lists into executable functions. > --- > libswscale/ops.c | 62 ++ > libswscale/ops_internal.h | 108 ++ > 2 files changed, 170 insertions(+) > create mode 100644 libswscale/ops_internal.h ubuntu x86-32 In file included from src/libavutil/internal.h:39:0, from src/libavutil/common.h:50, from src/libavutil/avutil.h:300, from src/libswscale/swscale.h:33, from src/libswscale/graph.h:27, from src/libswscale/ops.h:28, from src/libswscale/ops.c:27: src/libswscale/ops_internal.h:50:1: error: static assertion failed: "SwsOpExec layout mismatch" static_assert(sizeof(SwsOpExec) == 16 * sizeof(void *) + 8 * sizeof(int32_t), ^ make: *** [/home/michael/ffmpeg-git/ffmpeg/ffbuild/common.mak:81: libswscale/ops.o] Error 1 make: *** Waiting for unfinished jobs AR libavcodec/libavcodec.a [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB While the State exists there can be no freedom; when there is freedom there will be no State. -- Vladimir Lenin signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v2 1/2] avformat/rtsp: parse framerate in sdp
From: Erik Linge
Co-authored-by: Marvin Scholz
---
libavformat/rtsp.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/libavformat/rtsp.c b/libavformat/rtsp.c
index 5ea471b40c..3f2966414f 100644
--- a/libavformat/rtsp.c
+++ b/libavformat/rtsp.c
@@ -618,6 +618,13 @@ static void sdp_parse_line(AVFormatContext *s,
SDPParseState *s1,
s1->seen_fmtp = 1;
av_strlcpy(s1->delayed_fmtp, buf, sizeof(s1->delayed_fmtp));
}
+} else if (av_strstart(p, "framerate:", &p) && s->nb_streams > 0) {
+// RFC 8866
+double framerate;
+if (av_sscanf(p, "%lf%c", &framerate, &(char){0}) == 1) {
+st = s->streams[s->nb_streams - 1];
+st->avg_frame_rate = av_d2q(framerate, INT_MAX);
+}
} else if (av_strstart(p, "ssrc:", &p) && s->nb_streams > 0) {
rtsp_st = rt->rtsp_streams[rt->nb_rtsp_streams - 1];
get_word(buf1, sizeof(buf1), &p);
--
2.39.5 (Apple Git-154)
___
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 08/17] swscale/ops_internal: add internal ops backend API
On Fri, 23 May 2025 18:27:38 +0200 Michael Niedermayer wrote: > On Wed, May 21, 2025 at 02:43:54PM +0200, Niklas Haas wrote: > > From: Niklas Haas > > > > This adds an internal API for ops backends, which are responsible for > > compiling op lists into executable functions. > > --- > > libswscale/ops.c | 62 ++ > > libswscale/ops_internal.h | 108 ++ > > 2 files changed, 170 insertions(+) > > create mode 100644 libswscale/ops_internal.h > > ubuntu x86-32 > > In file included from src/libavutil/internal.h:39:0, > from src/libavutil/common.h:50, > from src/libavutil/avutil.h:300, > from src/libswscale/swscale.h:33, > from src/libswscale/graph.h:27, > from src/libswscale/ops.h:28, > from src/libswscale/ops.c:27: > src/libswscale/ops_internal.h:50:1: error: static assertion failed: > "SwsOpExec layout mismatch" > static_assert(sizeof(SwsOpExec) == 16 * sizeof(void *) + 8 * sizeof(int32_t), > ^ > make: *** [/home/michael/ffmpeg-git/ffmpeg/ffbuild/common.mak:81: > libswscale/ops.o] Error 1 > make: *** Waiting for unfinished jobs Fixed; I've opted to instead move the alignment to the usage site. > ARlibavcodec/libavcodec.a > > [...] > -- > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > While the State exists there can be no freedom; when there is freedom there > will be no State. -- Vladimir Lenin > ___ > 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] STF RaptorQ
On Fri, May 23, 2025 at 4:00 PM Kieran Kunhya wrote: > > On Fri, May 23, 2025 at 3:50 PM Devin Heitmueller > wrote: > > > > Hello Michael, > > > > On Fri, May 23, 2025 at 5:45 AM Michael Niedermayer > > wrote: > > > On Thu, May 22, 2025 at 07:55:40PM -0400, Devin Heitmueller wrote: > > > > On Thu, May 22, 2025 at 7:42 PM Kieran Kunhya via ffmpeg-devel > > > > wrote: > > > > > I wanted to put on the record that adding RaptorQ to FFmpeg isn't > > > > > maintenance of FFmpeg. > > > > > > i agree adding RaptorQ itself is probably not maintenance > > > > Ok, so that much everybody seems to agree on. Great. > > > > > > > It's adding an obscure FEC protocol to FFmpeg, > > > > > > tornado and raptor codes are not obscure. > > > and FFmpeg supports hundreads of much more obscure things > > > > Sure, no disagreement there. While I've personally never used any of > > the codecs that support video games from the 1990's, I don't really > > have any problem with them being in ffmpeg. That said, in my opinion, > > I doubt STF would really think it's a good use of their funds to add > > support for new codecs for such games. > > > > > > I'm not sure I've seen any commercial gear that does RaptorQ for FEC, > > > > so it's not clear what the use cases are if the goal is > > > > interoperability. > > > > > > its IMHO for communication between tools that on both sides > > > use our software > > > > > > If no commercial gear uses a reliable FEC system all teh better > > > for us > > > > Wow, that's quite a leap to suggest that because there aren't open > > standards using RaptorQ that there isn't commercial video transmission > > gear out there that doesn't do a good job with FEC. > > > > > > If somebody really wants to be paid to work on > > > > reliable transport protocols, the time would be better spent improving > > > > the RIST or SRT integration, which is where most of the industry is > > > > putting their energy. > > > > > > FEC is supperior to ARQ > > > for ARQ, each receiver needs to request the lost packet > > > while for FEC the sender just needs to know or guess how many packets > > > where lost. > > > 1. FEC is lower latency This isn't true. You need a large FEC matrix to handle burst packet loss and you have to buffer for the duration of this matrix. At low bitrates this duration can be really long. (100 packets at 1mbit/s is already roughly a second). Regards, Kieran Kunhya ___ 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] STF RaptorQ
Hi Devin On Fri, May 23, 2025 at 10:57:37AM -0400, Devin Heitmueller wrote: > On Fri, May 23, 2025 at 5:58 AM Michael Niedermayer > wrote: > > Theres also the human element, where people are not machienes that can > > be placed and told things arbitrary. RaptorQ is "cool", ARQ is boring > > > > Some people enjoy working on "cool" things, dont tell them to work on > > boring things please. Its bad for them, and likely bad for the results. > > > > If you find RIST/SRT important, you should work on it, or fund someone > > to do it or to submit a project idea to STF/GsoC/... and work on it > > with their funding ... > > > > Also IMO if you have someone who wants to do a project that moves FFmpeg > > forward, be supportive of the effort and try to find a way to make it happen > > be that inside or outside STF. > > Arguing against efforts to move to teh cutting edge of technology > > will do only one thing and thats havig competitors take the space > > and FFmpeg fall behind > > To be clear, I have no desire to discourage developers from working on > anything that interests them. I've spoken to Lynne about her txproto > work, and while I can't offer any guidance due to the NDA with my > employer, I admire her initiative and really hope that research turns > into something useful. > > This discussion though really started about what the scope of work is > that can be funded by STF. My understanding is that STF intends for > the funds to be used for maintenance and work that contributes toward > project sustainability. At least for me personally, I am not > confident I could argue that the RaptorQ work proposed falls within > that definition. yes, as it was proposed on the wiki and as i remember STF, i agree. thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB No great genius has ever existed without some touch of madness. -- Aristotle signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v2 2/2] avformat/rtpdec_jpeg: Set width and heigh codec parameters
From: Erik Linge --- libavformat/rtpdec_jpeg.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/libavformat/rtpdec_jpeg.c b/libavformat/rtpdec_jpeg.c index 81036247c1..4d9ee0d754 100644 --- a/libavformat/rtpdec_jpeg.c +++ b/libavformat/rtpdec_jpeg.c @@ -233,6 +233,8 @@ static int jpeg_parse_packet(AVFormatContext *ctx, PayloadContext *jpeg, q = AV_RB8(buf + 5); /* quantization factor (or table id) */ width = AV_RB8(buf + 6); /* frame width in 8 pixel blocks */ height = AV_RB8(buf + 7); /* frame height in 8 pixel blocks */ +st->codecpar->width = width*8; +st->codecpar->height = height*8; buf += 8; len -= 8; -- 2.39.5 (Apple Git-154) ___ 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] STF RaptorQ
Hi, > > > But Lynne is insisting it's not a protocol. The work would just be the low > level RaptorQ algorithm. > > UDP based retransmit/FEC protocols are essentially impossible to develop > well without an event loop / timers. > > You can look at libsrt and librist of examples of how trying to reinvent an > event loop in threads and creating lots of bugs in the process as each lib > struggles to synchronise a complex state machine between threads. > > Adding event loop support to FFmpeg would be a great STF project. I just wanted to drop a giant +1 that event loop support in FFmpeg would be a big win (and unblock a lot of other improvements for e.g. FFmpeg's network stack IMO) and should seriously be considered for an STF project if someone has the wherewithal. It's obviously a pretty large undertaking. Best, Tristan ___ 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] avformat/rtsp: parse framerate in sdp
On 23 May 2025, at 18:06, Michael Niedermayer wrote:
> On Fri, May 23, 2025 at 01:59:37AM +0200, Marvin Scholz wrote:
>> From: Erik Linge
>>
>> Co-authored-by: Marvin Scholz
>> ---
>> libavformat/rtsp.c | 7 +++
>> 1 file changed, 7 insertions(+)
>>
>> diff --git a/libavformat/rtsp.c b/libavformat/rtsp.c
>> index 5ea471b40c..6807e1d6b5 100644
>> --- a/libavformat/rtsp.c
>> +++ b/libavformat/rtsp.c
>> @@ -618,6 +618,13 @@ static void sdp_parse_line(AVFormatContext *s,
>> SDPParseState *s1,
>> s1->seen_fmtp = 1;
>> av_strlcpy(s1->delayed_fmtp, buf, sizeof(s1->delayed_fmtp));
>> }
>> +} else if (av_strstart(p, "framerate:", &p) && s->nb_streams > 0) {
>> +// RFC 8866
>> +double framerate;
>> +if (av_sscanf(p, "%lf%c", &framerate, &(char){}) == 1) {
>> +st = s->streams[s->nb_streams - 1];
>> +st->avg_frame_rate = av_d2q(framerate, INT_MAX);
>> +}
>
> mingw64:
>
> src/libavformat/rtsp.c: In function ‘sdp_parse_line’:
> src/libavformat/rtsp.c:624:58: error: empty scalar initializer
> 624 | if (av_sscanf(p, "%lf%c", &framerate, &(char){}) == 1) {
> | ^
> src/libavformat/rtsp.c:624:58: note: (near initialization for ‘(anonymous)’)
> make: *** [src/ffbuild/common.mak:81: libavformat/rtsp.o] Error 1
> make: *** Waiting for unfinished jobs
>
>
> thx
Thanks for testing, I sent a new version that should fix this.
>
> [...]
>
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> If one takes all money from those who grow wealth and gives it to those who
> do not grow wealth, 10 years later, almost the same people who where wealthy
> will be wealthy again, the same people who where poor will be poor again.
> ___
> 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] avformat/sdp: add framerate entry
Hi Marvin
On Fri, May 23, 2025 at 02:11:24AM +0200, Marvin Scholz wrote:
> ---
> libavformat/sdp.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/libavformat/sdp.c b/libavformat/sdp.c
> index 215e38f8fc..21ada5d1ce 100644
> --- a/libavformat/sdp.c
> +++ b/libavformat/sdp.c
> @@ -867,6 +867,9 @@ int ff_sdp_write_media(char *buff, int size, const
> AVStream *st, int idx,
> if (p->bit_rate) {
> av_strlcatf(buff, size, "b=AS:%"PRId64"\r\n", p->bit_rate / 1000);
> }
> +if (p->framerate.num > 0 && p->framerate.den > 0) {
> +av_strlcatf(buff, size, "a=framerate:%g\r\n", av_q2d(p->framerate));
> +}
>
> return sdp_write_media_attributes(buff, size, st, payload_type, fmt);
> }
> --
> 2.39.5 (Apple Git-154)
breaks fate:
TESTlavf-mov_rtphint
--- ./tests/ref/lavf/mov_rtphint2025-05-23 14:14:31.476447585 +0200
+++ tests/data/fate/lavf-mov_rtphint2025-05-23 20:51:14.221038582 +0200
@@ -1,3 +1,3 @@
-d3d0b0a15e2207e1d69b7de5c0ff845c *tests/data/lavf/lavf.mov_rtphint
-365745 tests/data/lavf/lavf.mov_rtphint
+e5e994cd3885a28304229f5e277c1917 *tests/data/lavf/lavf.mov_rtphint
+365761 tests/data/lavf/lavf.mov_rtphint
tests/data/lavf/lavf.mov_rtphint CRC=0xbb2b949b
Test lavf-mov_rtphint failed. Look at tests/data/fate/lavf-mov_rtphint.err for
details.
make: *** [tests/Makefile:316: fate-lavf-mov_rtphint] Error 1
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Many that live deserve death. And some that die deserve life. Can you give
it to them? Then do not be too eager to deal out death in judgement. For
even the very wise cannot see all ends. -- Gandalf
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] [FFmpeg-cvslog] tests/fate/ac3: add a second ac3_fixed encoder test
Andreas Rheinhardt: > Martin Storsjö: >> On Thu, 22 May 2025, James Almer wrote: >> >>> ffmpeg | branch: master | James Almer | Thu May 22 >>> 19:23:35 2025 -0300| [622a72b5ea5f2022b173355d65d513df2d75000b] | >>> committer: James Almer >>> >>> tests/fate/ac3: add a second ac3_fixed encoder test >>> >>> Exercising the lavfi filtergraph codepath to choose the best output >>> layout. >>> >>> Signed-off-by: James Almer >>> http://git.videolan.org/gitweb.cgi/ffmpeg.git/? a=commit;h=622a72b5ea5f2022b173355d65d513df2d75000b >>> --- >>> >>> tests/fate/ac3.mak | 5 + >>> 1 file changed, 5 insertions(+) >>> >>> diff --git a/tests/fate/ac3.mak b/tests/fate/ac3.mak >>> index 1ecb5a3f54..b23a9e4dcc 100644 >>> --- a/tests/fate/ac3.mak >>> +++ b/tests/fate/ac3.mak >>> @@ -91,6 +91,11 @@ fate-ac3-fixed-encode: CMD = md5 -i $(SRC) -c >>> ac3_fixed -ab 128k -f ac3 -flags + >>> fate-ac3-fixed-encode: CMP = oneline >>> fate-ac3-fixed-encode: REF = e9d78bca187b4bbafc4512bcea8efd3e >>> >>> +FATE_AC3-$(call ALLYES, EAC3_DEMUXER AC3_FIXED_ENCODER AC3_MUXER >>> ARESAMPLE_FILTER) += fate-ac3-fixed-encode-2 >>> +fate-ac3-fixed-encode-2: CMD = md5pipe -i $(TARGET_SAMPLES)/eac3/ >>> the_great_wall_7.1.eac3 -c:a ac3_fixed -ab 256k -f ac3 -flags >>> +bitexact -af aresample >>> +fate-ac3-fixed-encode-2: CMP = oneline >>> +fate-ac3-fixed-encode-2: REF = 1b92b037b23b231c9523f334ccfb11da >>> + >>> FATE_EAC3-$(call ALLYES, EAC3_DEMUXER EAC3_MUXER EAC3_CORE_BSF) += >>> fate-eac3-core-bsf >>> fate-eac3-core-bsf: CMD = md5pipe -i $(TARGET_SAMPLES)/eac3/ >>> the_great_wall_7.1.eac3 -c:a copy -bsf:a eac3_core -fflags +bitexact - >>> f eac3 >>> fate-eac3-core-bsf: CMP = oneline >> >> This test seems to fail in a large number of configurations; see fate. >> > > Presumably because it does not use the ac3_fixed decoder? > And why was this not on the mailing list? (That's a question for James, > not for you.) > The fixed point ac3 decoder also uses floats, so it also may not work. - Andreas ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2] fix(configure): fix detection on windows arm64
Also we can check $MSYSTEM_CARCH if it exists How about your idea? Coia Prant 于 2025年5月23日周五 17:11写道： > On Windows Arm64 > `uname -m` returned `x86_64` instead of `aarch64` > Link: https://github.com/msys2/msys2-runtime/issues/171 > > But `uname -s` contains `ARM64` suffix > So check MSYSTEM on windows arm64 (for clangarm64) > > This problem also in VideoLAN/x264 > Link: https://code.videolan.org/videolan/x264/-/merge_requests/177 > > Signed-off-by: Coia Prant > --- > configure | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/configure b/configure > index 2e69b3c..1901da3 100755 > --- a/configure > +++ b/configure > @@ -4151,12 +4151,15 @@ response_files_default="auto" > # OS > target_os_default=$(tolower $(uname -s)) > host_os=$target_os_default > +msystem=$(tolower $MSYSTEM) > > # machine > if test "$target_os_default" = aix; then > arch_default=$(uname -p) > strip_default="strip -X32_64" > nm_default="nm -g -X32_64" > +elif test "$msystem" = clangarm64; then > +arch_default="aarch64" > else > arch_default=$(uname -m) > fi > -- > 2.49.0.windows.1 > > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] Funding Proposals
On Fri, May 23, 2025 at 11:38 AM Leo Izen wrote: > > I'm actually quite out of the loop on how to request funding. I've been > meaning to do it since I'm putting a lot of hours into my EXIF work, and > still got a bunch more. A lot of code is written but much of it is not > tested, and that's important. > > Can someone explain the process, in a nutshell, along with reasonable > numbers for requests? Assuming (a) there is a critical mass of projects and (b) STF funding is still available, "we" could request such additional funding. The first step would be to add your request at the following wiki page: https://trac.ffmpeg.org/wiki/SponsoringPrograms/STF/2025 Recall that STF focuses on maintenance/bug/security fixes. > > - Leo Izen (Traneptora) > ___ > 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] [FEATURE PROPOSAL] Extracting codec-level data to binary files
On 2025-05-23T02:57:36.000+02:00, Michael Niedermayer wrote: > On Fri, May 23, 2025 at 02:45:59AM +0200, Michael Niedermayer wrote: > >> Hi Ronald On Thu, May 22, 2025 at 07:59:06AM -0400, Ronald S. >> Bultje wrote: >> >>> Hi, On Wed, May 21, 2025 at 9:34 AM Timothée < >>> timothee.informati...@regaud-chapuy.fr> wrote: >>> Hello, I am interested in expanding ffmpeg's capabilities to extract low-level data from video codecs. Specifically, I'd like to implement functionality that would allow exporting frame data, macroblock information, quantization tables, and similar codec-specific elements to binary files for further analysis. After searching through the documentation and existing features, I haven't found similar functionality, though I may have missed something. Has this been implemented before, or are there related features I should examine? >>> >>>Some older codecs implement minor variants for this, e.g. grep >>> for AV_FRAME_DATA_MOTION_VECTORS, which attaches a frame's >>> motion vectors to the picture data. I believe there's an example >>> app and possibly a filter to overlay MVs on top of the video >>> frame based on this concept. You could extend this to cover >>> other (macro)block info. There used to be a variant of this for >>> quant-tables also but I can't find it, maybe it was removed. >> >> For motion vectors: ./ffplay -flags2 +export_mvs -i >> matrixbench_mpeg2.mpg -vf codecview=mv=pf+bf+bb For macroblock >> segmentation and type vissualization + also motion vectors: >> ffplay-3.4.13 -debug vis_mb_type matrixbench_mpeg2.mpg -vf >> codecview=mv=pf+bf+bb For QP vissualization + also motion vectors: >> ffplay-3.4.13 -debug vis_qp matrixbench_mpeg2.mpg -vf >> codecview=mv=pf+bf+bb For qp values dumped on the console ./ffplay >> -debug qp -i matrixbench_mpeg2.mpg > > And this can easily be extended to other codecs, ATM it should work > with all 16x16 MB based codecs like > msmpeg4*/wmv*/mpeg1/2/4/h263/h264 mbtype and qp vissualization need > codecview to be extended or versions around 3.4 which implemented it > differently Implementing vissualization as done currently with > sidedata and codecview is simple and efficient. It also would allow > exporting the data to json by writing a codec2json filter in place > of codecview Also all decoders already have all this data parsed and > available so its simpler than trying to do it in a decoder > independant way I would thus suggest implementations of this for > modern codecs to follow the same path as the existing code. thx Thanks for the helpful pointers! I will work on the codec2json filter. Looking at the code, I see where I can access sidedata but extracting qb table seems to fail. (in codecview.c l.233: ff_qp_table_extract() return 0 and qp_table is empty) (I use ./ffmpeg -flags2 +export_mvs -i input.mp4 -vf codecview=qp=1 output.mp4 -y) Is is qp extraction not implemented yet? Or is it because I have h264 video? If it's not implemented, I'm curious why there’s already code that appears to handle it. Timothée ___ 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] fix(configure): fix detection on windows
On Windows Arm64 `uname -m` returned `x86_64` instead of `aarch64` Link: https://github.com/msys2/msys2-runtime/issues/171 On x86 32-bit toolchain msys2 environment `uname -m` returned `x86_64` instead of `i686` or `x86` So check MSYSTEM_CARCH on windows (for arm64 and i686) This problem also in VideoLAN/x264 Link: https://code.videolan.org/videolan/x264/-/merge_requests/177 Signed-off-by: Coia Prant --- configure | 2 ++ 1 file changed, 2 insertions(+) diff --git a/configure b/configure index 2e69b3c..ed30b6b 100755 --- a/configure +++ b/configure @@ -4157,6 +4157,8 @@ if test "$target_os_default" = aix; then arch_default=$(uname -p) strip_default="strip -X32_64" nm_default="nm -g -X32_64" +elif test "$MSYSTEM_CARCH" != ""; then +arch_default="$MSYSTEM_CARCH" else arch_default=$(uname -m) fi -- 2.49.0.windows.1 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] STF RaptorQ
On Fri, 23 May 2025, 04:44 Lynne, wrote: > On 23/05/2025 08:42, Kieran Kunhya via ffmpeg-devel wrote: > > Hello, > > > > I wanted to put on the record that adding RaptorQ to FFmpeg isn't > > maintenance of FFmpeg. > > It isn't -- it's research. > STF isn't for "fun things I want to work on" I appreciate the way the 2024 organisers ran STF was not exactly stellar but that doesn't mean you can just jump on the bandwagon in 2025. Kieran > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [FFmpeg-cvslog] tests/fate/ac3: add a second ac3_fixed encoder test
Martin Storsjö: > On Thu, 22 May 2025, James Almer wrote: > >> ffmpeg | branch: master | James Almer | Thu May 22 >> 19:23:35 2025 -0300| [622a72b5ea5f2022b173355d65d513df2d75000b] | >> committer: James Almer >> >> tests/fate/ac3: add a second ac3_fixed encoder test >> >> Exercising the lavfi filtergraph codepath to choose the best output >> layout. >> >> Signed-off-by: James Almer >> >>> http://git.videolan.org/gitweb.cgi/ffmpeg.git/? >>> a=commit;h=622a72b5ea5f2022b173355d65d513df2d75000b >> --- >> >> tests/fate/ac3.mak | 5 + >> 1 file changed, 5 insertions(+) >> >> diff --git a/tests/fate/ac3.mak b/tests/fate/ac3.mak >> index 1ecb5a3f54..b23a9e4dcc 100644 >> --- a/tests/fate/ac3.mak >> +++ b/tests/fate/ac3.mak >> @@ -91,6 +91,11 @@ fate-ac3-fixed-encode: CMD = md5 -i $(SRC) -c >> ac3_fixed -ab 128k -f ac3 -flags + >> fate-ac3-fixed-encode: CMP = oneline >> fate-ac3-fixed-encode: REF = e9d78bca187b4bbafc4512bcea8efd3e >> >> +FATE_AC3-$(call ALLYES, EAC3_DEMUXER AC3_FIXED_ENCODER AC3_MUXER >> ARESAMPLE_FILTER) += fate-ac3-fixed-encode-2 >> +fate-ac3-fixed-encode-2: CMD = md5pipe -i $(TARGET_SAMPLES)/eac3/ >> the_great_wall_7.1.eac3 -c:a ac3_fixed -ab 256k -f ac3 -flags >> +bitexact -af aresample >> +fate-ac3-fixed-encode-2: CMP = oneline >> +fate-ac3-fixed-encode-2: REF = 1b92b037b23b231c9523f334ccfb11da >> + >> FATE_EAC3-$(call ALLYES, EAC3_DEMUXER EAC3_MUXER EAC3_CORE_BSF) += >> fate-eac3-core-bsf >> fate-eac3-core-bsf: CMD = md5pipe -i $(TARGET_SAMPLES)/eac3/ >> the_great_wall_7.1.eac3 -c:a copy -bsf:a eac3_core -fflags +bitexact - >> f eac3 >> fate-eac3-core-bsf: CMP = oneline > > This test seems to fail in a large number of configurations; see fate. > Presumably because it does not use the ac3_fixed decoder? And why was this not on the mailing list? (That's a question for James, not for you.) - Andreas ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v2] fix(configure): fix detection on windows arm64
On Windows Arm64 `uname -m` returned `x86_64` instead of `aarch64` Link: https://github.com/msys2/msys2-runtime/issues/171 But `uname -s` contains `ARM64` suffix So check MSYSTEM on windows arm64 (for clangarm64) This problem also in VideoLAN/x264 Link: https://code.videolan.org/videolan/x264/-/merge_requests/177 Signed-off-by: Coia Prant --- configure | 3 +++ 1 file changed, 3 insertions(+) diff --git a/configure b/configure index 2e69b3c..1901da3 100755 --- a/configure +++ b/configure @@ -4151,12 +4151,15 @@ response_files_default="auto" # OS target_os_default=$(tolower $(uname -s)) host_os=$target_os_default +msystem=$(tolower $MSYSTEM) # machine if test "$target_os_default" = aix; then arch_default=$(uname -p) strip_default="strip -X32_64" nm_default="nm -g -X32_64" +elif test "$msystem" = clangarm64; then +arch_default="aarch64" else arch_default=$(uname -m) fi -- 2.49.0.windows.1 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] STF RaptorQ
Hi On Thu, May 22, 2025 at 07:55:40PM -0400, Devin Heitmueller wrote: > On Thu, May 22, 2025 at 7:42 PM Kieran Kunhya via ffmpeg-devel > wrote: > > I wanted to put on the record that adding RaptorQ to FFmpeg isn't > > maintenance of FFmpeg. i agree adding RaptorQ itself is probably not maintenance > > > > It's adding an obscure FEC protocol to FFmpeg, tornado and raptor codes are not obscure. and FFmpeg supports hundreads of much more obscure things [...] > I'm not sure I've seen any commercial gear that does RaptorQ for FEC, > so it's not clear what the use cases are if the goal is > interoperability. its IMHO for communication between tools that on both sides use our software If no commercial gear uses a reliable FEC system all teh better for us > If somebody really wants to be paid to work on > reliable transport protocols, the time would be better spent improving > the RIST or SRT integration, which is where most of the industry is > putting their energy. FEC is supperior to ARQ for ARQ, each receiver needs to request the lost packet while for FEC the sender just needs to know or guess how many packets where lost. 1. FEC is lower latency 2. FEC does not suffer from "oops the retrasmit was lost too" 3. if you have 3 receivers one lost packet 5 one packet 8 and one packet 0 with ARQ you need to send 3 individual packets with FEC you CAN broadcast the same 1 packet to all 3 receivers to recover them. Also FEC is VERY widely used, just not where you are looking. from compact disks, to phone networks to inter planetary communication since over 50 years its the standard, voyager in 1970 used FEC already. > > I agree with Kieran that this seems to largely be outside the STF > objectives (i.e. sustainability for open source projects). A new implementation of RIST, SRT, Raptor and so on may fall outside but redesigning the protocol layer in FFmpeg would perfectly fit inside "sustainability for open source projects" When you want A and B and both are connected, you ask for the funding to be for the side that fits inside the guidelines So this STF project could be changed to center on maintaince of the protocol layer instead of a RaptorQ/SRT/RIST implementation i think. thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Those who are too smart to engage in politics are punished by being governed by those who are dumber. -- Plato signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] tests/fate/ac3: Make ac3-fixed-encode-2 bitexact across arches
Patch attached. Another candidate as input file would be dts/master_audio_7.1_24bit.dts, but then it would be unclear whether this is still a true AC3 test. - Andreas From 493756488cd346eda96d7a6e6273d1e6ff455d68 Mon Sep 17 00:00:00 2001 From: Andreas Rheinhardt Date: Fri, 23 May 2025 11:42:38 +0200 Subject: [PATCH] tests/fate/ac3: Make ac3-fixed-encode-2 bitexact across arches Don't use a 7.1 EAC3 input file for which our decoder is not bitexact; instead just use the asynth-44100-8.wav file which (as a 7.1 file) exhibits the same issue fixed by 1b3f4842c18409dba5a345ef9e7b3de7a4fa3657. Also switch to a framecrc test so that the output channel layout is directly contained in the ref file. Signed-off-by: Andreas Rheinhardt --- tests/fate/ac3.mak| 10 +- tests/ref/fate/ac3-fixed-encode-2 | 178 ++ 2 files changed, 184 insertions(+), 4 deletions(-) create mode 100644 tests/ref/fate/ac3-fixed-encode-2 diff --git a/tests/fate/ac3.mak b/tests/fate/ac3.mak index b23a9e4dcc..dfbeedbb54 100644 --- a/tests/fate/ac3.mak +++ b/tests/fate/ac3.mak @@ -91,10 +91,12 @@ fate-ac3-fixed-encode: CMD = md5 -i $(SRC) -c ac3_fixed -ab 128k -f ac3 -flags + fate-ac3-fixed-encode: CMP = oneline fate-ac3-fixed-encode: REF = e9d78bca187b4bbafc4512bcea8efd3e -FATE_AC3-$(call ALLYES, EAC3_DEMUXER AC3_FIXED_ENCODER AC3_MUXER ARESAMPLE_FILTER) += fate-ac3-fixed-encode-2 -fate-ac3-fixed-encode-2: CMD = md5pipe -i $(TARGET_SAMPLES)/eac3/the_great_wall_7.1.eac3 -c:a ac3_fixed -ab 256k -f ac3 -flags +bitexact -af aresample -fate-ac3-fixed-encode-2: CMP = oneline -fate-ac3-fixed-encode-2: REF = 1b92b037b23b231c9523f334ccfb11da +# This tests that the LFE does not get lost when converting the input 7.1 +# to a channel layout supported by the encoder. +FATE_AC3-$(call FRAMECRC, WAV, PCM_S16LE, ARESAMPLE_FILTER AC3_FIXED_ENCODER) += fate-ac3-fixed-encode-2 +fate-ac3-fixed-encode-2: tests/data/asynth-44100-8.wav +fate-ac3-fixed-encode-2: SRC = $(TARGET_PATH)/tests/data/asynth-44100-8.wav +fate-ac3-fixed-encode-2: CMD = framecrc -i $(SRC) -c:a ac3_fixed -ab 256k -af aresample FATE_EAC3-$(call ALLYES, EAC3_DEMUXER EAC3_MUXER EAC3_CORE_BSF) += fate-eac3-core-bsf fate-eac3-core-bsf: CMD = md5pipe -i $(TARGET_SAMPLES)/eac3/the_great_wall_7.1.eac3 -c:a copy -bsf:a eac3_core -fflags +bitexact -f eac3 diff --git a/tests/ref/fate/ac3-fixed-encode-2 b/tests/ref/fate/ac3-fixed-encode-2 new file mode 100644 index 00..93aff13f06 --- /dev/null +++ b/tests/ref/fate/ac3-fixed-encode-2 @@ -0,0 +1,178 @@ +#tb 0: 1/44100 +#media_type 0: audio +#codec_id 0: ac3 +#sample_rate 0: 44100 +#channel_layout_name 0: 5.1(side) +0, -256, -256, 1536, 1114, 0x32fd276c +0, 1280, 1280, 1536, 1116, 0x1ac63ba7 +0, 2816, 2816, 1536, 1114, 0xdde82dbc +0, 4352, 4352, 1536, 1114, 0x39313179 +0, 5888, 5888, 1536, 1116, 0x166214e2 +0, 7424, 7424, 1536, 1114, 0xfbcc27ad +0, 8960, 8960, 1536, 1114, 0xe7ed3321 +0, 10496, 10496, 1536, 1114, 0xa1823473 +0, 12032, 12032, 1536, 1116, 0x1ccd1fe8 +0, 13568, 13568, 1536, 1114, 0x9377208a +0, 15104, 15104, 1536, 1114, 0x3438299e +0, 16640, 16640, 1536, 1116, 0x73303bb0 +0, 18176, 18176, 1536, 1114, 0x7f5225a4 +0, 19712, 19712, 1536, 1114, 0x18f92909 +0, 21248, 21248, 1536, 1114, 0x43b42275 +0, 22784, 22784, 1536, 1116, 0x06481d04 +0, 24320, 24320, 1536, 1114, 0xab4c3e3c +0, 25856, 25856, 1536, 1114, 0x614733e9 +0, 27392, 27392, 1536, 1116, 0x06151516 +0, 28928, 28928, 1536, 1114, 0xc395467d +0, 30464, 30464, 1536, 1114, 0x0e4a35ff +0, 32000, 32000, 1536, 1114, 0x15b23238 +0, 33536, 33536, 1536, 1116, 0x553a1cac +0, 35072, 35072, 1536, 1114, 0x82bc2b49 +0, 36608, 36608, 1536, 1114, 0xcfad2fc1 +0, 38144, 38144, 1536, 1114, 0x83c025fb +0, 39680, 39680, 1536, 1116, 0x8d322df4 +0, 41216, 41216, 1536, 1114, 0x536d1e18 +0, 42752, 42752, 1536, 1114, 0xfc8b0cd7 +0, 44288, 44288, 1536, 1116, 0x22343088 +0, 45824, 45824, 1536, 1114, 0x586929ef +0, 47360, 47360, 1536, 1114, 0xa2f13fdb +0, 48896, 48896, 1536, 1114, 0x9bff33d0 +0, 50432, 50432, 1536, 1116, 0xd2ab3a66 +0, 51968, 51968, 1536, 1114, 0xdb2a247e +0, 53504, 53504, 1536, 1114, 0x090f3a8a +0, 55040, 55040, 1536, 1116, 0x6b35205b +0, 56576, 56576, 1536, 1114, 0x0ce90a58 +0, 58112, 58112, 1536, 1114, 0xdb3ef5aa +0, 59648, 59
Re: [FFmpeg-devel] STF RaptorQ
On 23/05/2025 15:50, Kieran Kunhya via ffmpeg-devel wrote: On Fri, 23 May 2025, 04:44 Lynne, wrote: On 23/05/2025 08:42, Kieran Kunhya via ffmpeg-devel wrote: Hello, I wanted to put on the record that adding RaptorQ to FFmpeg isn't maintenance of FFmpeg. It isn't -- it's research. It's adding an obscure FEC protocol to FFmpeg, which is not going to be implemented well without an event loop anyway. You're mixing up FEC implementation details that don't matter for a library. It works much like a decoder - you put N blocks of Y bytes data in, and you get X blocks of Z byes out. I do not think it's a suitable STF project. STF is not maintenance-only from what I understand, but also for innovation, in this case, research. I point you to the previous thread on FEC where I explained that's a flawed design as it causes bursting in a practical protocol. You've basically answered the question that your implementation will be theoretical and not usable in a real protocol. Pretty much all implementations share the same underlying API, to the point where the protocol almost specifies how a public API would look like. It isn't a flawed design either, it works differently, so you simply use it differently. I've removed the proposal from the list. You should consider reading the spec, along with the Raptor spec. OpenPGP_0xA2FEA5F03F034464.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] STF RaptorQ
On Fri, 23 May 2025, 10:58 Michael Niedermayer, wrote: > On Fri, May 23, 2025 at 11:45:14AM +0200, Michael Niedermayer wrote: > > Hi > [...] > > > I agree with Kieran that this seems to largely be outside the STF > > > objectives (i.e. sustainability for open source projects). > > > > A new implementation of RIST, SRT, Raptor and so on may fall outside > > but redesigning the protocol layer in FFmpeg would perfectly fit inside > > "sustainability for open source projects" > > When you want A and B and both are connected, you ask for the funding > > to be for the side that fits inside the guidelines > > So this STF project could be changed to center on maintaince of the > > protocol layer instead of a RaptorQ/SRT/RIST implementation i think. > > Theres also the human element, where people are not machienes that can > be placed and told things arbitrary. RaptorQ is "cool", ARQ is boring > > Some people enjoy working on "cool" things, dont tell them to work on > boring things please. Its bad for them, and likely bad for the results. > They can work on cool things outside of STF. Kieran > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] STF RaptorQ
On Fri, 23 May 2025, 10:45 Michael Niedermayer, wrote: > Hi > > On Thu, May 22, 2025 at 07:55:40PM -0400, Devin Heitmueller wrote: > > On Thu, May 22, 2025 at 7:42 PM Kieran Kunhya via ffmpeg-devel > > wrote: > > > I wanted to put on the record that adding RaptorQ to FFmpeg isn't > > > maintenance of FFmpeg. > > i agree adding RaptorQ itself is probably not maintenance > > > > > > > > It's adding an obscure FEC protocol to FFmpeg, > > tornado and raptor codes are not obscure. > and FFmpeg supports hundreads of much more obscure things > > > [...] > > > I'm not sure I've seen any commercial gear that does RaptorQ for FEC, > > so it's not clear what the use cases are if the goal is > > interoperability. > > its IMHO for communication between tools that on both sides > use our software > > If no commercial gear uses a reliable FEC system all teh better > for us > But Lynne is insisting it's not a protocol. The work would just be the low level RaptorQ algorithm. UDP based retransmit/FEC protocols are essentially impossible to develop well without an event loop / timers. You can look at libsrt and librist of examples of how trying to reinvent an event loop in threads and creating lots of bugs in the process as each lib struggles to synchronise a complex state machine between threads. Adding event loop support to FFmpeg would be a great STF project. Kieran ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] tests/fate/ac3: Make ac3-fixed-encode-2 bitexact across arches
On 5/23/2025 6:52 AM, Andreas Rheinhardt wrote: Patch attached. Another candidate as input file would be dts/master_audio_7.1_24bit.dts, but then it would be unclear whether this is still a true AC3 test. - Andreas nit: maybe limit the amount of audio frames to be encoded, since it's not the important part of the test, and should reduce the size of the ref file. LGTM either way, thanks. OpenPGP_signature.asc Description: OpenPGP digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] STF RaptorQ
Hi Kieran On Fri, May 23, 2025 at 08:51:43AM +0100, Kieran Kunhya via ffmpeg-devel wrote: [...] > I appreciate the way the 2024 organisers ran STF was not exactly stellar It seems every mail you post is an attack on FFmpeg or the FFmpeg Team And its alot of different people you target. And often people who have done good and valuable work Seriously, I could easily talk negatively about you in every mail i write too but i dont, i try to be polite and positive. As an example i could have instead replied with a tone matching yours: (below is a (true) example of communication in the same tone as yours that i avoid) "I appreciated the stellar service you provided by providing and hosting a trac server for FFmpeg. It had only one broken cpu core. You only once decided to use the FFmpeg server to test some random audio hardware. Its sad that our users need reliable service" thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Rewriting code that is poorly written but fully understood is good. Rewriting code that one doesnt understand is a sign that one is less smart than the original author, trying to rewrite it will not make it better. signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v2] tests/fate/ac3: Make ac3-fixed-encode-2 bitexact across, arches
Updated version attached. Now only using six frames in order to avoid triggering differences on aarch64. - Andreas From 3b973c8bd47403348233a0b30fb03dfb0b7f5d75 Mon Sep 17 00:00:00 2001 From: Andreas Rheinhardt Date: Fri, 23 May 2025 11:42:38 +0200 Subject: [PATCH v2] tests/fate/ac3: Make ac3-fixed-encode-2 bitexact across arches Don't use a 7.1 EAC3 input file for which our decoder is not bitexact; instead just use the asynth-44100-8.wav file which (as a 7.1 file) exhibits the same issue fixed by 1b3f4842c18409dba5a345ef9e7b3de7a4fa3657. (Either the encoder or the resampler are still not completely bitexact, so we limit the number of frames output.) Also switch to a framecrc test so that the output channel layout is directly contained in the ref file. Signed-off-by: Andreas Rheinhardt --- tests/fate/ac3.mak| 10 ++ tests/ref/fate/ac3-fixed-encode-2 | 13 + 2 files changed, 19 insertions(+), 4 deletions(-) create mode 100644 tests/ref/fate/ac3-fixed-encode-2 diff --git a/tests/fate/ac3.mak b/tests/fate/ac3.mak index b23a9e4dcc..e52678a2fd 100644 --- a/tests/fate/ac3.mak +++ b/tests/fate/ac3.mak @@ -91,10 +91,12 @@ fate-ac3-fixed-encode: CMD = md5 -i $(SRC) -c ac3_fixed -ab 128k -f ac3 -flags + fate-ac3-fixed-encode: CMP = oneline fate-ac3-fixed-encode: REF = e9d78bca187b4bbafc4512bcea8efd3e -FATE_AC3-$(call ALLYES, EAC3_DEMUXER AC3_FIXED_ENCODER AC3_MUXER ARESAMPLE_FILTER) += fate-ac3-fixed-encode-2 -fate-ac3-fixed-encode-2: CMD = md5pipe -i $(TARGET_SAMPLES)/eac3/the_great_wall_7.1.eac3 -c:a ac3_fixed -ab 256k -f ac3 -flags +bitexact -af aresample -fate-ac3-fixed-encode-2: CMP = oneline -fate-ac3-fixed-encode-2: REF = 1b92b037b23b231c9523f334ccfb11da +# This tests that the LFE does not get lost when converting the input 7.1 +# to a channel layout supported by the encoder. +FATE_AC3-$(call FRAMECRC, WAV, PCM_S16LE, ARESAMPLE_FILTER AC3_FIXED_ENCODER) += fate-ac3-fixed-encode-2 +fate-ac3-fixed-encode-2: tests/data/asynth-44100-8.wav +fate-ac3-fixed-encode-2: SRC = $(TARGET_PATH)/tests/data/asynth-44100-8.wav +fate-ac3-fixed-encode-2: CMD = framecrc -i $(SRC) -c:a ac3_fixed -ab 256k -frames:a 6 -af aresample FATE_EAC3-$(call ALLYES, EAC3_DEMUXER EAC3_MUXER EAC3_CORE_BSF) += fate-eac3-core-bsf fate-eac3-core-bsf: CMD = md5pipe -i $(TARGET_SAMPLES)/eac3/the_great_wall_7.1.eac3 -c:a copy -bsf:a eac3_core -fflags +bitexact -f eac3 diff --git a/tests/ref/fate/ac3-fixed-encode-2 b/tests/ref/fate/ac3-fixed-encode-2 new file mode 100644 index 00..8e945b6637 --- /dev/null +++ b/tests/ref/fate/ac3-fixed-encode-2 @@ -0,0 +1,13 @@ +#tb 0: 1/44100 +#media_type 0: audio +#codec_id 0: ac3 +#sample_rate 0: 44100 +#channel_layout_name 0: 5.1(side) +0, -256, -256, 1536, 1114, 0x32fd276c +0, 1280, 1280, 1536, 1116, 0x1ac63ba7 +0, 2816, 2816, 1536, 1114, 0xdde82dbc +0, 4352, 4352, 1536, 1114, 0x39313179 +0, 5888, 5888, 1536, 1116, 0x166214e2 +0, 7424, 7424, 1536, 1114, 0xfbcc27ad +0, 8960, 8960, 1536, 1114, 0xe7ed3321 +0, 10496, 10496, 1536, 1114, 0xa1823473 -- 2.45.2 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [FEATURE PROPOSAL] Extracting codec-level data to binary files
On Fri, May 23, 2025 at 11:33:40AM +0200, Timothée wrote: > On 2025-05-23T02:57:36.000+02:00, Michael Niedermayer > wrote: > > > On Fri, May 23, 2025 at 02:45:59AM +0200, Michael Niedermayer wrote: > > > >> Hi Ronald On Thu, May 22, 2025 at 07:59:06AM -0400, Ronald S. > >> Bultje wrote: > >> > >>> Hi, On Wed, May 21, 2025 at 9:34 AM Timothée < > >>> timothee.informati...@regaud-chapuy.fr> wrote: > >>> > Hello, I am interested in expanding ffmpeg's capabilities to > extract low-level data from video codecs. Specifically, I'd > like to implement functionality that would allow exporting > frame data, macroblock information, quantization tables, and > similar codec-specific elements to binary files for further > analysis. After searching through the documentation and > existing features, I haven't found similar functionality, > though I may have missed something. Has this been implemented > before, or are there related features I should examine? > >>> > >>>Some older codecs implement minor variants for this, e.g. grep > >>> for AV_FRAME_DATA_MOTION_VECTORS, which attaches a frame's > >>> motion vectors to the picture data. I believe there's an example > >>> app and possibly a filter to overlay MVs on top of the video > >>> frame based on this concept. You could extend this to cover > >>> other (macro)block info. There used to be a variant of this for > >>> quant-tables also but I can't find it, maybe it was removed. > >> > >> For motion vectors: ./ffplay -flags2 +export_mvs -i > >> matrixbench_mpeg2.mpg -vf codecview=mv=pf+bf+bb For macroblock > >> segmentation and type vissualization + also motion vectors: > >> ffplay-3.4.13 -debug vis_mb_type matrixbench_mpeg2.mpg -vf > >> codecview=mv=pf+bf+bb For QP vissualization + also motion vectors: > >> ffplay-3.4.13 -debug vis_qp matrixbench_mpeg2.mpg -vf > >> codecview=mv=pf+bf+bb For qp values dumped on the console ./ffplay > >> -debug qp -i matrixbench_mpeg2.mpg > > > > And this can easily be extended to other codecs, ATM it should work > > with all 16x16 MB based codecs like > > msmpeg4*/wmv*/mpeg1/2/4/h263/h264 mbtype and qp vissualization need > > codecview to be extended or versions around 3.4 which implemented it > > differently Implementing vissualization as done currently with > > sidedata and codecview is simple and efficient. It also would allow > > exporting the data to json by writing a codec2json filter in place > > of codecview Also all decoders already have all this data parsed and > > available so its simpler than trying to do it in a decoder > > independant way I would thus suggest implementations of this for > > modern codecs to follow the same path as the existing code. thx > > Thanks for the helpful pointers! > > I will work on the codec2json filter. > > Looking at the code, I see where I can access sidedata but extracting > qb table seems to fail. (in codecview.c l.233: ff_qp_table_extract() > return 0 and qp_table is empty) (I use ./ffmpeg -flags2 +export_mvs -i > input.mp4 -vf codecview=qp=1 output.mp4 -y) > > Is is qp extraction not implemented yet? Or is it because I have h264 > video? If it's not implemented, I'm curious why there’s already code > that appears to handle it. look at ff_print_debug_info2() theres probably something missing The QP and MB type code was changed from being inside arrays of pictures to sidedata. Something likely was lost/forgotten in the process -debug qp works with h264 so likely teh export into sidedata is not fully implemented thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB "Nothing to hide" only works if the folks in power share the values of you and everyone you know entirely and always will -- Tom Scott 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 6/7] avfilter/alphadetect_vulkan: add alpha type detection filter
On Sun, 18 May 2025 14:11:51 +0200 Niklas Haas wrote:
> From: Niklas Haas
>
> This determines whether the input has any pixel values exceeding the alpha
> channel. In this case, we can be sure that the input is not premultiplied.
> In all other cases, the result in indeterminate. As such, we can only have
> false negatives, but no false positives.
I will drop this patch and resumbit it alongside a C implementation as a more
general purpose "detect color properties" filter, which will also be able to
auto-detect YUV range.
>
> Signed-off-by: Niklas Haas
> Sponsored-by: nxtedition
> ---
> configure | 1 +
> libavfilter/Makefile| 1 +
> libavfilter/allfilters.c| 1 +
> libavfilter/vf_alphadetect_vulkan.c | 400
> 4 files changed, 403 insertions(+)
> create mode 100644 libavfilter/vf_alphadetect_vulkan.c
>
> diff --git a/configure b/configure
> index 2e5f9fea49..9556d7c86f 100755
> --- a/configure
> +++ b/configure
> @@ -3869,6 +3869,7 @@ libzmq_protocol_deps="libzmq"
> libzmq_protocol_select="network"
>
> # filters
> +alphadetect_vulkan_filter_deps="vulkan spirv_compiler"
> ametadata_filter_deps="avformat"
> amovie_filter_deps="avcodec avformat"
> aresample_filter_deps="swresample"
> diff --git a/libavfilter/Makefile b/libavfilter/Makefile
> index e9d4566a2a..76a4f53932 100644
> --- a/libavfilter/Makefile
> +++ b/libavfilter/Makefile
> @@ -192,6 +192,7 @@ OBJS-$(CONFIG_ANULLSINK_FILTER) +=
> asink_anullsink.o
>
> # video filters
> OBJS-$(CONFIG_ADDROI_FILTER) += vf_addroi.o
> +OBJS-$(CONFIG_ALPHADETECT_VULKAN_FILTER) += vf_alphadetect_vulkan.o
> OBJS-$(CONFIG_ALPHAEXTRACT_FILTER) += vf_extractplanes.o
> OBJS-$(CONFIG_ALPHAMERGE_FILTER) += vf_alphamerge.o framesync.o
> OBJS-$(CONFIG_AMPLIFY_FILTER)+= vf_amplify.o
> diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c
> index 92890575f1..88204e070c 100644
> --- a/libavfilter/allfilters.c
> +++ b/libavfilter/allfilters.c
> @@ -177,6 +177,7 @@ extern const FFFilter ff_asrc_sine;
> extern const FFFilter ff_asink_anullsink;
>
> extern const FFFilter ff_vf_addroi;
> +extern const FFFilter ff_vf_alphadetect_vulkan;
> extern const FFFilter ff_vf_alphaextract;
> extern const FFFilter ff_vf_alphamerge;
> extern const FFFilter ff_vf_amplify;
> diff --git a/libavfilter/vf_alphadetect_vulkan.c
> b/libavfilter/vf_alphadetect_vulkan.c
> new file mode 100644
> index 00..ed76671fc1
> --- /dev/null
> +++ b/libavfilter/vf_alphadetect_vulkan.c
> @@ -0,0 +1,400 @@
> +/*
> + * Copyright 2025 (c) Niklas Haas
> + *
> + * This file is part of FFmpeg.
> + *
> + * FFmpeg is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU Lesser General Public
> + * License as published by the Free Software Foundation; either
> + * version 2.1 of the License, or (at your option) any later version.
> + *
> + * FFmpeg is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
> + * Lesser General Public License for more details.
> + *
> + * You should have received a copy of the GNU Lesser General Public
> + * License along with FFmpeg; if not, write to the Free Software
> + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301
> USA
> + */
> +
> +#include
> +#include "libavutil/vulkan_spirv.h"
> +#include "libavutil/opt.h"
> +#include "libavutil/timestamp.h"
> +#include "vulkan_filter.h"
> +
> +#include "drawutils.h"
> +#include "filters.h"
> +#include "video.h"
> +
> +enum AlphaType {
> +UNDETERMINED = 0,
> +STRAIGHT,
> +NONE,
> +};
> +
> +static const char *type2str(enum AlphaType type)
> +{
> +switch(type) {
> +case NONE : return "none";
> +case STRAIGHT : return "straight";
> +case UNDETERMINED : return "undetermined";
> +}
> +return NULL;
> +}
> +
> +typedef struct AlphaDetectVulkanContext {
> +FFVulkanContext vkctx;
> +
> +int initialized;
> +FFVkExecPool e;
> +AVVulkanDeviceQueueFamily *qf;
> +FFVulkanShader shd;
> +AVBufferPool *det_buf_pool;
> +
> +enum AlphaType type;
> +} AlphaDetectVulkanContext;
> +
> +typedef struct AlphaDetectPushData {
> +float yscale, yoff;
> +} AlphaDetectPushData;
> +
> +typedef struct AlphaDetectBuf {
> +uint32_t frame_straight;
> +} AlphaDetectBuf;
> +
> +static void fmt_swizzle(FFVulkanShader *shd, enum AVPixelFormat fmt)
> +{
> +const AVPixFmtDescriptor *desc = av_pix_fmt_desc_get(fmt);
> +uint8_t map[4];
> +char swiz[5] = {0};
> +
> +if (desc->flags & AV_PIX_FMT_FLAG_RGB) {
> +ff_fill_rgba_map(map, fmt);
> +} else if (desc->nb_components == 2) { /* ya */
> +GLSLC(1, color.a = color.y;);
> +return;
> +} else {
> +ff_fill_ay
Re: [FFmpeg-devel] STF RaptorQ
On Fri, 23 May 2025, 12:33 Michael Niedermayer, wrote: > Hi Kieran > > On Fri, May 23, 2025 at 08:51:43AM +0100, Kieran Kunhya via ffmpeg-devel > wrote: > [...] > > I appreciate the way the 2024 organisers ran STF was not exactly stellar > > It seems every mail you post is an attack on FFmpeg or the FFmpeg Team > And its alot of different people you target. And often people who > have done good and valuable work > STF was you and Thilo. Thilo doesn't exactly have the best reputation in this project. Seriously, I could easily talk negatively about you in every mail i > write too but i dont, i try to be polite and positive. > > As an example i could have instead replied with a tone matching yours: > (below is a (true) example of communication in the same tone as yours > that i avoid) > > "I appreciated the stellar service you provided by providing and > hosting a trac server for FFmpeg. It had only one broken cpu core. > You only once decided to use the FFmpeg server to test some random > audio hardware. > > Its sad that our users need reliable service" > You seem to forget that you contacted me in a panic because your hosting was gone. And I went into the office on a Saturday in my own time and found the first server I could find and immediately set it up for you. You are very much welcome for this. You really are doing an amazing job of antagonising people to leave the project. Let's list them: Paul Anton Derek Vittorio The two biggest contributors of the last decade gone because of you and both explicitly saying that. Who will be next! Tune into the next episode of Michael antagonising people who don't agree with him! Regards, Kieran ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC] Error handing with CBS
On Fri, May 23, 2025 at 11:44:26AM +0800, Zhao Zhili wrote: > I have created a ticket on trac and uploaded a sample. > > https://trac.ffmpeg.org/ticket/11603 > > The issue is CBS can detect invalid data in the bitstream, and report error. > How to handle these error is a problem. > > With a single error in SEI, it can break the decoding/transcoding process. > > ffmpeg -bsf:v h264_metadata -i input.mp4 -f null - > > [h264_metadata @ 0x6392c0f0] Invalid SEI user data unregistered payload. > [h264_metadata @ 0x6392c0f0] Failed to read unit 0 (type 6). > [h264_metadata @ 0x6392c0f0] Failed to read access unit from packet. > [vist#0:0/h264 @ 0x14c704ba0] Error applying bitstream filters to a packet: > Invalid data found when processing input > [in#0/mov,mp4,m4a,3gp,3g2,mj2 @ 0x14c6062c0] Task finished with error code: > -1094995529 (Invalid data found when processing input) > [in#0/mov,mp4,m4a,3gp,3g2,mj2 @ 0x14c6062c0] Terminating thread with return > code -1094995529 (Invalid data found when processing input) > > Part of the problem is ffmpeg_demux.c doesn’t respect exit_on_error with > bsf error. > > Another problem is CBS drops whole packet with a single error in SEI, and > the user of CBS doesn’t have the context where the error happened. > > I don’t know how to fine-tuning the error handing and without breaking the > layered design. i think CBS should not drop damaged data thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The bravest are surely those who have the clearest vision of what is before them, glory and danger alike, and yet notwithstanding go out to meet it. -- Thucydides 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 3/7] avfilter/vf_gblur_vulkan: omit unnecessary buffer usage flag
On Thu, 22 May 2025 06:32:42 +0900 Lynne wrote: > On 18/05/2025 21:11, Niklas Haas wrote: > > From: Niklas Haas > > > > Implied internally now when needed. > > --- > > libavfilter/vf_gblur_vulkan.c | 1 - > > 1 file changed, 1 deletion(-) > > > > diff --git a/libavfilter/vf_gblur_vulkan.c b/libavfilter/vf_gblur_vulkan.c > > index 80b66de735..fb676a7fc9 100644 > > --- a/libavfilter/vf_gblur_vulkan.c > > +++ b/libavfilter/vf_gblur_vulkan.c > > @@ -171,7 +171,6 @@ static int init_gblur_pipeline(GBlurVulkanContext *s, > > RET(ff_vk_shader_register_exec(&s->vkctx, &s->e, shd)); > > > > RET(ff_vk_create_buf(&s->vkctx, params_buf, sizeof(float) * ksize, > > NULL, NULL, > > - VK_BUFFER_USAGE_SHADER_DEVICE_ADDRESS_BIT | > >VK_BUFFER_USAGE_STORAGE_BUFFER_BIT, > >VK_MEMORY_PROPERTY_HOST_VISIBLE_BIT)); > > RET(ff_vk_map_buffer(&s->vkctx, params_buf, &kernel_mapped, 0)); > > Its used in a lot more places than here, but its a start. For the other use cases, I was not sure whether the code itself was taking the buffer's address (as e.g. nlmeans definitely does) > ___ > 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/7] avutil/vulkan: automatically enable shader device address usage bit
On Thu, 22 May 2025 06:32:18 +0900 Lynne wrote:
> On 18/05/2025 21:11, Niklas Haas wrote:
> > From: Niklas Haas
> >
> > We require this internally when using descriptor buffers, so it makes sense
> > to enable it internally, also.
> > ---
> > libavutil/vulkan.c | 3 +++
> > 1 file changed, 3 insertions(+)
> >
> > diff --git a/libavutil/vulkan.c b/libavutil/vulkan.c
> > index 5f2ac6267d..97c008c809 100644
> > --- a/libavutil/vulkan.c
> > +++ b/libavutil/vulkan.c
> > @@ -989,6 +989,9 @@ int ff_vk_create_buf(FFVulkanContext *s, FFVkBuffer
> > *buf, size_t size,
> > int use_ded_mem;
> > FFVulkanFunctions *vk = &s->vkfn;
> >
> > +if (s->extensions & FF_VK_EXT_DESCRIPTOR_BUFFER)
> > +usage |= VK_BUFFER_USAGE_SHADER_DEVICE_ADDRESS_BIT;
>
> You should omit the flag if the usage contains
> VK_BUFFER_USAGE_VIDEO_DECODE_SRC_BIT_KHR or
> VK_BUFFER_USAGE_VIDEO_ENCODE_DST_BIT_KHR, since its not used there.
I think a more robust logic would be to emit the flag only if the usage
contains any type that implies a descriptor (e.g. storage buffer, uniform
buffer, etc).
>
> > +
> > VkBufferCreateInfo buf_spawn = {
> > .sType = VK_STRUCTURE_TYPE_BUFFER_CREATE_INFO,
> > .pNext = pNext,
>
> Apart from that, okay.
> ___
> 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] STF RaptorQ
On Fri, May 23, 2025 at 11:45:14AM +0200, Michael Niedermayer wrote: > Hi [...] > > I agree with Kieran that this seems to largely be outside the STF > > objectives (i.e. sustainability for open source projects). > > A new implementation of RIST, SRT, Raptor and so on may fall outside > but redesigning the protocol layer in FFmpeg would perfectly fit inside > "sustainability for open source projects" > When you want A and B and both are connected, you ask for the funding > to be for the side that fits inside the guidelines > So this STF project could be changed to center on maintaince of the > protocol layer instead of a RaptorQ/SRT/RIST implementation i think. Theres also the human element, where people are not machienes that can be placed and told things arbitrary. RaptorQ is "cool", ARQ is boring Some people enjoy working on "cool" things, dont tell them to work on boring things please. Its bad for them, and likely bad for the results. If you find RIST/SRT important, you should work on it, or fund someone to do it or to submit a project idea to STF/GsoC/... and work on it with their funding ... Also IMO if you have someone who wants to do a project that moves FFmpeg forward, be supportive of the effort and try to find a way to make it happen be that inside or outside STF. Arguing against efforts to move to teh cutting edge of technology will do only one thing and thats havig competitors take the space and FFmpeg fall behind thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Asymptotically faster algorithms should always be preferred if you have asymptotical amounts of data 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] Percent-encode URL paths in HLS playlists
> -Original Message- > From: ffmpeg-devel On Behalf Of Marton > Balint > Sent: Freitag, 23. Mai 2025 22:31 > To: Timothy Allen via ffmpeg-devel > Subject: Re: [FFmpeg-devel] [PATCH] Percent-encode URL paths in HLS playlists > > > > On Fri, 23 May 2025, Timothy Allen via ffmpeg-devel wrote: > > > This commit closes trac ticket 10679. > > And what if the M3U8 is referencing absolute URLs with scheme? Or is using > a data URI? Or if it is a local DOS path? What if the URL is already > percent encoded? > > This issue is not trivial to fix, so I really meant it when I wrote that > its worth checking what heuristics other software is using for this issue. > > Thanks, > Marton I agree with Marton, it cannot be done that way. What I had actually in mind was a more targeted approach: 1. If the playlist has absolute URLs => leave them alone - we can assume they must be valid 2. If the playlist has relative URLs => don't touch the base URL. It is already working+ (otherwise we couldn't have loaded the playlist) => only percent-encode the url fragment from the playlist For Marton's additional point about the relative URL being URL-encoded already, you could check for a list of chars that are disallowed in URLs (excepting percent sign). Then URL-encode only when such char is present, as that means it's not URL-encoded yet. The edge case of a percent-sign needing to be escaped is probably negligible. Best, sw ___ 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] Percent-encode URL paths in HLS playlists
> -Original Message-
> From: ffmpeg-devel On Behalf Of Timothy
> Allen via ffmpeg-devel
> Sent: Freitag, 23. Mai 2025 16:53
> To: ffmpeg-devel@ffmpeg.org
> Cc: Timothy Allen
> Subject: [FFmpeg-devel] [PATCH] Percent-encode URL paths in HLS playlists
>
> This commit closes trac ticket 10679.
>
> Signed-off-by: Timothy Allen
> ---
> libavformat/hls.c | 9 +
> libavformat/url.c | 35 +++
> libavformat/url.h | 9 +
> 3 files changed, 53 insertions(+)
>
> diff --git a/libavformat/hls.c b/libavformat/hls.c
> index c7b655c83c..49436d8184 100644
> --- a/libavformat/hls.c
> +++ b/libavformat/hls.c
> @@ -1021,6 +1021,15 @@ static int parse_playlist(HLSContext *c, const char
> *url,
> seg->key = NULL;
> }
>
> +ff_percent_encode_url(tmp_str, sizeof(tmp_str), line);
> +if (!tmp_str[0]) {
> +ret = AVERROR_INVALIDDATA;
> +if (seg->key)
> +av_free(seg->key);
> +av_free(seg);
> +goto fail;
> +}
> +strcpy(line, av_strdup(tmp_str));
> ff_make_absolute_url(tmp_str, sizeof(tmp_str), url, line);
> if (!tmp_str[0]) {
> ret = AVERROR_INVALIDDATA;
> diff --git a/libavformat/url.c b/libavformat/url.c
> index d5dd6a4666..69d68d4248 100644
> --- a/libavformat/url.c
> +++ b/libavformat/url.c
> @@ -324,6 +324,41 @@ int ff_make_absolute_url(char *buf, int size, const char
> *base,
> return ff_make_absolute_url2(buf, size, base, rel, HAVE_DOS_PATHS);
> }
>
> +int ff_percent_encode_url(char *buf, int size, const char *url)
> +{
> +const char *hex = "0123456789abcdef";
> +
> +av_assert0(url);
> +
> +int p = 0;
> +int len = strlen(url);
> +for (int i = 0; i < len; i++) {
What about the slash:
> +if (i + 1 < len && ':' == url[i] && '/' == url[i+1])
> +buf[p++] = url[i];
> +else if (('a' <= url[i] && url[i] <= 'z')
> + || ('A' <= url[i] && url[i] <= 'Z')
> + || ('0' <= url[i] && url[i] <= '9')
> + || '/' == url[i] || '.' == url[i] || '~' == url[i]
> + || '-' == url[i] || '_' == url[i] || '+' == url[i]
> + || '?' == url[i] || '=' == url[i] || '&' == url[i]
> + || '#' == url[i])
> +{
> +buf[p++] = url[i];
> +} else if (' ' == url[i])
> +{
Space must be %20. The plus sign is only used for encoding form fields.
> +buf[p++] = '+';
> +} else
> +{
Check buffer size:
> +buf[p++] = '%';
Use HEX for upper case:
> +buf[p++] = hex[url[i] >> 4];
> +buf[p++] = hex[url[i] & 15];
> +}
> +}
Check buffer size:
> +buf[p] = '\0';
> +
> +return 0;
> +}
> +
Please also check behavior with signed/unsigned char, I'm not sure
whether the shifts are always right.
As a tip: using AVBPrint for building the string might be easier.
HLS URLs can be pretty long sometimes.
Regards
sw
___
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 v5 4/4] lavc: implement a Vulkan-based VC-2 encoder Implements a Vulkan based dirac encoder. Supports Haar and Legall wavelets and should work with all wavelet depths.
From: IndecisiveTurtle
Performance wise, encoding a 3440x1440 1-minute video is performed in about 2.4
minutes with the cpu encoder running on my Ryzen 5 4600H, while it takes about
1.3 minutes on my NVIDIA GTX 1650
Haar shader has a subgroup optimized variant that applies when configured
wavelet depth allows it
---
configure| 1 +
libavcodec/Makefile | 3 +
libavcodec/allcodecs.c | 1 +
libavcodec/vc2enc.c | 2 +-
libavcodec/vc2enc_vulkan.c | 777 +++
libavcodec/vulkan/vc2_dwt_haar.comp | 82 ++
libavcodec/vulkan/vc2_dwt_haar_subgroup.comp | 75 ++
libavcodec/vulkan/vc2_dwt_hor_legall.comp| 82 ++
libavcodec/vulkan/vc2_dwt_upload.comp| 96 +++
libavcodec/vulkan/vc2_dwt_ver_legall.comp| 78 ++
libavcodec/vulkan/vc2_encode.comp| 173 +
libavcodec/vulkan/vc2_slice_sizes.comp | 170
12 files changed, 1539 insertions(+), 1 deletion(-)
create mode 100644 libavcodec/vc2enc_vulkan.c
create mode 100644 libavcodec/vulkan/vc2_dwt_haar.comp
create mode 100644 libavcodec/vulkan/vc2_dwt_haar_subgroup.comp
create mode 100644 libavcodec/vulkan/vc2_dwt_hor_legall.comp
create mode 100644 libavcodec/vulkan/vc2_dwt_upload.comp
create mode 100644 libavcodec/vulkan/vc2_dwt_ver_legall.comp
create mode 100644 libavcodec/vulkan/vc2_encode.comp
create mode 100644 libavcodec/vulkan/vc2_slice_sizes.comp
diff --git a/configure b/configure
index 2e69b3c56c..09f9dff258 100755
--- a/configure
+++ b/configure
@@ -3132,6 +3132,7 @@ utvideo_encoder_select="bswapdsp huffman llvidencdsp"
vble_decoder_select="llviddsp"
vbn_decoder_select="texturedsp"
vbn_encoder_select="texturedspenc"
+vc2_vulkan_encoder_select="vulkan spirv_compiler"
vmix_decoder_select="idctdsp"
vc1_decoder_select="blockdsp h264qpel intrax8 mpegvideodec qpeldsp vc1dsp"
vc1image_decoder_select="vc1_decoder"
diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index bdf0d6742e..20968520d7 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -772,6 +772,9 @@ OBJS-$(CONFIG_VC1_MMAL_DECODER)+= mmaldec.o
OBJS-$(CONFIG_VC1_QSV_DECODER) += qsvdec.o
OBJS-$(CONFIG_VC1_V4L2M2M_DECODER) += v4l2_m2m_dec.o
OBJS-$(CONFIG_VC2_ENCODER) += vc2enc.o vc2enc_dwt.o
vc2enc_common.o diractab.o
+OBJS-$(CONFIG_VC2_VULKAN_ENCODER) += vc2enc_vulkan.o vulkan/vc2_encode.o
vulkan/vc2_slice_sizes.o \
+ vulkan/vc2_dwt_hor_legall.o
vulkan/vc2_dwt_ver_legall.o \
+ vulkan/vc2_dwt_upload.o
vulkan/vc2_dwt_haar.o vulkan/vc2_dwt_haar_subgroup.o
OBJS-$(CONFIG_VCR1_DECODER)+= vcr1.o
OBJS-$(CONFIG_VMDAUDIO_DECODER)+= vmdaudio.o
OBJS-$(CONFIG_VMDVIDEO_DECODER)+= vmdvideo.o
diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
index cd4f6ecd59..cd23a9490c 100644
--- a/libavcodec/allcodecs.c
+++ b/libavcodec/allcodecs.c
@@ -367,6 +367,7 @@ extern const FFCodec ff_vc1_mmal_decoder;
extern const FFCodec ff_vc1_qsv_decoder;
extern const FFCodec ff_vc1_v4l2m2m_decoder;
extern const FFCodec ff_vc2_encoder;
+extern const FFCodec ff_vc2_vulkan_encoder;
extern const FFCodec ff_vcr1_decoder;
extern const FFCodec ff_vmdvideo_decoder;
extern const FFCodec ff_vmix_decoder;
diff --git a/libavcodec/vc2enc.c b/libavcodec/vc2enc.c
index 22a5a1b97c..d0147ee21d 100644
--- a/libavcodec/vc2enc.c
+++ b/libavcodec/vc2enc.c
@@ -581,7 +581,7 @@ static const AVOption vc2enc_options[] = {
{"slice_width", "Slice width", offsetof(VC2EncContext, slice_width),
AV_OPT_TYPE_INT, {.i64 = 32}, 32, 1024, VC2ENC_FLAGS, .unit = "slice_width"},
{"slice_height", "Slice height", offsetof(VC2EncContext, slice_height),
AV_OPT_TYPE_INT, {.i64 = 16}, 8, 1024, VC2ENC_FLAGS, .unit = "slice_height"},
{"wavelet_depth", "Transform depth", offsetof(VC2EncContext,
wavelet_depth), AV_OPT_TYPE_INT, {.i64 = 4}, 1, 5, VC2ENC_FLAGS, .unit =
"wavelet_depth"},
-{"wavelet_type", "Transform type", offsetof(VC2EncContext, wavelet_idx),
AV_OPT_TYPE_INT, {.i64 = VC2_TRANSFORM_9_7}, 0, VC2_TRANSFORMS_NB,
VC2ENC_FLAGS, .unit = "wavelet_idx"},
+{"wavelet_type", "Transform type", offsetof(VC2EncContext, wavelet_idx),
AV_OPT_TYPE_INT, {.i64 = VC2_TRANSFORM_5_3}, 0, VC2_TRANSFORMS_NB,
VC2ENC_FLAGS, .unit = "wavelet_idx"},
{"9_7", "Deslauriers-Dubuc (9,7)", 0, AV_OPT_TYPE_CONST,
{.i64 = VC2_TRANSFORM_9_7},INT_MIN, INT_MAX, VC2ENC_FLAGS, .unit =
"wavelet_idx"},
{"5_3", "LeGall (5,3)",0, AV_OPT_TYPE_CONST,
{.i64 = VC2_TRANSFORM_5_3},INT_MIN, INT_MAX, VC2ENC_FLAGS, .unit =
"wavelet_idx"},
{"haar", "Haar (with shift)", 0, AV_OPT_TYPE_CONST,
{.i64 = VC2_TRANSFORM_HAAR_S}, INT_MIN, INT_MAX, VC2ENC_FLAGS, .unit =
"wavelet_idx"},
diff --git a/libavcodec/vc2enc_vulkan.c b/
[FFmpeg-devel] [PATCH v5 1/4] libavcodec/vc2enc: Split out common functions between software and hardware encoders
From: IndecisiveTurtle
---
libavcodec/Makefile| 2 +-
libavcodec/vc2enc.c| 669 ++---
libavcodec/vc2enc_common.c | 571 +++
libavcodec/vc2enc_common.h | 168 ++
4 files changed, 765 insertions(+), 645 deletions(-)
create mode 100644 libavcodec/vc2enc_common.c
create mode 100644 libavcodec/vc2enc_common.h
diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index 77734dff24..bdf0d6742e 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -771,7 +771,7 @@ OBJS-$(CONFIG_VC1_CUVID_DECODER) += cuviddec.o
OBJS-$(CONFIG_VC1_MMAL_DECODER)+= mmaldec.o
OBJS-$(CONFIG_VC1_QSV_DECODER) += qsvdec.o
OBJS-$(CONFIG_VC1_V4L2M2M_DECODER) += v4l2_m2m_dec.o
-OBJS-$(CONFIG_VC2_ENCODER) += vc2enc.o vc2enc_dwt.o diractab.o
+OBJS-$(CONFIG_VC2_ENCODER) += vc2enc.o vc2enc_dwt.o
vc2enc_common.o diractab.o
OBJS-$(CONFIG_VCR1_DECODER)+= vcr1.o
OBJS-$(CONFIG_VMDAUDIO_DECODER)+= vmdaudio.o
OBJS-$(CONFIG_VMDVIDEO_DECODER)+= vmdvideo.o
diff --git a/libavcodec/vc2enc.c b/libavcodec/vc2enc.c
index 99ca95c40a..22a5a1b97c 100644
--- a/libavcodec/vc2enc.c
+++ b/libavcodec/vc2enc.c
@@ -30,80 +30,12 @@
#include "put_bits.h"
#include "version.h"
-#include "vc2enc_dwt.h"
-#include "diractab.h"
-
-/* The limited size resolution of each slice forces us to do this */
-#define SSIZE_ROUND(b) (FFALIGN((b), s->size_scaler) + 4 + s->prefix_bytes)
+#include "vc2enc_common.h"
/* Decides the cutoff point in # of slices to distribute the leftover bytes */
#define SLICE_REDIST_TOTAL 150
-typedef struct VC2BaseVideoFormat {
-enum AVPixelFormat pix_fmt;
-AVRational time_base;
-int width, height;
-uint8_t interlaced, level;
-char name[13];
-} VC2BaseVideoFormat;
-
-static const VC2BaseVideoFormat base_video_fmts[] = {
-{ 0 }, /* Custom format, here just to make indexing equal to base_vf */
-{ AV_PIX_FMT_YUV420P, { 1001, 15000 }, 176, 120, 0, 1, "QSIF525" },
-{ AV_PIX_FMT_YUV420P, {2,25 }, 176, 144, 0, 1, "QCIF"},
-{ AV_PIX_FMT_YUV420P, { 1001, 15000 }, 352, 240, 0, 1, "SIF525" },
-{ AV_PIX_FMT_YUV420P, {2,25 }, 352, 288, 0, 1, "CIF" },
-{ AV_PIX_FMT_YUV420P, { 1001, 15000 }, 704, 480, 0, 1, "4SIF525" },
-{ AV_PIX_FMT_YUV420P, {2,25 }, 704, 576, 0, 1, "4CIF"},
-
-{ AV_PIX_FMT_YUV422P10, { 1001, 3 }, 720, 480, 1, 2, "SD480I-60" },
-{ AV_PIX_FMT_YUV422P10, {1,25 }, 720, 576, 1, 2, "SD576I-50" },
-
-{ AV_PIX_FMT_YUV422P10, { 1001, 6 }, 1280, 720, 0, 3, "HD720P-60" },
-{ AV_PIX_FMT_YUV422P10, {1,50 }, 1280, 720, 0, 3, "HD720P-50" },
-{ AV_PIX_FMT_YUV422P10, { 1001, 3 }, 1920, 1080, 1, 3, "HD1080I-60" },
-{ AV_PIX_FMT_YUV422P10, {1,25 }, 1920, 1080, 1, 3, "HD1080I-50" },
-{ AV_PIX_FMT_YUV422P10, { 1001, 6 }, 1920, 1080, 0, 3, "HD1080P-60" },
-{ AV_PIX_FMT_YUV422P10, {1,50 }, 1920, 1080, 0, 3, "HD1080P-50" },
-
-{ AV_PIX_FMT_YUV444P12, {1,24 }, 2048, 1080, 0, 4,"DC2K" },
-{ AV_PIX_FMT_YUV444P12, {1,24 }, 4096, 2160, 0, 5,"DC4K" },
-
-{ AV_PIX_FMT_YUV422P10, { 1001, 6 }, 3840, 2160, 0, 6, "UHDTV 4K-60" },
-{ AV_PIX_FMT_YUV422P10, {1,50 }, 3840, 2160, 0, 6, "UHDTV 4K-50" },
-
-{ AV_PIX_FMT_YUV422P10, { 1001, 6 }, 7680, 4320, 0, 7, "UHDTV 8K-60" },
-{ AV_PIX_FMT_YUV422P10, {1,50 }, 7680, 4320, 0, 7, "UHDTV 8K-50" },
-
-{ AV_PIX_FMT_YUV422P10, { 1001, 24000 }, 1920, 1080, 0, 3, "HD1080P-24" },
-{ AV_PIX_FMT_YUV422P10, { 1001, 3 }, 720, 486, 1, 2, "SD Pro486" },
-};
-static const int base_video_fmts_len = FF_ARRAY_ELEMS(base_video_fmts);
-
-enum VC2_QM {
-VC2_QM_DEF = 0,
-VC2_QM_COL,
-VC2_QM_FLAT,
-
-VC2_QM_NB
-};
-
-typedef struct SubBand {
-dwtcoef *buf;
-ptrdiff_t stride;
-int width;
-int height;
-} SubBand;
-
-typedef struct Plane {
-SubBand band[MAX_DWT_LEVELS][4];
-dwtcoef *coef_buf;
-int width;
-int height;
-int dwt_width;
-int dwt_height;
-ptrdiff_t coef_stride;
-} Plane;
+#define QUANT(c, mul, add, shift) (((mul) * (c) + (add)) >> (shift))
typedef struct SliceArgs {
const struct VC2EncContext *ctx;
@@ -119,418 +51,6 @@ typedef struct SliceArgs {
int bytes;
} SliceArgs;
-typedef struct TransformArgs {
-const struct VC2EncContext *ctx;
-Plane *plane;
-const void *idata;
-ptrdiff_t istride;
-int field;
-VC2TransformContext t;
-} TransformArgs;
-
-typedef struct VC2EncContext {
-AVClass *av_class;
-PutBitContext pb;
-Plane plane[3];
-AVCodecContext *avctx;
-DiracVersionInfo ver;
-
-SliceArgs *slice_args;
-TransformArgs transform_args[3];
-
-/* For conversion from unsigned pixel values to signed */
-int diff_offset;
-
[FFmpeg-devel] [PATCH v5 3/4] libavcodec/vulkan: Add modifications to common shader for VC2 vulkan encoder
From: IndecisiveTurtle
---
libavcodec/vulkan/common.comp | 51 ---
1 file changed, 41 insertions(+), 10 deletions(-)
diff --git a/libavcodec/vulkan/common.comp b/libavcodec/vulkan/common.comp
index 10af9c0623..59a4a4b1a8 100644
--- a/libavcodec/vulkan/common.comp
+++ b/libavcodec/vulkan/common.comp
@@ -18,6 +18,9 @@
* Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
*/
+#extension GL_EXT_buffer_reference : require
+#extension GL_EXT_buffer_reference2 : require
+
layout(buffer_reference, buffer_reference_align = 1) buffer u8buf {
uint8_t v;
};
@@ -61,22 +64,20 @@ layout(buffer_reference, buffer_reference_align = 8) buffer
u64buf {
#define mid_pred(a, b, c) \
max(min((a), (b)), min(max((a), (b)), (c)))
-/* TODO: optimize */
+
uint align(uint src, uint a)
{
-uint res = src % a;
-if (res == 0)
-return src;
-return src + a - res;
+return (src + a - 1) & ~(a - 1);
+}
+
+int align(int src, int a)
+{
+return (src + a - 1) & ~(a - 1);
}
-/* TODO: optimize */
uint64_t align64(uint64_t src, uint64_t a)
{
-uint64_t res = src % a;
-if (res == 0)
-return src;
-return src + a - res;
+return (src + a - 1) & ~(a - 1);
}
#define reverse4(src) \
@@ -146,6 +147,36 @@ void put_bits(inout PutBitContext pb, const uint32_t n,
uint32_t value)
}
}
+void put_bits63(inout PutBitContext pb, const uint32_t n, uint64_t value)
+{
+if (n < pb.bit_left) {
+pb.bit_buf = (pb.bit_buf << n) | value;
+pb.bit_left -= uint8_t(n);
+} else {
+pb.bit_buf <<= pb.bit_left;
+pb.bit_buf |= (value >> (n - pb.bit_left));
+
+#ifdef PB_UNALIGNED
+u8buf bs = u8buf(pb.buf);
+[[unroll]]
+for (uint8_t i = uint8_t(0); i < BUF_BYTES; i++)
+bs[i].v = BYTE_EXTRACT(pb.bit_buf, BUF_BYTES - uint8_t(1) - i);
+#else
+#ifdef DEBUG
+if ((pb.buf % BUF_BYTES) != 0)
+debugPrintfEXT("put_bits buffer is not aligned!");
+#endif
+
+BUF_TYPE bs = BUF_TYPE(pb.buf);
+bs.v = BUF_REVERSE(pb.bit_buf);
+#endif
+pb.buf = uint64_t(bs) + BUF_BYTES;
+
+pb.bit_left += BUF_BITS - uint8_t(n);
+pb.bit_buf = value;
+}
+}
+
uint32_t flush_put_bits(inout PutBitContext pb)
{
/* Align bits to MSBs */
--
2.49.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avformat/sdp: add framerate entry
On 23 May 2025, at 20:53, Michael Niedermayer wrote:
> Hi Marvin
>
> On Fri, May 23, 2025 at 02:11:24AM +0200, Marvin Scholz wrote:
>> ---
>> libavformat/sdp.c | 3 +++
>> 1 file changed, 3 insertions(+)
>>
>> diff --git a/libavformat/sdp.c b/libavformat/sdp.c
>> index 215e38f8fc..21ada5d1ce 100644
>> --- a/libavformat/sdp.c
>> +++ b/libavformat/sdp.c
>> @@ -867,6 +867,9 @@ int ff_sdp_write_media(char *buff, int size, const
>> AVStream *st, int idx,
>> if (p->bit_rate) {
>> av_strlcatf(buff, size, "b=AS:%"PRId64"\r\n", p->bit_rate / 1000);
>> }
>> +if (p->framerate.num > 0 && p->framerate.den > 0) {
>> +av_strlcatf(buff, size, "a=framerate:%g\r\n", av_q2d(p->framerate));
>> +}
>>
>> return sdp_write_media_attributes(buff, size, st, payload_type, fmt);
>> }
>> --
>> 2.39.5 (Apple Git-154)
>
> breaks fate:
>
> TESTlavf-mov_rtphint
> --- ./tests/ref/lavf/mov_rtphint 2025-05-23 14:14:31.476447585 +0200
> +++ tests/data/fate/lavf-mov_rtphint 2025-05-23 20:51:14.221038582 +0200
> @@ -1,3 +1,3 @@
> -d3d0b0a15e2207e1d69b7de5c0ff845c *tests/data/lavf/lavf.mov_rtphint
> -365745 tests/data/lavf/lavf.mov_rtphint
> +e5e994cd3885a28304229f5e277c1917 *tests/data/lavf/lavf.mov_rtphint
> +365761 tests/data/lavf/lavf.mov_rtphint
> tests/data/lavf/lavf.mov_rtphint CRC=0xbb2b949b
> Test lavf-mov_rtphint failed. Look at tests/data/fate/lavf-mov_rtphint.err
> for details.
> make: *** [tests/Makefile:316: fate-lavf-mov_rtphint] Error 1
>
Indeed it changed because it includes the SDP. Sent a new version that updates
the
ref accordingly.
> [...]
>
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> Many that live deserve death. And some that die deserve life. Can you give
> it to them? Then do not be too eager to deal out death in judgement. For
> even the very wise cannot see all ends. -- Gandalf
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v2] avformat/sdp: add framerate entry
This also updates fate-lavf-mov_rtphint as there the SDP
is included in the muxed file.
---
libavformat/sdp.c | 3 +++
tests/ref/lavf/mov_rtphint | 4 ++--
2 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/libavformat/sdp.c b/libavformat/sdp.c
index 215e38f8fc..21ada5d1ce 100644
--- a/libavformat/sdp.c
+++ b/libavformat/sdp.c
@@ -867,6 +867,9 @@ int ff_sdp_write_media(char *buff, int size, const AVStream
*st, int idx,
if (p->bit_rate) {
av_strlcatf(buff, size, "b=AS:%"PRId64"\r\n", p->bit_rate / 1000);
}
+if (p->framerate.num > 0 && p->framerate.den > 0) {
+av_strlcatf(buff, size, "a=framerate:%g\r\n", av_q2d(p->framerate));
+}
return sdp_write_media_attributes(buff, size, st, payload_type, fmt);
}
diff --git a/tests/ref/lavf/mov_rtphint b/tests/ref/lavf/mov_rtphint
index 1d5e720351..b4256a861b 100644
--- a/tests/ref/lavf/mov_rtphint
+++ b/tests/ref/lavf/mov_rtphint
@@ -1,3 +1,3 @@
-d3d0b0a15e2207e1d69b7de5c0ff845c *tests/data/lavf/lavf.mov_rtphint
-365745 tests/data/lavf/lavf.mov_rtphint
+e5e994cd3885a28304229f5e277c1917 *tests/data/lavf/lavf.mov_rtphint
+365761 tests/data/lavf/lavf.mov_rtphint
tests/data/lavf/lavf.mov_rtphint CRC=0xbb2b949b
--
2.39.5 (Apple Git-154)
___
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] Percent-encode URL paths in HLS playlists
On Fri, 23 May 2025, Timothy Allen via ffmpeg-devel wrote:
This commit closes trac ticket 10679.
And what if the M3U8 is referencing absolute URLs with scheme? Or is using
a data URI? Or if it is a local DOS path? What if the URL is already
percent encoded?
This issue is not trivial to fix, so I really meant it when I wrote that
its worth checking what heuristics other software is using for this issue.
Thanks,
Marton
Signed-off-by: Timothy Allen
---
libavformat/hls.c | 9 +
libavformat/url.c | 35 +++
libavformat/url.h | 9 +
3 files changed, 53 insertions(+)
diff --git a/libavformat/hls.c b/libavformat/hls.c
index c7b655c83c..49436d8184 100644
--- a/libavformat/hls.c
+++ b/libavformat/hls.c
@@ -1021,6 +1021,15 @@ static int parse_playlist(HLSContext *c, const char *url,
seg->key = NULL;
}
+ff_percent_encode_url(tmp_str, sizeof(tmp_str), line);
+if (!tmp_str[0]) {
+ret = AVERROR_INVALIDDATA;
+if (seg->key)
+av_free(seg->key);
+av_free(seg);
+goto fail;
+}
+strcpy(line, av_strdup(tmp_str));
ff_make_absolute_url(tmp_str, sizeof(tmp_str), url, line);
if (!tmp_str[0]) {
ret = AVERROR_INVALIDDATA;
diff --git a/libavformat/url.c b/libavformat/url.c
index d5dd6a4666..69d68d4248 100644
--- a/libavformat/url.c
+++ b/libavformat/url.c
@@ -324,6 +324,41 @@ int ff_make_absolute_url(char *buf, int size, const char
*base,
return ff_make_absolute_url2(buf, size, base, rel, HAVE_DOS_PATHS);
}
+int ff_percent_encode_url(char *buf, int size, const char *url)
+{
+const char *hex = "0123456789abcdef";
+
+av_assert0(url);
+
+int p = 0;
+int len = strlen(url);
+for (int i = 0; i < len; i++) {
+if (i + 1 < len && ':' == url[i] && '/' == url[i+1])
+buf[p++] = url[i];
+else if (('a' <= url[i] && url[i] <= 'z')
+ || ('A' <= url[i] && url[i] <= 'Z')
+ || ('0' <= url[i] && url[i] <= '9')
+ || '/' == url[i] || '.' == url[i] || '~' == url[i]
+ || '-' == url[i] || '_' == url[i] || '+' == url[i]
+ || '?' == url[i] || '=' == url[i] || '&' == url[i]
+ || '#' == url[i])
+{
+buf[p++] = url[i];
+} else if (' ' == url[i])
+{
+buf[p++] = '+';
+} else
+{
+buf[p++] = '%';
+buf[p++] = hex[url[i] >> 4];
+buf[p++] = hex[url[i] & 15];
+}
+}
+buf[p] = '\0';
+
+return 0;
+}
+
AVIODirEntry *ff_alloc_dir_entry(void)
{
AVIODirEntry *entry = av_mallocz(sizeof(AVIODirEntry));
diff --git a/libavformat/url.h b/libavformat/url.h
index 0784d77b64..85f94f06ce 100644
--- a/libavformat/url.h
+++ b/libavformat/url.h
@@ -331,6 +331,15 @@ int ff_make_absolute_url2(char *buf, int size, const char
*base,
int ff_make_absolute_url(char *buf, int size, const char *base,
const char *rel);
+/**
+ * Percent-encode a URL, to avoid it being incorrectly parsed.
+ *
+ * @param buf the buffer where output absolute url is written
+ * @param size the size of buf
+ * @param url the url to encode
+ */
+int ff_percent_encode_url(char *buf, int size, const char *url);
+
/**
* Allocate directory entry with default values.
*
--
2.43.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
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 v5 2/4] libavcodec/vc2enc: Switch quant to int
From: IndecisiveTurtle
Prevents compiler from mistaking it as a string
Also makes passing it to the GPU in a buffer easier
---
libavcodec/vc2enc_common.c | 2 +-
libavcodec/vc2enc_common.h | 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/libavcodec/vc2enc_common.c b/libavcodec/vc2enc_common.c
index bb24711eb2..5549eae1c1 100644
--- a/libavcodec/vc2enc_common.c
+++ b/libavcodec/vc2enc_common.c
@@ -304,7 +304,7 @@ static const uint8_t vc2_qm_flat_tab[][4] = {
{ 0, 0, 0, 0}
};
-void ff_vc2_init_quant_matrix(VC2EncContext *s, uint8_t
quant[MAX_DWT_LEVELS][4])
+void ff_vc2_init_quant_matrix(VC2EncContext *s, int quant[MAX_DWT_LEVELS][4])
{
int level, orientation;
diff --git a/libavcodec/vc2enc_common.h b/libavcodec/vc2enc_common.h
index 41f555c496..929e0e49ea 100644
--- a/libavcodec/vc2enc_common.h
+++ b/libavcodec/vc2enc_common.h
@@ -94,7 +94,7 @@ typedef struct VC2EncContext {
int profile;
/* Quantization matrix */
-uint8_t quant[MAX_DWT_LEVELS][4];
+int quant[MAX_DWT_LEVELS][4];
int custom_quant_matrix;
/* Division LUT */
@@ -159,7 +159,7 @@ void ff_vc2_write_frame_header(VC2EncContext *s);
void ff_vc2_write_sequence_end(VC2EncContext *s);
-void ff_vc2_init_quant_matrix(VC2EncContext *s, uint8_t
quant[MAX_DWT_LEVELS][4]);
+void ff_vc2_init_quant_matrix(VC2EncContext *s, int quant[MAX_DWT_LEVELS][4]);
void ff_vc2_encode_frame(VC2EncContext *s,
void(*encode_slices)(VC2EncContext*));
--
2.49.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] STF RaptorQ
Hi Kieran On Fri, May 23, 2025 at 04:45:53PM +0100, Kieran Kunhya via ffmpeg-devel wrote: > On Fri, May 23, 2025 at 4:00 PM Kieran Kunhya > wrote: > > > > On Fri, May 23, 2025 at 3:50 PM Devin Heitmueller > > wrote: > > > > > > Hello Michael, > > > > > > On Fri, May 23, 2025 at 5:45 AM Michael Niedermayer > > > wrote: > > > > On Thu, May 22, 2025 at 07:55:40PM -0400, Devin Heitmueller wrote: > > > > > On Thu, May 22, 2025 at 7:42 PM Kieran Kunhya via ffmpeg-devel > > > > > wrote: > > > > > > I wanted to put on the record that adding RaptorQ to FFmpeg isn't > > > > > > maintenance of FFmpeg. > > > > > > > > i agree adding RaptorQ itself is probably not maintenance > > > > > > Ok, so that much everybody seems to agree on. Great. > > > > > > > > > It's adding an obscure FEC protocol to FFmpeg, > > > > > > > > tornado and raptor codes are not obscure. > > > > and FFmpeg supports hundreads of much more obscure things > > > > > > Sure, no disagreement there. While I've personally never used any of > > > the codecs that support video games from the 1990's, I don't really > > > have any problem with them being in ffmpeg. That said, in my opinion, > > > I doubt STF would really think it's a good use of their funds to add > > > support for new codecs for such games. > > > > > > > > I'm not sure I've seen any commercial gear that does RaptorQ for FEC, > > > > > so it's not clear what the use cases are if the goal is > > > > > interoperability. > > > > > > > > its IMHO for communication between tools that on both sides > > > > use our software > > > > > > > > If no commercial gear uses a reliable FEC system all teh better > > > > for us > > > > > > Wow, that's quite a leap to suggest that because there aren't open > > > standards using RaptorQ that there isn't commercial video transmission > > > gear out there that doesn't do a good job with FEC. > > > > > > > > If somebody really wants to be paid to work on > > > > > reliable transport protocols, the time would be better spent improving > > > > > the RIST or SRT integration, which is where most of the industry is > > > > > putting their energy. > > > > > > > > FEC is supperior to ARQ > > > > for ARQ, each receiver needs to request the lost packet > > > > while for FEC the sender just needs to know or guess how many packets > > > > where lost. > > > > 1. FEC is lower latency > > This isn't true. You need a large FEC matrix to handle burst packet > loss and you have to buffer for the duration of this matrix. > At low bitrates this duration can be really long. (100 packets at > 1mbit/s is already roughly a second). Even with this constructed example, FEC is lower latency than no FEC lets take your 1mbit/sec and your 100packets a second, that makes 10kbit per packet with retransmission we will request a retransmission once we reasonably know a packet is lost, but we will not be sure because sometimes a packet is just late or out of order so we at the very least will have to wait for the next packet to come in but in reality maybe we wait an extra one to conserve bandwidth and not request a reatransmit of every out of order packet. We will also end up asking for packets that we actually do receive later, these will waste bandwidth with FEC lets say we have 1 extra parity packet every 20 packets, but you can pick other numbers now we do the same, we ask for a retransmission at the same time as before. BUT and thats the crucial difference we dont need to ask for a specific packet we just ask for how many we are currently missing Lets pick actual random numbers: Packets 1, 3, 2, 4, 5, 8, 6, 9, 10 ARQ: R2 R6R7 (you can make this burst arbitrary long) FEC: R1 R2 Now the differnce are multiple First the parity packet send for R1 will not just include packets up to 3 but instead up to the point the sender has them at the time it sends the parity packet so this packet may include packet 6 or 7. Similarly when the receiver requests 2 parity packets seeing 8 without 6 and 7 by the time the receiver receives the first parity packet it will have received packet 6 and not need to wait for the 2nd one again there is a CLEAR advantage over ARQ in lower latency and we have NOT even used the 1/20 parity we get by default you can make teh burst as long as you want, theres an advanatge for FEC * If a packet is received after its retransmission is requested * If any transmitted by default parity packets cover the range * If any previous requested parity happens to cover any part of the burst Now i dont expect that iam the first to suggest this system above, but maybe i am. Also above is just what i came up with in 15min, i expect if some mathematicans think about this they will find more ways to reduce latency with FEC. Giving one an extra optional tool cant make the optimal solution worse, it can make it better though. thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Its not that you
[FFmpeg-devel] [PATCH v4] ffbuild/commonmak: Fix rebuild check with implicit rule chains
From: softworkz When there's a chain of implicit rules, make treats files generated inside that chain as intermediate files. Those intermediate files are removed after completion of make. When make is run again, it normally determines the need for a rebuild by comparing the timestamps of the original source file and the final output of the chain and if still up-to-date, it doesn't rebuild, even when the intermediate files are not present. That makes sense of course - why would it delete them otherwise, it would end up in builds being never up-to-date. But this original by-the-book logic appeared to be broken and has been worked around by adding all intermediate files to the .SECONDARY special target, which required extra logic and issues with make clean. What broke the up-to-date checking is the dependency file generation. For the .c files generated by BIN2C the compile target created a .d file which indicated that the .ptx.o file has a dependency on the ptx.c file. And that dependency broke the normal make behavior with intermediate files. This patch compiles the BIN2C generated .c files without generating .d files. In turn the files do not longer need to be added to the .SECONDARY target in common.mak. When interested in those files for debugging, a line can be added to the corresponding Makefile like .SECONDARY: %.ptx.c %.ptx.gz Signed-off-by: softworkz --- ffbuild/commonmak: Fix rebuild check with implicit rule chains V2 == * Fix MSVC build (use the universal command pattern) V3 == * Skip dependency generation by clearing CC_DEPS instead (as suggested by Ramiro - thanks!) V4 == * Always keep .ptx files (as suggested by Timo - thanks) Tested all scenarios: * .ptx.c and .ptx.gz still get deleted (as intermediates) * repeated make shows "up-to-date" * removing a .ptx file does not cause a rebuild (it's still an intermediate, but an "intermediate to keep") * but changing a .ptx does (in case of dev/debugging) * changed .cu files always rebuild of course . Published-As: https://github.com/ffstaging/FFmpeg/releases/tag/pr-ffstaging-80%2Fsoftworkz%2Fsubmit_commonmak-v4 Fetch-It-Via: git fetch https://github.com/ffstaging/FFmpeg pr-ffstaging-80/softworkz/submit_commonmak-v4 Pull-Request: https://github.com/ffstaging/FFmpeg/pull/80 Range-diff vs v3: 1: 981329e5d9 ! 1: 20c2fb65ed ffbuild/commonmak: Fix rebuild check with implicit rule chains @@ ffbuild/common.mak: else # NO COMPRESSION clean:: $(RM) $(BIN2CEXE) $(CLEANSUFFIXES:%=ffbuild/%) -@@ ffbuild/common.mak: ALLHEADERS := $(subst $(SRC_DIR)/,$(SUBDIR),$(wildcard $(SRC_DIR)/*.h $(SRC_DIR) - SKIPHEADERS += $(ARCH_HEADERS:%=$(ARCH)/%) $(SKIPHEADERS-) +@@ ffbuild/common.mak: SKIPHEADERS += $(ARCH_HEADERS:%=$(ARCH)/%) $(SKIPHEADERS-) SKIPHEADERS := $(SKIPHEADERS:%=$(SUBDIR)%) HOBJS= $(filter-out $(SKIPHEADERS:.h=.h.o),$(ALLHEADERS:.h=.h.o)) --PTXOBJS = $(filter %.ptx.o,$(OBJS)) + PTXOBJS = $(filter %.ptx.o,$(OBJS)) -RESOURCEOBJS = $(filter %.css.o %.html.o,$(OBJS)) $(HOBJS): CCFLAGS += $(CFLAGS_HEADERS) checkheaders: $(HOBJS) -.SECONDARY: $(HOBJS:.o=.c) $(PTXOBJS:.o=.c) $(PTXOBJS:.o=.gz) $(PTXOBJS:.o=) $(RESOURCEOBJS:.o=.c) $(RESOURCEOBJS:%.css.o=%.css.min) $(RESOURCEOBJS:%.css.o=%.css.min.gz) $(RESOURCEOBJS:%.html.o=%.html.gz) $(RESOURCEOBJS:.o=) -+.SECONDARY: $(HOBJS:.o=.c) ++.SECONDARY: $(HOBJS:.o=.c) $(PTXOBJS:.o=) alltools: $(TOOLS) ffbuild/common.mak | 11 +-- 1 file changed, 9 insertions(+), 2 deletions(-) diff --git a/ffbuild/common.mak b/ffbuild/common.mak index 0e1eb1f62b..f03b9ca051 100644 --- a/ffbuild/common.mak +++ b/ffbuild/common.mak @@ -139,6 +139,10 @@ else $(BIN2C) $(patsubst $(SRC_PATH)/%,$(SRC_LINK)/%,$<) $@ $(subst .,_,$(basename $(notdir $@))) endif +%.ptx.o: CCDEP = +%.ptx.o: CC_DEPFLAGS = + + # 1) Preprocess CSS to a minified version %.css.min: %.css # Must start with a tab in the real Makefile @@ -177,6 +181,10 @@ else # NO COMPRESSION $(BIN2C) $< $@ $(subst .,_,$(basename $(notdir $@))) endif +%.html.o %.css.o: CCDEP = +%.html.o %.css.o: CC_DEPFLAGS = + + clean:: $(RM) $(BIN2CEXE) $(CLEANSUFFIXES:%=ffbuild/%) @@ -229,10 +237,9 @@ SKIPHEADERS += $(ARCH_HEADERS:%=$(ARCH)/%) $(SKIPHEADERS-) SKIPHEADERS := $(SKIPHEADERS:%=$(SUBDIR)%) HOBJS= $(filter-out $(SKIPHEADERS:.h=.h.o),$(ALLHEADERS:.h=.h.o)) PTXOBJS = $(filter %.ptx.o,$(OBJS)) -RESOURCEOBJS = $(filter %.css.o %.html.o,$(OBJS)) $(HOBJS): CCFLAGS += $(CFLAGS_HEADERS) checkheaders: $(HOBJS) -.SECONDARY: $(HOBJS:.o=.c) $(PTXOBJS:.o=.c) $(PTXOBJS:.o=.gz) $(PTXOBJS:.o=) $(RESOURCEOBJS:.o=.c) $(RESOURCEOBJS:%.css.o=%.css.min) $(RESOURCEOBJS:%.css.o=%.css.min.gz)
Re: [FFmpeg-devel] STF RaptorQ
On Fri, 23 May 2025, 21:35 Michael Niedermayer, wrote: > Hi Kieran > > On Fri, May 23, 2025 at 04:45:53PM +0100, Kieran Kunhya via ffmpeg-devel > wrote: > > On Fri, May 23, 2025 at 4:00 PM Kieran Kunhya > wrote: > > > > > > On Fri, May 23, 2025 at 3:50 PM Devin Heitmueller > > > wrote: > > > > > > > > Hello Michael, > > > > > > > > On Fri, May 23, 2025 at 5:45 AM Michael Niedermayer > > > > wrote: > > > > > On Thu, May 22, 2025 at 07:55:40PM -0400, Devin Heitmueller wrote: > > > > > > On Thu, May 22, 2025 at 7:42 PM Kieran Kunhya via ffmpeg-devel > > > > > > wrote: > > > > > > > I wanted to put on the record that adding RaptorQ to FFmpeg > isn't > > > > > > > maintenance of FFmpeg. > > > > > > > > > > i agree adding RaptorQ itself is probably not maintenance > > > > > > > > Ok, so that much everybody seems to agree on. Great. > > > > > > > > > > > It's adding an obscure FEC protocol to FFmpeg, > > > > > > > > > > tornado and raptor codes are not obscure. > > > > > and FFmpeg supports hundreads of much more obscure things > > > > > > > > Sure, no disagreement there. While I've personally never used any of > > > > the codecs that support video games from the 1990's, I don't really > > > > have any problem with them being in ffmpeg. That said, in my > opinion, > > > > I doubt STF would really think it's a good use of their funds to add > > > > support for new codecs for such games. > > > > > > > > > > I'm not sure I've seen any commercial gear that does RaptorQ for > FEC, > > > > > > so it's not clear what the use cases are if the goal is > > > > > > interoperability. > > > > > > > > > > its IMHO for communication between tools that on both sides > > > > > use our software > > > > > > > > > > If no commercial gear uses a reliable FEC system all teh better > > > > > for us > > > > > > > > Wow, that's quite a leap to suggest that because there aren't open > > > > standards using RaptorQ that there isn't commercial video > transmission > > > > gear out there that doesn't do a good job with FEC. > > > > > > > > > > If somebody really wants to be paid to work on > > > > > > reliable transport protocols, the time would be better spent > improving > > > > > > the RIST or SRT integration, which is where most of the industry > is > > > > > > putting their energy. > > > > > > > > > > FEC is supperior to ARQ > > > > > for ARQ, each receiver needs to request the lost packet > > > > > while for FEC the sender just needs to know or guess how many > packets > > > > > where lost. > > > > > 1. FEC is lower latency > > > > This isn't true. You need a large FEC matrix to handle burst packet > > loss and you have to buffer for the duration of this matrix. > > At low bitrates this duration can be really long. (100 packets at > > 1mbit/s is already roughly a second). > > Even with this constructed example, FEC is lower latency than no FEC > > lets take your 1mbit/sec and your 100packets a second, that makes 10kbit > per packet > > with retransmission we will request a retransmission once we reasonably > know a packet > is lost, but we will not be sure because sometimes a packet is just late > or out of order > so we at the very least will have to wait for the next packet to come in > but in reality maybe > we wait an extra one to conserve bandwidth and not request a reatransmit > of every out of > order packet. > We will also end up asking for packets that we actually do receive later, > these will waste bandwidth > > with FEC lets say we have 1 extra parity packet every 20 packets, but you > can > pick other numbers > now we do the same, we ask for a retransmission at the same time as before. > BUT and thats the crucial difference we dont need to ask for a specific > packet > we just ask for how many we are currently missing > > Lets pick actual random numbers: > > Packets 1, 3, 2, 4, 5, 8, 6, 9, 10 > ARQ: R2 R6R7 (you can make this burst arbitrary > long) > FEC: R1 R2 > > Now the differnce are multiple > First the parity packet send for R1 will not just include packets up to 3 > but instead up to the > point the sender has them at the time it sends the parity packet so this > packet may include > packet 6 or 7. > Similarly when the receiver requests 2 parity packets seeing 8 without 6 > and 7 by the time > the receiver receives the first parity packet it will have received packet > 6 and not > need to wait for the 2nd one > again there is a CLEAR advantage over ARQ in lower latency > and we have NOT even used the 1/20 parity we get by default > > you can make teh burst as long as you want, theres an advanatge for FEC > * If a packet is received after its retransmission is requested > * If any transmitted by default parity packets cover the range > * If any previous requested parity happens to cover any part of the burst > > Now i dont expect that iam the first to suggest this system above, but > maybe i am. > > Also above is just what i came up with in 15min, i expect if some > math
[FFmpeg-devel] [PATCH] avfilter: add CUDA stack filters (hstack_cuda, vstack_cuda, xstack_cuda)
Add hardware-accelerated stack filters for CUDA that provide equivalent
functionality to the software stack filters but with GPU acceleration.
Features:
- Support for hstack, vstack, and xstack operations
- Compatible pixel formats such as:
yuv420p, nv12, yuv444p, p010le, p016le, yuv444p16le, rgb0, bgr0, rgba, bgra
- Fill color support with automatic RGB to YUV conversion for YUV formats
- Proper chroma subsampling handling for all supported formats
- Integration with existing stack filter infrastructure via stack_internal.h
The implementation follows the established CUDA filter pattern from
vf_scale_cuda.c, using PTX modules for kernel execution and proper
CUDA context management. Copy operations handle frame placement while
color operations fill background areas when using fill colors.
This enables efficient video composition workflows entirely on GPU
without CPU-GPU memory transfers, significantly improving performance
for multi-input video processing pipelines.
Examples:
$ ffmpeg -hwaccel cuda -i input.h265 -filter_complex "[0:v][0:v]hstack_cuda"
-c:v hevc_nvenc out.h265
$ ffmpeg \
-hwaccel cuda -i input1.mp4 \
-hwaccel cuda -i input2.mp4 \
-hwaccel cuda -i input3.mp4 \
-hwaccel cuda -i input4.mp4 \
-filter_complex
"[0:v]hwupload_cuda[0v];[1:v]hwupload_cuda[1v];[2:v]hwupload_cuda[2v];[3:v]hwupload_cuda[3v];[0v][1v][2v][3v]xstack_cuda=inputs=4:fill=black:layout=0_0|w0_0|0_h0|w0_h0"
\
-c:v hevc_nvenc out.mp4
Signed-off-by: Faeez Kadiri
---
Changelog| 1 +
configure| 6 +
doc/filters.texi | 78 +
libavfilter/Makefile | 3 +
libavfilter/allfilters.c | 3 +
libavfilter/vf_stack_cuda.c | 589 +++
libavfilter/vf_stack_cuda.cu | 389 +++
7 files changed, 1069 insertions(+)
create mode 100644 libavfilter/vf_stack_cuda.c
create mode 100644 libavfilter/vf_stack_cuda.cu
diff --git a/Changelog b/Changelog
index 4217449438..0dec3443d4 100644
--- a/Changelog
+++ b/Changelog
@@ -18,6 +18,7 @@ version :
- APV encoding support through a libopenapv wrapper
- VVC decoder supports all content of SCC (Screen Content Coding):
IBC (Inter Block Copy), Palette Mode and ACT (Adaptive Color Transform
+- hstack_cuda, vstack_cuda and xstack_cuda filters
version 7.1:
diff --git a/configure b/configure
index 3730b0524c..5c2d6e132d 100755
--- a/configure
+++ b/configure
@@ -4033,6 +4033,12 @@ xfade_vulkan_filter_deps="vulkan spirv_compiler"
yadif_cuda_filter_deps="ffnvcodec"
yadif_cuda_filter_deps_any="cuda_nvcc cuda_llvm"
yadif_videotoolbox_filter_deps="metal corevideo videotoolbox"
+hstack_cuda_filter_deps="ffnvcodec"
+hstack_cuda_filter_deps_any="cuda_nvcc cuda_llvm"
+vstack_cuda_filter_deps="ffnvcodec"
+vstack_cuda_filter_deps_any="cuda_nvcc cuda_llvm"
+xstack_cuda_filter_deps="ffnvcodec"
+xstack_cuda_filter_deps_any="cuda_nvcc cuda_llvm"
hstack_vaapi_filter_deps="vaapi_1"
vstack_vaapi_filter_deps="vaapi_1"
xstack_vaapi_filter_deps="vaapi_1"
diff --git a/doc/filters.texi b/doc/filters.texi
index 6d2df07508..1c9afac9eb 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -26850,6 +26850,84 @@ Only deinterlace frames marked as interlaced.
The default value is @code{all}.
@end table
+@section hstack_cuda
+Stack input videos horizontally.
+
+This is the CUDA variant of the @ref{vstack} filter, each input stream may
+have different width, this filter will scale down/up each input stream while
+keeping the orignal aspect.
+
+It accepts the following options:
+
+@table @option
+@item inputs
+See @ref{hstack}.
+
+@item shortest
+See @ref{hstack}.
+
+@item height
+Set height of output. If set to 0, this filter will set height of output to
+height of the first input stream. Default value is 0.
+@end table
+
+@section vstack_cuda
+Stack input videos vertically.
+
+This is the CUDA variant of the @ref{vstack} filter, each input stream may
+have different width, this filter will scale down/up each input stream while
+keeping the orignal aspect.
+
+It accepts the following options:
+
+@table @option
+@item inputs
+See @ref{vstack}.
+
+@item shortest
+See @ref{vstack}.
+
+@item width
+Set width of output. If set to 0, this filter will set width of output to
+width of the first input stream. Default value is 0.
+@end table
+
+@section xstack_cuda
+Stack video inputs into custom layout.
+
+This is the CUDA variant of the @ref{xstack} filter, each input stream may
+have different size, this filter will scale down/up each input stream to the
+given output size, or the size of the first input stream.
+
+It accepts the following options:
+
+@table @option
+@item inputs
+See @ref{xstack}.
+
+@item shortest
+See @ref{xstack}.
+
+@item layout
+See @ref{xstack}.
+Moreover, this permits the user to supply output size for each input stream.
+@example
+xstack_cuda=inputs=4:layout=0_0_1920x1080|0_h0_1920x1080|w0_0_1920x1080|w0_h0_1920x1080
+@end example
+
+@item grid
+See @ref{xst
Re: [FFmpeg-devel] [PATCH v7 3/4] ogg/vorbis: implement header packet skip in chained ogg bitstreams.
Hi Romain On Wed, May 21, 2025 at 05:05:37PM -0500, Romain Beauxis wrote: > --- > libavcodec/vorbis_parser.h | 11 > libavcodec/vorbisdec.c | 75 +- > libavformat/oggparsevorbis.c | 63 +- > tests/ref/fate/ogg-vorbis-chained-meta.txt | 3 - > 4 files changed, 115 insertions(+), 37 deletions(-) make -j32 libavformat/tests/seek && libavformat/tests/seek ~/tickets/2739/lavf_ogm_seeking_borked.ogm CC libavcodec/libvorbisenc.o CC libavcodec/version.o CC libavcodec/vorbis_parser.o CC libavcodec/vorbisdec.o CC libswresample/version.o CC libavutil/version.o CC libavformat/oggparsevorbis.o CC libavformat/version.o AR libswresample/libswresample.a AR libavutil/libavutil.a AR libavcodec/libavcodec.a AR libavformat/libavformat.a LD libavformat/tests/seek [ogg @ 0x558349c4f3c0] Headers mismatch for stream 1: expected 3 received 2. [ogg @ 0x558349c4f3c0] Headers mismatch for stream 2: expected 3 received 2. ret: 0 st: 0 flags:1 dts:-0.083417 pts: 0.00 pos:887 size: 3347 ret: 0 st:-1 flags:0 ts:-1.00 ret: 0 st: 0 flags:1 dts: 0.00 pts: 0.00 pos:887 size: 3347 ret: 0 st:-1 flags:1 ts: 1.894167 ret: 0 st: 0 flags:1 dts: 0.00 pts: 0.00 pos:887 size: 3347 ret: 0 st: 0 flags:0 ts: 0.792458 ret: 0 st: 1 flags:1 dts: 12.481333 pts: 12.481333 pos:2855209 size: 269 ret: 0 st: 0 flags:1 ts:-0.333666 ret: 0 st: 0 flags:1 dts: 0.00 pts: 0.00 pos:887 size: 3347 ret: 0 st: 1 flags:0 ts: 2.576667 ret: 0 st: 1 flags:1 dts: 2.785333 pts: 2.785333 pos: 559697 size: 255 ret: 0 st: 1 flags:1 ts: 1.470833 ret: 0 st: 1 flags:1 dts: 1.164000 pts: 1.164000 pos: 192278 size: 275 ret: 0 st: 2 flags:0 ts: 0.365000 ret: 0 st: 2 flags:1 dts: 0.332000 pts: 0.332000 pos: 18959 size: 271 Segmentation fault (core dumped) on samples server: ffmpeg-bugs/trac/ticket2739/lavf_ogm_seeking_borked.ogm thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The worst form of inequality is to try to make unequal things equal. -- Aristotle signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] gcc: Remove auto-vectorization limitation.
Here is a particularly bad example of autovectorisation across many compilers: https://gcc.godbolt.org/z/rjEqzf1hh Kieran Admittedly, in some cases, enabling vectorization is not the optimal solution. But the question is the limitation is only added on gcc side.For LLVM clang, there are no same restrict. And force add the limitation in configure side will change the user's original purpose, if user want to enable the vectorization when using gcc, it will have vectorization turned off without knowing it. After a long and careful inspection, user may finally find that the configure configuration has forced this feature to be turned off, and they still need to remove this restriction manually. BR, Jiawei ___ 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 1/4] avcodec/mpegvideo_enc: Use av_unreachable() for unreachable code
Andreas Rheinhardt: > Patches attached. > > - Andreas > Will apply this patchset tonight unless there are objections. - Andreas ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] gcc: Remove auto-vectorization limitation.
On Thu, 22 May 2025, 07:32 Jiawei, wrote: > 在 2025/5/22 2:21, Frank Plowman 写道: > > On 21/05/2025 11:17, Jiawei wrote: > >> 在 2025/5/21 14:52, Nicolas George 写道: > >>> Jiawei (HE12025-05-21): > particularly improving > performance on x86_64 (AVX), ARM64 (SVE) and RISC-V(RVV) > architectures. > >>> Benchmark needed. > >>> > >>> Regards, > >> > >> Hi Nicolas, > >> > >> > >> Since I am a gcc developer, I'm not so familiar with the FFmpeg test > >> flow, here is my test process, > >> if there exists anything uncorrect, please point me out: > >> > >> > >> 1. Download the video bbb_sunflower_2160p_30fps_normal.mp4.zip > >> < > https://download.blender.org/demo/movies/BBB/bbb_sunflower_2160p_30fps_normal.mp4.zip > > > >> from https://download.blender.org/demo/movies/BBB/， > >> > >> ``` > >> > >> ffmpeg -i bbb_sunflower_2160p_30fps_normal.mp4 -t 60 -vf > >> "scale=1920:1080" -c:v libx265 -c:a libmp3lame 1080p_hevc_mp3.mp4 > >> ``` > >> > >> get the 1080p video as Benchmark test video > >> > >> > >> 2. Build two version of FFmpeg, one with the modify, another without > >> the patch modif, using the gcc 13.3 release version, > >> > >> verified with Intel(R) Core(TM) Ultra 9 285HX > >> > >> > >> Using patch: > >> > >> ``` > >> ./ffmpeg -benchmark -i ~/mp/1080p_hevc_mp3.mp4 -f null - > >> ffmpeg version N-119636-g96518c8d8d Copyright (c) 2000-2025 the FFmpeg > >> developers > >> built with gcc 13 (Ubuntu 13.3.0-6ubuntu2~24.04) > >> configuration: --prefix=/home/pz9115/ffpo --disable-ffplay > --arch=x64 > >> --extra-cflags=-O3 --enable-static --target-os=linux > >> libavutil 60. 2.100 / 60. 2.100 > >> libavcodec 62. 3.101 / 62. 3.101 > >> libavformat62. 0.102 / 62. 0.102 > >> libavdevice62. 0.100 / 62. 0.100 > >> libavfilter11. 0.100 / 11. 0.100 > >> libswscale 9. 0.100 / 9. 0.100 > >> libswresample 6. 0.100 / 6. 0.100 > >> Input #0, mov,mp4,m4a,3gp,3g2,mj2, from > >> '/home/pz9115/mp/1080p_hevc_mp3.mp4': > >> Metadata: > >> major_brand : isom > >> minor_version : 512 > >> compatible_brands: isomiso2mp41 > >> title : Big Buck Bunny, Sunflower version > >> artist : Blender Foundation 2008, Janus Bager Kristensen > 2013 > >> composer: Sacha Goedegebure > >> encoder : Lavf60.16.100 > >> comment : Creative Commons Attribution 3.0 - > >> http://bbb3d.renderfarming.net > >> genre : Animation > >> Duration: 00:01:00.00, start: 0.00, bitrate: 1564 kb/s > >> Stream #0:0[0x1](und): Video: hevc (Main) (hev1 / 0x31766568), > >> yuv420p(tv, progressive), 1920x1080 [SAR 1:1 DAR 16:9], 1429 kb/s, 30 > >> fps, 30 tbr, 15360 tbn (default) > >> Metadata: > >> handler_name: GPAC ISO Video Handler > >> vendor_id : [0][0][0][0] > >> encoder : Lavc60.31.102 libx265 > >> Stream #0:1[0x2](und): Audio: mp3 (mp3float) (mp4a / 0x6134706D), > >> 48000 Hz, stereo, fltp, 128 kb/s (default) > >> Metadata: > >> handler_name: GPAC ISO Audio Handler > >> vendor_id : [0][0][0][0] > >> Stream mapping: > >> Stream #0:0 -> #0:0 (hevc (native) -> wrapped_avframe (native)) > >> Stream #0:1 -> #0:1 (mp3 (mp3float) -> pcm_s16le (native)) > >> Press [q] to stop, [?] for help > >> Output #0, null, to 'pipe:': > >> Metadata: > >> major_brand : isom > >> minor_version : 512 > >> compatible_brands: isomiso2mp41 > >> title : Big Buck Bunny, Sunflower version > >> artist : Blender Foundation 2008, Janus Bager Kristensen > 2013 > >> composer: Sacha Goedegebure > >> genre : Animation > >> comment : Creative Commons Attribution 3.0 - > >> http://bbb3d.renderfarming.net > >> encoder : Lavf62.0.102 > >> Stream #0:0(und): Video: wrapped_avframe, yuv420p(tv, progressive), > >> 1920x1080 [SAR 1:1 DAR 16:9], q=2-31, 200 kb/s, 30 fps, 30 tbn (default) > >> Metadata: > >> encoder : Lavc62.3.101 wrapped_avframe > >> handler_name: GPAC ISO Video Handler > >> vendor_id : [0][0][0][0] > >> Stream #0:1(und): Audio: pcm_s16le, 48000 Hz, stereo, s16, 1536 kb/s > >> (default) > >> Metadata: > >> encoder : Lavc62.3.101 pcm_s16le > >> handler_name: GPAC ISO Audio Handler > >> vendor_id : [0][0][0][0] > >> [out#0/null @ 0x565233669eb0] video:731KiB audio:11250KiB subtitle:0KiB > >> other streams:0KiB global headers:0KiB muxing overhead: unknown > >> frame= 1800 fps=635 q=-0.0 Lsize=N/A time=00:01:00.00 bitrate=N/A > >> speed=21.2x elapsed=0:00:02.83 > >> bench: utime=11.324s stime=0.290s rtime=2.834s > >> bench: maxrss=186556KiB > >> ``` > >> > >> Without patch(here I add the fno-tree-vectorize directly): > >> > >> ./ffmpeg -be
