[FFmpeg-devel] Fwd: Your message to ffmpeg-devel awaits moderator approval
Hello, My messages are being blocked on the mailing list. How is this fair that one person can unilaterally decide this? Here is my message: Hi Michael, If the CC has voted to ban someone, why has it not happened? You can't complain it the CC fails to act when it has voted for something to happen but is not capable of acting on the vote. Regards, Kieran Kunhya -- Forwarded message - From: Date: Thu, 19 Dec 2024, 08:55 Subject: Your message to ffmpeg-devel awaits moderator approval To: Your mail to 'ffmpeg-devel' with the subject Re: [FFmpeg-devel] [ANNOUNCE] upcoming vote: CC election Is being held until the list moderator can review it for approval. The reason it is being held: Header matched regexp: ^Subject:.*upcoming.*vote Either the message will get posted to the list, or you will receive notification of the moderator's decision. If you would like to cancel this posting, please visit the following URL: https://ffmpeg.org/mailman/confirm/ffmpeg-devel/2ded0729a35070cf225d539a330cc26cc24109a0 ___ ffmpeg-devel mailing list ffmpeg-devel@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] matroskadec: support S_TEXT/WEBVTT
based on Hendrik Leppkes's fork 0001-matroskadec-support-S_TEXT-WEBVTT.patch Description: Binary data ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] ffv1dec: add support for hardware acceleration
---
libavcodec/ffv1.h| 2 +
libavcodec/ffv1dec.c | 451 +--
2 files changed, 268 insertions(+), 185 deletions(-)
diff --git a/libavcodec/ffv1.h b/libavcodec/ffv1.h
index ca03fd2b10..93174bd45e 100644
--- a/libavcodec/ffv1.h
+++ b/libavcodec/ffv1.h
@@ -121,7 +121,9 @@ typedef struct FFV1Context {
int64_t picture_number;
int key_frame;
ProgressFrame picture, last_picture;
+void *hwaccel_picture_private, *hwaccel_last_picture_private;
uint32_t crcref;
+enum AVPixelFormat pix_fmt;
const AVFrame *cur_enc_frame;
int plane_count;
diff --git a/libavcodec/ffv1dec.c b/libavcodec/ffv1dec.c
index 7845815873..7dc1aaedc6 100644
--- a/libavcodec/ffv1dec.c
+++ b/libavcodec/ffv1dec.c
@@ -40,6 +40,9 @@
#include "progressframe.h"
#include "libavutil/refstruct.h"
#include "thread.h"
+#include "decode.h"
+#include "hwconfig.h"
+#include "hwaccel_internal.h"
static inline av_flatten int get_symbol_inline(RangeCoder *c, uint8_t *state,
int is_signed)
@@ -268,7 +271,7 @@ static int decode_slice(AVCodecContext *c, void *arg)
FFV1Context *f= c->priv_data;
FFV1SliceContext *sc = arg;
int width, height, x, y, ret;
-const int ps = av_pix_fmt_desc_get(c->pix_fmt)->comp[0].step;
+const int ps = av_pix_fmt_desc_get(f->pix_fmt)->comp[0].step;
AVFrame * const p = f->picture.f;
const int si = sc - f->slices;
GetBitContext gb;
@@ -537,178 +540,114 @@ static int read_extra_header(FFV1Context *f)
return 0;
}
-static int read_header(FFV1Context *f)
+static int setup_format(FFV1Context *f)
{
-uint8_t state[CONTEXT_SIZE];
-int context_count = -1; //-1 to avoid warning
-RangeCoder *const c = &f->slices[0].c;
-
-memset(state, 128, sizeof(state));
-
-if (f->version < 2) {
-int chroma_planes, chroma_h_shift, chroma_v_shift, transparency,
colorspace, bits_per_raw_sample;
-unsigned v= get_symbol(c, state, 0);
-if (v >= 2) {
-av_log(f->avctx, AV_LOG_ERROR, "invalid version %d in ver01
header\n", v);
-return AVERROR_INVALIDDATA;
-}
-f->version = v;
-f->ac = get_symbol(c, state, 0);
-
-if (f->ac == AC_RANGE_CUSTOM_TAB) {
-for (int i = 1; i < 256; i++) {
-int st = get_symbol(c, state, 1) + c->one_state[i];
-if (st < 1 || st > 255) {
-av_log(f->avctx, AV_LOG_ERROR, "invalid state transition
%d\n", st);
-return AVERROR_INVALIDDATA;
-}
-f->state_transition[i] = st;
-}
-}
-
-colorspace = get_symbol(c, state, 0); //YUV cs type
-bits_per_raw_sample = f->version > 0 ? get_symbol(c, state, 0) :
f->avctx->bits_per_raw_sample;
-chroma_planes = get_rac(c, state);
-chroma_h_shift = get_symbol(c, state, 0);
-chroma_v_shift = get_symbol(c, state, 0);
-transparency= get_rac(c, state);
-if (colorspace == 0 && f->avctx->skip_alpha)
-transparency = 0;
-
-if (f->plane_count) {
-if (colorspace != f->colorspace ||
-bits_per_raw_sample != f->avctx->bits_per_raw_sample ||
-chroma_planes != f->chroma_planes ||
-chroma_h_shift != f->chroma_h_shift ||
-chroma_v_shift != f->chroma_v_shift ||
-transparency!= f->transparency) {
-av_log(f->avctx, AV_LOG_ERROR, "Invalid change of global
parameters\n");
-return AVERROR_INVALIDDATA;
-}
-}
-
-if (chroma_h_shift > 4U || chroma_v_shift > 4U) {
-av_log(f->avctx, AV_LOG_ERROR, "chroma shift parameters %d %d are
invalid\n",
- chroma_h_shift, chroma_v_shift);
-return AVERROR_INVALIDDATA;
-}
-
-f->colorspace = colorspace;
-f->avctx->bits_per_raw_sample = bits_per_raw_sample;
-f->chroma_planes = chroma_planes;
-f->chroma_h_shift = chroma_h_shift;
-f->chroma_v_shift = chroma_v_shift;
-f->transparency = transparency;
-
-f->plane_count= 2 + f->transparency;
-}
-
if (f->colorspace == 0) {
if (!f->transparency && !f->chroma_planes) {
if (f->avctx->bits_per_raw_sample <= 8)
-f->avctx->pix_fmt = AV_PIX_FMT_GRAY8;
+f->pix_fmt = AV_PIX_FMT_GRAY8;
else if (f->avctx->bits_per_raw_sample == 9) {
f->packed_at_lsb = 1;
-f->avctx->pix_fmt = AV_PIX_FMT_GRAY9;
+f->pix_fmt = AV_PIX_FMT_GRAY9;
} else if (f->avctx->bits_per_raw_sample == 10) {
f->packed_at_lsb
Re: [FFmpeg-devel] [PATCH v2 02/17] swscale/utils: add HDR metadata to SwsFormat
On Thu, 19 Dec 2024 05:07:16 +0100 Michael Niedermayer
wrote:
> Hi
>
>
> On Mon, Dec 16, 2024 at 12:17:23PM +0100, Niklas Haas wrote:
> [...]
> > diff --git a/libswscale/utils.h b/libswscale/utils.h
> > index 4d204ef6cc..52b1e67644 100644
> > --- a/libswscale/utils.h
> > +++ b/libswscale/utils.h
> > @@ -21,26 +21,55 @@
> > #ifndef SWSCALE_UTILS_H
> > #define SWSCALE_UTILS_H
> >
> > +#include "libavutil/csp.h"
> > #include "libavutil/pixdesc.h"
> >
> > #include "swscale.h"
> >
> > +/* Like av_cmp_q but considers x/0 == y/0 */
> > +static inline int ff_q_equal(const AVRational a, const AVRational b)
> > +{
> > +return (!a.den && !b.den) || !av_cmp_q(a, b);
> > +}
>
> if thats true for all cases then ok
>
> feels a little odd to me that -inf == NaN == +inf
Good point. I'll change it to only exclude the NaN case then.
>
> thx
>
> [...]
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> I know you won't believe me, but the highest form of Human Excellence is
> to question oneself and others. -- Socrates
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@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] [ANNOUNCE] upcoming vote: CC election
Hi J-B: > The 2 situations are not the same at all: > One claims to be from this community and uses the FFmpeg name, > the other one does not make any claims. > Please don't confuse the 2 situations. Thanks for clarifying, I was going off of my interpretation based on how I read through it last night. The nuance makes sense. What I was going more for is building a process around organizing the events that is more formidable than an email announcement. Ultimately I am trying to propose/focus on solutions irrespective of the nuance. If such a process already exists and I am missing it, just let me know. Administrative paperwork is not ideal but in this case a socialization and approval workflow seems to be a reasonable "what could we do better" retro action. ___ ffmpeg-devel mailing list ffmpeg-devel@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] Fwd: Your message to ffmpeg-devel awaits moderator approval
On Thu, 19 Dec 2024 14:58:34 +0100, Anton Khirnov wrote: > Quoting James Almer (2024-12-19 14:04:53) > > On 12/19/2024 6:34 AM, Anton Khirnov wrote: > > > Quoting Kieran Kunhya via ffmpeg-devel (2024-12-19 09:58:14) > > >> Hello, > > >> > > >> My messages are being blocked on the mailing list. How is this fair that > > >> one person can unilaterally decide this? > > > > > > This also happened to one mail I sent a few weeks ago. I thought it was > > > a thread block put in place by CC, but a CC member confirmed to me > > > recently this was not the case. > > > > Which mail? I added rules to block two threads as notified publicly by > > Ronald since said threads were too heated. > > The mail never got to the ML, I am pasting it below. It was in the > thread: > "Discussion about mails from 9 years ago Was: [PATCH 1/2] doc/community: Add > a standard set of rules for software development mailing lists" > > I saw no announcement of any CC action related to that thread. i didnt moderate that standard*set thread. CC did , as specified here: https://lists.ffmpeg.org/pipermail/ffmpeg-devel/2024-December/337678.html > Which mail? I added rules to block two threads as notified publicly by > Ronald since said threads were too heated. > > > > > > > Indirect evidence points towards compn adding the block in both cases. > > > IMO it's utterly unacceptable that a random unelected person (not even a > > > part of GA at that) just unilaterally decides to usurp CC powers and > > > censor the ML. > > > > > > CCing root - I request that ML moderator privileges are removed from > > > everyone who does not have a legitimate reason to have them (that is > > > server administrators and CC members). I further request that ONLY CC > > > members engage in actual moderation (besides approving mails from > > > non-subscribed people). > > > > I have no idea who added the rule for "upcoming vote", but i just > > removed it. > > The reasons I think it was compn are: > * he replied to email contents in a private IRC message (which btw I > consider another major abuse of moderator powers) i discarded your mail of the mod queue a few hours ago. yes i tried to talk to you privately about your mail on irc. your response on irc made me stop talking to you further. are you upset that i, as the ml admin, read mails that get stuck in the moderation queue? > * he mentioned having ML mod access on ML > * his CC candidacy email mentions preemptive ML censoring > But we do not have to speculate, the person who did it can just say so. yep, its me. ml admin for 15 years reporting in. > Either way, I believe there should be clarity about who has ML moderator > powers and what they can use them for. community page is mum about ml admins and their duties , yes. > The email mentioned above: another personal flame email that isnt ffmpeg development related? -compn ___ ffmpeg-devel mailing list ffmpeg-devel@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] [ANNOUNCE] upcoming vote: CC election
Hello, On Thu, 19 Dec 2024, at 04:40, Marth64 wrote: > Statement #1 (NAB 2023) > > * Trademarked FFmpeg branding was used by a different organization > without clear authorization. Incorrect: FFmpeg is not trademarked in the USA. Actually, in 2023, FFmpeg was not trademarked anywhere in the world. > * Two or more contributors were present at the booth, resulting in a > mixed image of brand ownership. Incorrect: the booth was under the name VideoLabs, with VideoLabs name and logo, with VideoLabs on the map, the directory and so on. Contributors to FFmpeg are on numerous booths at IBC/NAB, because incredibly, people have jobs in this industry. > Statement #2 (NAB 2024) > > * Booth announced in Nov 2023 with "anonymous corporate sponsorship" > and vague expense process. > * There was a brief, heated exchange on the ML about the source of > funding, but the booth was opened anyway. > * FFmpeg contributors who passed by the booth questioned its > legitimacy due to seeing nobody. > * Ultimately the booth was revealed to be staffed but the thread > exploded due to the initial disagreement. The issue is that the booth was under the NAME FFmpeg, with FFmpeg name on the directory and maps, and website, searchable and indexed. This booth was therefore supposedly representing the community, with the FFmpeg name, with dark sponsorship(?), where we still don't know who paid what for. And finally, that FFmpeg booth finally became a GPAC booth, which was not announced at all. Oh, and by that time, the FFmpeg was trademarked again. The 2 situations are not the same at all: One claims to be from this community and uses the FFmpeg name, the other one does not make any claims. Please don't confuse the 2 situations. -- Jean-Baptiste Kempf - President +33 672 704 734 https://jbkempf.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] Fwd: Your message to ffmpeg-devel awaits moderator approval
On 12/19/2024 6:34 AM, Anton Khirnov wrote: Quoting Kieran Kunhya via ffmpeg-devel (2024-12-19 09:58:14) Hello, My messages are being blocked on the mailing list. How is this fair that one person can unilaterally decide this? This also happened to one mail I sent a few weeks ago. I thought it was a thread block put in place by CC, but a CC member confirmed to me recently this was not the case. Which mail? I added rules to block two threads as notified publicly by Ronald since said threads were too heated. Indirect evidence points towards compn adding the block in both cases. IMO it's utterly unacceptable that a random unelected person (not even a part of GA at that) just unilaterally decides to usurp CC powers and censor the ML. CCing root - I request that ML moderator privileges are removed from everyone who does not have a legitimate reason to have them (that is server administrators and CC members). I further request that ONLY CC members engage in actual moderation (besides approving mails from non-subscribed people). I have no idea who added the rule for "upcoming vote", but i just removed it. 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] [ANNOUNCE] upcoming vote: CC election
On Thu, 19 Dec 2024, 02:22 Michael Niedermayer, wrote: > > Kieran reports this to the CC > and jb and ronald vote for a third ban of Nicolas, > ronald states that he would not have voted for a ban if Nicolas apologized. > Hi Michael, If the CC has voted to ban someone, why has it not happened? You can't complain it the CC fails to act when it has voted for something to happen but is not capable of acting on the vote. 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] Fwd: Your message to ffmpeg-devel awaits moderator approval
On Thu, 19 Dec 2024 13:16:23 -0300, James Almer wrote: > On 12/19/2024 1:12 PM, compn wrote: > > On Thu, 19 Dec 2024 10:04:53 -0300, James Almer wrote: > >> I have no idea who added the rule for "upcoming vote", but i just > >> removed it. > >> > > > > i added upcoming vote to mod as devs were getting personal about booths > > and whatnot. as you've removed it, now we see the flames on the list. > > You can't silently and unilaterally add a filter to stop a thread in its > tracks. That is something that needs to go through the CC, and publicly > announced. could you link me to the actual rules that state any of this? none of what you said is in the ffmpeg code of conduct. https://ffmpeg.org/community.html if you cannot link me to rules that show any of what you said i broke the rules of, i would like an apology. > It speaks poorly of how you would perform as part of the CC if you think > acting alone and making bad use of your ml admin privileges is ok. keeping out flames is part of the ml admin duties. see for ex: emergency moderation, moderate all users, mod individual, spam filtering options. these stop flames duties were told to me by previous roots (gabu, diego) and current roots (michael, alex). reading the mails stuck in the moderation queue and clearing the moderation queue is also part of the duties of the ml admin. -compn ___ ffmpeg-devel mailing list ffmpeg-devel@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] Fwd: Your message to ffmpeg-devel awaits moderator approval
On 12/19/2024 11:46 AM, Timo Rothenpieler wrote: On 19/12/2024 09:58, Kieran Kunhya via ffmpeg-devel wrote: Hello, My messages are being blocked on the mailing list. How is this fair that one person can unilaterally decide this? It's not even possible for a moderator do hold individual mails after the fact, unless I'm missing something here? This mail got through, so it can't be a block on you in general. The only thing that can hold mails is if some kind of filter rule matches it, or the spam filter. Or if you accidentally send it from an address that's not subscribed. As in this case, the mail got blocked because it matched a filter rule against "upcoming vote" in the subject. It's a bit odd of a rule, but I could see it making sense at least, in that only people who are allowed to run votes can actually do so. It's also been already removed now, which seems like the right decision to me, given we never had any such issues ever. Yes i removed the rule and approved his email. The filter rule was added without previous notice and without the intervention of the CC, which is not ok at all. 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] Fwd: Your message to ffmpeg-devel awaits moderator approval
On Thu, 19 Dec 2024 10:04:53 -0300, James Almer wrote: > On 12/19/2024 6:34 AM, Anton Khirnov wrote: > > Quoting Kieran Kunhya via ffmpeg-devel (2024-12-19 09:58:14) > >> Hello, > >> > >> My messages are being blocked on the mailing list. How is this fair that > >> one person can unilaterally decide this? > > > > This also happened to one mail I sent a few weeks ago. I thought it was > > a thread block put in place by CC, but a CC member confirmed to me > > recently this was not the case. > > Which mail? I added rules to block two threads as notified publicly by > Ronald since said threads were too heated. > > > > > Indirect evidence points towards compn adding the block in both cases. > > IMO it's utterly unacceptable that a random unelected person (not even a > > part of GA at that) just unilaterally decides to usurp CC powers and > > censor the ML. > > > > CCing root - I request that ML moderator privileges are removed from > > everyone who does not have a legitimate reason to have them (that is > > server administrators and CC members). I further request that ONLY CC > > members engage in actual moderation (besides approving mails from > > non-subscribed people). > > I have no idea who added the rule for "upcoming vote", but i just > removed it. > i added upcoming vote to mod as devs were getting personal about booths and whatnot. as you've removed it, now we see the flames on the list. -compn ___ ffmpeg-devel mailing list ffmpeg-devel@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] Fwd: Your message to ffmpeg-devel awaits moderator approval
On Thu, 19 Dec 2024 08:58:14 +, Kieran Kunhya via ffmpeg-devel wrote: > Hello, > > My messages are being blocked on the mailing list. your message, and the message of others in that specific thread was not blocked. it was held for moderator approval as you quoted below. > The reason it is being held: > > Header matched regexp: ^Subject:.*upcoming.*vote > > Either the message will get posted to the list, or you will receive > notification of the moderator's decision. If you would like to cancel > this posting, please visit the following URL: > How is this fair that one person can unilaterally decide this? as ml admin if i see flames i try to tamper them down a bit. -compn ___ ffmpeg-devel mailing list ffmpeg-devel@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] Fwd: Your message to ffmpeg-devel awaits moderator approval
On 12/19/2024 1:12 PM, compn wrote: On Thu, 19 Dec 2024 10:04:53 -0300, James Almer wrote: On 12/19/2024 6:34 AM, Anton Khirnov wrote: Quoting Kieran Kunhya via ffmpeg-devel (2024-12-19 09:58:14) Hello, My messages are being blocked on the mailing list. How is this fair that one person can unilaterally decide this? This also happened to one mail I sent a few weeks ago. I thought it was a thread block put in place by CC, but a CC member confirmed to me recently this was not the case. Which mail? I added rules to block two threads as notified publicly by Ronald since said threads were too heated. Indirect evidence points towards compn adding the block in both cases. IMO it's utterly unacceptable that a random unelected person (not even a part of GA at that) just unilaterally decides to usurp CC powers and censor the ML. CCing root - I request that ML moderator privileges are removed from everyone who does not have a legitimate reason to have them (that is server administrators and CC members). I further request that ONLY CC members engage in actual moderation (besides approving mails from non-subscribed people). I have no idea who added the rule for "upcoming vote", but i just removed it. i added upcoming vote to mod as devs were getting personal about booths and whatnot. as you've removed it, now we see the flames on the list. You can't silently and unilaterally add a filter to stop a thread in its tracks. That is something that needs to go through the CC, and publicly announced. It speaks poorly of how you would perform as part of the CC if you think acting alone and making bad use of your ml admin privileges is ok. 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] [PATCH v2 04/17] swscale/utils: read HDR mastering metadata from AVFrame
On 12/16/24 6:17 AM, Niklas Haas wrote:
From: Niklas Haas
---
libswscale/utils.c | 22 ++
1 file changed, 22 insertions(+)
diff --git a/libswscale/utils.c b/libswscale/utils.c
index 2d8fc10beb..3d3fcadacc 100644
--- a/libswscale/utils.c
+++ b/libswscale/utils.c
@@ -46,6 +46,7 @@
#include "libavutil/imgutils.h"
#include "libavutil/intreadwrite.h"
#include "libavutil/libm.h"
+#include "libavutil/mastering_display_metadata.h"
#include "libavutil/mathematics.h"
#include "libavutil/mem.h"
#include "libavutil/opt.h"
@@ -2655,6 +2656,7 @@ SwsFormat ff_fmt_from_frame(const AVFrame *frame, int
field)
{
const AVPixFmtDescriptor *desc = av_pix_fmt_desc_get(frame->format);
const AVColorPrimariesDesc *primaries;
+AVFrameSideData *sd;
SwsFormat fmt = {
.width = frame->width,
@@ -2727,6 +2729,26 @@ SwsFormat ff_fmt_from_frame(const AVFrame *frame, int
field)
if (primaries)
fmt.color.gamut = primaries->prim;
+if ((sd = av_frame_get_side_data(frame, AV_FRAME_DATA_MASTERING_DISPLAY_METADATA))) {
+const AVMasteringDisplayMetadata *mdm = (const AVMasteringDisplayMetadata
*) sd->data;
+if (mdm->has_luminance) {
+fmt.color.min_luma = mdm->min_luminance;
+fmt.color.max_luma = mdm->max_luminance;
+}
+
+if (mdm->has_primaries) {
+/* Ignore mastering display white point as it has no bearance on
+ * the underlying content */
+fmt.color.gamut.r = (AVCIExy) { mdm->display_primaries[0][0],
mdm->display_primaries[0][1] };
+fmt.color.gamut.g = (AVCIExy) { mdm->display_primaries[1][0],
mdm->display_primaries[1][1] };
+fmt.color.gamut.b = (AVCIExy) { mdm->display_primaries[2][0],
mdm->display_primaries[2][1] };
I think this kind of initializer chokes MSVC. We need to use something like:
fmt.color.gamut.r = { .x = mdm->display_primaries[0][0], .y =
mdm->display_primaries[0][1] };
+}
+}
+
+/* PQ is always scaled down to absolute zero, so ignore mastering metadata
*/
+if (fmt.color.trc == AVCOL_TRC_SMPTE2084)
+fmt.color.min_luma = av_make_q(0, 1);
+
return fmt;
}
___
ffmpeg-devel mailing list
ffmpeg-devel@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] swscale/options: add missing -sws_dither none alias
From: Niklas Haas
This one was documented, but never actually supported.
Fixes: ticket #9192
Signed-off-by: Niklas Haas
Sponsored-by: Sovereign Tech Fund
---
libswscale/options.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/libswscale/options.c b/libswscale/options.c
index 5eef26de06..8375655183 100644
--- a/libswscale/options.c
+++ b/libswscale/options.c
@@ -71,6 +71,7 @@ static const AVOption swscale_options[] = {
{ "sws_dither", "set dithering algorithm", OFFSET(dither),
AV_OPT_TYPE_INT,{ .i64 = SWS_DITHER_AUTO }, .flags = VE, .unit =
"sws_dither", .max = SWS_DITHER_NB - 1 },
{ "auto","automatic selection", 0,
AV_OPT_TYPE_CONST, { .i64 = SWS_DITHER_AUTO }, .flags = VE, .unit =
"sws_dither" },
+{ "none","no dithering", 0,
AV_OPT_TYPE_CONST, { .i64 = SWS_DITHER_NONE }, .flags = VE, .unit =
"sws_dither" },
{ "bayer", "ordered matrix dither", 0,
AV_OPT_TYPE_CONST, { .i64 = SWS_DITHER_BAYER}, .flags = VE, .unit =
"sws_dither" },
{ "ed", "full error diffusion", 0,
AV_OPT_TYPE_CONST, { .i64 = SWS_DITHER_ED }, .flags = VE, .unit =
"sws_dither" },
{ "a_dither","arithmetic addition dither",0,
AV_OPT_TYPE_CONST, { .i64 = SWS_DITHER_A_DITHER }, .flags = VE, .unit =
"sws_dither" },
--
2.47.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] Fwd: Your message to ffmpeg-devel awaits moderator approval
Quoting James Almer (2024-12-19 14:04:53) > On 12/19/2024 6:34 AM, Anton Khirnov wrote: > > Quoting Kieran Kunhya via ffmpeg-devel (2024-12-19 09:58:14) > >> Hello, > >> > >> My messages are being blocked on the mailing list. How is this fair that > >> one person can unilaterally decide this? > > > > This also happened to one mail I sent a few weeks ago. I thought it was > > a thread block put in place by CC, but a CC member confirmed to me > > recently this was not the case. > > Which mail? I added rules to block two threads as notified publicly by > Ronald since said threads were too heated. The mail never got to the ML, I am pasting it below. It was in the thread: "Discussion about mails from 9 years ago Was: [PATCH 1/2] doc/community: Add a standard set of rules for software development mailing lists" I saw no announcement of any CC action related to that thread. > > > > Indirect evidence points towards compn adding the block in both cases. > > IMO it's utterly unacceptable that a random unelected person (not even a > > part of GA at that) just unilaterally decides to usurp CC powers and > > censor the ML. > > > > CCing root - I request that ML moderator privileges are removed from > > everyone who does not have a legitimate reason to have them (that is > > server administrators and CC members). I further request that ONLY CC > > members engage in actual moderation (besides approving mails from > > non-subscribed people). > > I have no idea who added the rule for "upcoming vote", but i just > removed it. The reasons I think it was compn are: * he replied to email contents in a private IRC message (which btw I consider another major abuse of moderator powers) * he mentioned having ML mod access on ML * his CC candidacy email mentions preemptive ML censoring But we do not have to speculate, the person who did it can just say so. Either way, I believe there should be clarity about who has ML moderator powers and what they can use them for. The email mentioned above: Quoting compn (2024-11-24 21:51:08) > On Sun, 24 Nov 2024 20:09:43 +0100 > Michael Niedermayer wrote: > > > less than 2 weeks ago the founder was insulted like this: > > "Fabrice's control of ffmpeg.org and French trademark, despite not havign > > contributed > > in 20 years, purely for ego reasons mean we can never move to a truly > > community run set or project infra." > > > > And we can probably go on and on. > > On top of this i would not be surprised if other people have similar stories > > from yet others they spoke with. > > a non-ff developer at vdd said i was "inactive for years". it > makes me not want to visit vdd again. i reported them to the videolan > board, Saying someone seems inactive is a reportable offence now? Because you do seem inactive to me. Before this VDD, the last email from you on the ML sems to be from June 2018, that is over 6 years ago. You also have 3 commits in the last 10 years (of them zero in the last 7 years). You are not in GA, any of the committees, or MAINTAINERS. The only mention of you in infra is as IRC channel founder, yet I saw minimal activity from you in #ffmpeg-devel until very recently. So just why are you surprised or offended that someone considers you inactive? Also, as a counterpoint, consider the following perspective: some person, whom I haven't seen contribute to the project in years, suddenly appears out of nowhere and fills the ML with his opinions on how the project should be run. What kind of an impression do you think that creates? -- Anton Khirnov ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 1/2] swscale/unscaled: correctly copy semiplanar formats
From: Niklas Haas
This fixes multiple bugs with semiplanar formats like NV12. Not only do these
false positive the grayscale format checks (because dst[2] in NULL), but they
also copied an incorrect number of pixels.
Fixes conversions such as nv12 -> nv12, gray8 -> nv12, nv20le -> nv20be, etc.
Fixes: ticket #11239
Signed-off-by: Niklas Haas
Sponsored-by: Sovereign Tech Fund
---
libswscale/swscale_unscaled.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/libswscale/swscale_unscaled.c b/libswscale/swscale_unscaled.c
index 434206996b..ebc0fe33d2 100644
--- a/libswscale/swscale_unscaled.c
+++ b/libswscale/swscale_unscaled.c
@@ -2215,10 +2215,12 @@ static int planarCopyWrapper(SwsInternal *c, const
uint8_t *const src[],
const uint8_t *srcPtr = src[plane];
uint8_t *dstPtr = dst[plane] + dstStride[plane] * y;
int shiftonly = plane == 1 || plane == 2 || (!c->opts.src_range &&
plane == 0);
+if (plane == 1 && isSemiPlanarYUV(c->opts.dst_format))
+length *= 2;
// ignore palette for GRAY8
-if (plane == 1 && !dst[2]) continue;
-if (!src[plane] || (plane == 1 && !src[2])) {
+if (plane == 1 && desc_dst->nb_components < 3) continue;
+if (!src[plane] || (plane == 1 && desc_src->nb_components < 3)) {
if (is16BPS(c->opts.dst_format) || isNBPS(c->opts.dst_format)) {
fillPlane16(dst[plane], dstStride[plane], length, height, y,
plane == 3, desc_dst->comp[plane].depth,
--
2.47.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 2/2] swscale/unscaled: allow semiplanar copies
From: Niklas Haas
As fixed in the previous commit, this enables semipacked range and
bit depth conversions. Previously these would go through the general
purpose path.
Signed-off-by: Niklas Haas
Sponsored-by: Sovereign Tech Fund
---
libswscale/swscale_unscaled.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libswscale/swscale_unscaled.c b/libswscale/swscale_unscaled.c
index ebc0fe33d2..957b02ef30 100644
--- a/libswscale/swscale_unscaled.c
+++ b/libswscale/swscale_unscaled.c
@@ -2665,7 +2665,7 @@ void ff_get_unscaled_swscale(SwsInternal *c)
(isPlanarYUV(srcFormat) && isPlanarYUV(dstFormat) &&
c->chrDstHSubSample == c->chrSrcHSubSample &&
c->chrDstVSubSample == c->chrSrcVSubSample &&
- !isSemiPlanarYUV(srcFormat) && !isSemiPlanarYUV(dstFormat
+ isSemiPlanarYUV(srcFormat) == isSemiPlanarYUV(dstFormat
{
if (isPacked(c->opts.src_format))
c->convert_unscaled = packedCopyWrapper;
--
2.47.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 1/2] swscale/unscaled: correctly copy semiplanar formats
Quoting Niklas Haas (2024-12-19 15:07:59) > From: Niklas Haas > > This fixes multiple bugs with semiplanar formats like NV12. Not only do these > false positive the grayscale format checks (because dst[2] in NULL), but they > also copied an incorrect number of pixels. > > Fixes conversions such as nv12 -> nv12, gray8 -> nv12, nv20le -> nv20be, etc. > > Fixes: ticket #11239 > Signed-off-by: Niklas Haas > Sponsored-by: Sovereign Tech Fund > --- > libswscale/swscale_unscaled.c | 6 -- > 1 file changed, 4 insertions(+), 2 deletions(-) Do we have no tests for this? -- Anton Khirnov ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2 05/17] swscale/utils: read dynamic HDR10+ metadata from AVFrame
On Mon, Dec 16, 2024 at 12:17:26PM +0100, Niklas Haas wrote: > From: Niklas Haas > > Logic ported from libplacebo's AVFrame helpers. The basic idea is to use the > provided MaxRGB/MaxSCL values to infer what the actual luminance would have > been, which HDR10+ metadata does not provide directly. It's worth pointing out > that this gives us an *upper* bound on the true maximum luminance, so any > error in the estimation cannot result in clipping. > --- > libswscale/utils.c | 50 ++ > 1 file changed, 50 insertions(+) still probably ok thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Elect your leaders based on what they did after the last election, not based on what they say before an election. 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 1/8] avutil/frame: add AVSideDataDescriptor for AV_FRAME_DATA_VIDEO_HINT
On Wed, 04 Dec 2024 15:51:02 +0100 Niklas Haas wrote:
> From: Niklas Haas
>
> This entry was seemingly missing.
> ---
> libavutil/frame.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/libavutil/frame.c b/libavutil/frame.c
> index 5fb47dbaa6..3020845ef8 100644
> --- a/libavutil/frame.c
> +++ b/libavutil/frame.c
> @@ -58,6 +58,7 @@ static const AVSideDataDescriptor sd_props[] = {
> [AV_FRAME_DATA_SPHERICAL] = { "Spherical Mapping",
>AV_SIDE_DATA_PROP_GLOBAL },
> [AV_FRAME_DATA_ICC_PROFILE] = { "ICC profile",
>AV_SIDE_DATA_PROP_GLOBAL },
> [AV_FRAME_DATA_SEI_UNREGISTERED]= { "H.26[45] User Data
> Unregistered SEI message", AV_SIDE_DATA_PROP_MULTI },
> +[AV_FRAME_DATA_VIDEO_HINT] = { "Encoding video hint" },
> };
>
> static void get_frame_defaults(AVFrame *frame)
> --
> 2.47.0
>
Will merge this series in 24h if there are no further comments.
___
ffmpeg-devel mailing list
ffmpeg-devel@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] Your message to ffmpeg-devel awaits moderator approval
On 19 Dec 2024, at 10:34, Anton Khirnov wrote: > Quoting Kieran Kunhya via ffmpeg-devel (2024-12-19 09:58:14) >> Hello, >> >> My messages are being blocked on the mailing list. How is this fair that >> one person can unilaterally decide this? > > This also happened to one mail I sent a few weeks ago. I thought it was > a thread block put in place by CC, but a CC member confirmed to me > recently this was not the case. > > Indirect evidence points towards compn adding the block in both cases. > IMO it's utterly unacceptable that a random unelected person (not even a > part of GA at that) just unilaterally decides to usurp CC powers and > censor the ML. > > CCing root - I request that ML moderator privileges are removed from > everyone who does not have a legitimate reason to have them (that is > server administrators and CC members). I further request that ONLY CC > members engage in actual moderation (besides approving mails from > non-subscribed people). I agree on that, whoever implemented such moderation rule, especially for a thread about the next CC vote, should have their access to be able to do this revoked immediately as this is a clear abuse of admin powers. (Even if the current CC had decided to do this, this is something that HAS to be transparently communicated at the very least.) Sincerely, Marvin Scholz > > -- > Anton Khirnov > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". ___ ffmpeg-devel mailing list ffmpeg-devel@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: add AV1 RTP depacketizer and packetizer
Hi there, On 12/13/24 15:09, Tristan Matthews via ffmpeg-devel wrote: I don't seem to be able to replay the Chimera video directly with my local build of ffplay, get's all choppy and skips big deals of the video. Might be an outdated libdav1d? I still have problems with the media server and the Chimera video. I downloaded the IVF file from here: http://download.opencontent.netflix.com/?prefix=AV1/Chimera/Old/ It seems like the PTS are all over the place for each cut-scene and ffmpeg will thus increase the output video rate to infinity which causes a slight UDP overflow and drop on the receiving end. Maybe I'm doing something wrong here, but I wasn't able to fix the PTS in the file with ffmpeg so that it was monotonically increasing. Anyway, the AV1 RTP decoder currently does not wait for a keyframe before sending down frames. Should it do that? Also, should it wait for another keyframe if any frame or packet had been dropped (the GOP is going to be useless for the decoder anyway)? That's a good question, I don't believe any of the RTP depacketizers in libavformat do this currently so maybe best left as a future enhancement (behind an option/flag). Sounds reasonable. The implementation in some browsers* seem to refuse to playback the AV1 file if the tile data corrupted due to dropped frames and will not skip till the next keyframe. This is rather unexpected. There is a AV_PKT_FLAG_CORRUPT flag, maybe I should be setting this instead? * for me it works in Firefox but fails in Chrome On a related note, one feature that only the VP8 depacketizer supports now is signalling via RTCP that it needs a keyframe (in the event of loss or the start of a stream), to do this you just have to implement the .need_keyframe callback (see https://git.ffmpeg.org/gitweb/ffmpeg.git/blob/eb79c316c7b205f45e7003e91f77c253818e6685:/libavformat/rtpdec_vp8.c#l274) That's a great feature, can't see why I shouldn't be implementing it. Will provide a new patch next year. I haven't been working with such complex frame hierarchies, but I will try to get the Chimera working. FWIW I was seeing similar behaviour with smaller/simpler files as well. Except for the UDP packet drops, causing loss of most of the latter scenes past the keyframes (with the current change of dropping all data past the point of corruption), I didn't see any stream corruption anymore. Best regards, Chris PS: Will be unavailable over xmas. God jul! -- Chris ___ ffmpeg-devel mailing list ffmpeg-devel@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] [ANNOUNCE] upcoming vote: CC election
Hi, On Thu, Dec 19, 2024 at 8:05 AM Kieran Kunhya via ffmpeg-devel < ffmpeg-devel@ffmpeg.org> wrote: > On Thu, 19 Dec 2024, 02:22 Michael Niedermayer, > wrote: > > > Kieran reports this to the CC > > and jb and ronald vote for a third ban of Nicolas, > > ronald states that he would not have voted for a ban if Nicolas > apologized. > The "if Nicolas had apologized" part is a bit terse, there's things going on behind the scenes that are not visible. The CC members had previously agreed that if discussions got heated, we wouldn't debate extensively before getting involved: bans need to be voted on, but asking people to be nice does not. This is in line with what the community asked for over the past few months. Also, such communications can be private, but we CC c...@ffmpeg.org to make sure we don't all send the same message. In light of that, I sent a private email to Nicolas, CC'ed to c...@ffmpeg.org, saying the following: "You really have to learn to tone down the venom in your voice. This is not how friends or colleagues interact. My friendly CC-hat recommendation is that you take the comment back, apologize for the tone, or something to that effect. Probably a combination of the above." There was no follow-up from Nicolas, unfortunately. > Hi Michael, > > If the CC has voted to ban someone, why has it not happened? > The CC consists of 5 members, and only 2 of them voted for a ban. 2/5 is not a majority and therefore no ban was enacted. This seems correct to me. Ronald ___ ffmpeg-devel mailing list ffmpeg-devel@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: add AV1 RTP depacketizer and packetizer
Hi, On Thu, Dec 19, 2024 at 8:23 AM Chris Hodges wrote: > Hi there, > > On 12/13/24 15:09, Tristan Matthews via ffmpeg-devel wrote: > > >> I don't seem to be able to replay the Chimera video directly with my > >> local build of ffplay, get's all choppy and skips big deals of the > >> video. Might be an outdated libdav1d? > > I still have problems with the media server and the Chimera video. I > downloaded the IVF file from here: > > http://download.opencontent.netflix.com/?prefix=AV1/Chimera/Old/ > > It seems like the PTS are all over the place for each cut-scene > They are, that sample is somewhat broken. I would suggest using another one for testing... Ronald ___ ffmpeg-devel mailing list ffmpeg-devel@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] Fwd: Your message to ffmpeg-devel awaits moderator approval
On 19/12/2024 09:58, Kieran Kunhya via ffmpeg-devel wrote: Hello, My messages are being blocked on the mailing list. How is this fair that one person can unilaterally decide this? It's not even possible for a moderator do hold individual mails after the fact, unless I'm missing something here? This mail got through, so it can't be a block on you in general. The only thing that can hold mails is if some kind of filter rule matches it, or the spam filter. Or if you accidentally send it from an address that's not subscribed. As in this case, the mail got blocked because it matched a filter rule against "upcoming vote" in the subject. It's a bit odd of a rule, but I could see it making sense at least, in that only people who are allowed to run votes can actually do so. It's also been already removed now, which seems like the right decision to me, given we never had any such issues ever. Timo ___ ffmpeg-devel mailing list ffmpeg-devel@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] Fwd: Your message to ffmpeg-devel awaits moderator approval
Quoting Kieran Kunhya via ffmpeg-devel (2024-12-19 09:58:14) > Hello, > > My messages are being blocked on the mailing list. How is this fair that > one person can unilaterally decide this? This also happened to one mail I sent a few weeks ago. I thought it was a thread block put in place by CC, but a CC member confirmed to me recently this was not the case. Indirect evidence points towards compn adding the block in both cases. IMO it's utterly unacceptable that a random unelected person (not even a part of GA at that) just unilaterally decides to usurp CC powers and censor the ML. CCing root - I request that ML moderator privileges are removed from everyone who does not have a legitimate reason to have them (that is server administrators and CC members). I further request that ONLY CC members engage in actual moderation (besides approving mails from non-subscribed people). -- Anton Khirnov ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v3] libavcodec/v4l2_buffers.c: set AVFrame interlaced flags
> On Dec 19, 2024, at 08:28, James Almer wrote:
>
> On 12/18/2024 6:59 PM, Scott Theisen wrote:
>> Originally from:
>> https://github.com/MythTV/mythtv/commit/669955c6cb29196b4b5120451b5b998d67a65749
>> ---
>> v3:
>> remove unnecessary clearing of already 0 valued flags
>> use switch-case; I don't really think it is any simpler, but I do like the
>> format better.
>> ---
>> libavcodec/v4l2_buffers.c | 19 +++
>> 1 file changed, 19 insertions(+)
>> diff --git a/libavcodec/v4l2_buffers.c b/libavcodec/v4l2_buffers.c
>> index 23474ee143..19cc86334b 100644
>> --- a/libavcodec/v4l2_buffers.c
>> +++ b/libavcodec/v4l2_buffers.c
>> @@ -210,6 +210,24 @@ static enum AVColorTransferCharacteristic
>> v4l2_get_color_trc(V4L2Buffer *buf)
>> return AVCOL_TRC_UNSPECIFIED;
>> }
>> +static void v4l2_get_interlacing(AVFrame *frame, V4L2Buffer *buf)
>> +{
>> +enum v4l2_field field;
>> +field = V4L2_TYPE_IS_MULTIPLANAR(buf->buf.type) ?
>> +buf->context->format.fmt.pix_mp.field :
>> +buf->context->format.fmt.pix.field;
>> +
>> +switch (field) {
>> +case V4L2_FIELD_INTERLACED:
>> +case V4L2_FIELD_INTERLACED_TB:
>> +frame->flags |= AV_FRAME_FLAG_TOP_FIELD_FIRST;
>> +/* fallthrough */
>> +case V4L2_FIELD_INTERLACED_BT:
>> +frame->flags |= AV_FRAME_FLAG_INTERLACED;
>> +break;
>> +}
>> +}
>> +
>> static void v4l2_free_buffer(void *opaque, uint8_t *unused)
>> {
>> V4L2Buffer* avbuf = opaque;
>> @@ -434,6 +452,7 @@ int ff_v4l2_buffer_buf_to_avframe(AVFrame *frame,
>> V4L2Buffer *avbuf)
>> frame->color_trc = v4l2_get_color_trc(avbuf);
>> frame->pts = v4l2_get_pts(avbuf);
>> frame->pkt_dts = AV_NOPTS_VALUE;
>> +v4l2_get_interlacing(frame, avbuf);
>>/* these values are updated also during re-init in
>> v4l2_process_driver_event */
>> frame->height = avbuf->context->height;
>
> Should be ok, but i don't maintain (nor can test) v4l2. So if nobody reviews
> it or pushes it in a few days, I'll.
I’m planing to do some test, maybe this weekend.
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2 3/8] avutil/frame: add av_frame_remove_side_data_by_props()
On 12/4/2024 11:51 AM, Niklas Haas wrote:
From: Niklas Haas
As discussed in the previous commit, we often need a convenient way of
stripping all side data related to a certain aspect of the frame. This helper
accomplishes just that.
I considered also adding a way to match only side data matching *all*
properties, but I think this is sufficiently useless in practise to not warrant
inclusion in the API.
---
doc/APIchanges | 4
libavutil/frame.c | 21 +
libavutil/frame.h | 13 +
libavutil/version.h | 2 +-
4 files changed, 39 insertions(+), 1 deletion(-)
diff --git a/doc/APIchanges b/doc/APIchanges
index bce38829ee..e0f778db5a 100644
--- a/doc/APIchanges
+++ b/doc/APIchanges
@@ -2,6 +2,10 @@ The last version increases of all libraries were on 2024-03-07
API changes, most recent first:
+2024-12-xx - xx - lavu 59.49.100 - frame.h
+ Add av_frame_remove_side_data_by_props() and
Don't add two functions, please. Just the one taking pointers to array
and size, which can be used everywhere.
+ av_frame_side_data_remove_by_props().
+
2024-12-xx - xx - lavu 59.48.100 - frame.h
Add AV_SIDE_DATA_PROP_SIZE_DEPENDENT and AV_FRAME_DATA_PROP_COLOR_DEPENDENT.
diff --git a/libavutil/frame.c b/libavutil/frame.c
index 1dced3b52b..d3a45217dc 100644
--- a/libavutil/frame.c
+++ b/libavutil/frame.c
@@ -961,6 +961,22 @@ void av_frame_side_data_remove(AVFrameSideData ***sd, int
*nb_sd,
remove_side_data(sd, nb_sd, type);
}
+void av_frame_side_data_remove_by_props(AVFrameSideData ***sd, int *nb_sd,
+int props)
+{
+for (int i = *nb_sd - 1; i >= 0; i--) {
+AVFrameSideData *entry = ((*sd)[i]);
+const AVSideDataDescriptor *desc =
av_frame_side_data_desc(entry->type);
+if (!desc || !(desc->props & props))
+continue;
+
+free_side_data(&entry);
+
+((*sd)[i]) = ((*sd)[*nb_sd - 1]);
+(*nb_sd)--;
+}
+}
+
AVFrameSideData *av_frame_get_side_data(const AVFrame *frame,
enum AVFrameSideDataType type)
{
@@ -1032,6 +1048,11 @@ void av_frame_remove_side_data(AVFrame *frame, enum
AVFrameSideDataType type)
remove_side_data(&frame->side_data, &frame->nb_side_data, type);
}
+void av_frame_remove_side_data_by_props(AVFrame *frame, int props)
+{
+av_frame_side_data_remove_by_props(&frame->side_data,
&frame->nb_side_data, props);
+}
+
const AVSideDataDescriptor *av_frame_side_data_desc(enum AVFrameSideDataType
type)
{
unsigned t = type;
diff --git a/libavutil/frame.h b/libavutil/frame.h
index 8345010e22..5dfcd85c47 100644
--- a/libavutil/frame.h
+++ b/libavutil/frame.h
@@ -1013,6 +1013,11 @@ AVFrameSideData *av_frame_get_side_data(const AVFrame
*frame,
*/
void av_frame_remove_side_data(AVFrame *frame, enum AVFrameSideDataType type);
+/**
+ * Remove and free all side data instances that match any of the given
+ * side data properties. (See enum AVSideDataProps)
+ */
+void av_frame_remove_side_data_by_props(AVFrame *frame, int props);
/**
* Flags for frame cropping.
@@ -1183,6 +1188,14 @@ const AVFrameSideData
*av_frame_side_data_get(AVFrameSideData * const *sd,
*/
void av_frame_side_data_remove(AVFrameSideData ***sd, int *nb_sd,
enum AVFrameSideDataType type);
+
+/**
+ * Remove and free all side data instances that match any of the given
+ * side data properties. (See enum AVSideDataProps)
+ */
+void av_frame_side_data_remove_by_props(AVFrameSideData ***sd, int *nb_sd,
+int props);
+
/**
* @}
*/
diff --git a/libavutil/version.h b/libavutil/version.h
index efc569e090..ad1f3e68ba 100644
--- a/libavutil/version.h
+++ b/libavutil/version.h
@@ -79,7 +79,7 @@
*/
#define LIBAVUTIL_VERSION_MAJOR 59
-#define LIBAVUTIL_VERSION_MINOR 48
+#define LIBAVUTIL_VERSION_MINOR 49
#define LIBAVUTIL_VERSION_MICRO 100
#define LIBAVUTIL_VERSION_INT AV_VERSION_INT(LIBAVUTIL_VERSION_MAJOR, \
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] Fwd: Your message to ffmpeg-devel awaits moderator approval
Quoting compn (2024-12-19 17:32:26) > On Thu, 19 Dec 2024 14:58:34 +0100, Anton Khirnov wrote: > > > Quoting James Almer (2024-12-19 14:04:53) > > > On 12/19/2024 6:34 AM, Anton Khirnov wrote: > > > > Quoting Kieran Kunhya via ffmpeg-devel (2024-12-19 09:58:14) > > > >> Hello, > > > >> > > > >> My messages are being blocked on the mailing list. How is this fair > > > >> that > > > >> one person can unilaterally decide this? > > > > > > > > This also happened to one mail I sent a few weeks ago. I thought it was > > > > a thread block put in place by CC, but a CC member confirmed to me > > > > recently this was not the case. > > > > > > Which mail? I added rules to block two threads as notified publicly by > > > Ronald since said threads were too heated. > > > > The mail never got to the ML, I am pasting it below. It was in the > > thread: > > "Discussion about mails from 9 years ago Was: [PATCH 1/2] doc/community: > > Add a standard set of rules for software development mailing lists" > > > > I saw no announcement of any CC action related to that thread. > > i didnt moderate that standard*set thread. CC did , as specified here: > > https://lists.ffmpeg.org/pipermail/ffmpeg-devel/2024-December/337678.html Then I apologize for the speculation. Thought I still cannot find any announcement by the CC that the thread in question was blocked. > > Which mail? I added rules to block two threads as notified publicly by > > Ronald since said threads were too heated. > > > > > > > > > > > Indirect evidence points towards compn adding the block in both cases. > > > > IMO it's utterly unacceptable that a random unelected person (not even a > > > > part of GA at that) just unilaterally decides to usurp CC powers and > > > > censor the ML. > > > > > > > > CCing root - I request that ML moderator privileges are removed from > > > > everyone who does not have a legitimate reason to have them (that is > > > > server administrators and CC members). I further request that ONLY CC > > > > members engage in actual moderation (besides approving mails from > > > > non-subscribed people). > > > > > > I have no idea who added the rule for "upcoming vote", but i just > > > removed it. > > > > The reasons I think it was compn are: > > * he replied to email contents in a private IRC message (which btw I > > consider another major abuse of moderator powers) > > i discarded your mail of the mod queue a few hours ago. Unilateral arbitrary censorship, very nice. > yes i tried to talk to you privately about your mail on irc. > your response on irc made me stop talking to you further. > > are you upset that i, as the ml admin, read mails that get stuck in the > moderation queue? Moderator powers give you access to privileged information and also imply certain duties. One which is that you do not use that information for private purposes, which is exactly what you did. As you apparently do not even see the distinction between your role as a moderator and a private person, this just reinforces my conviction that you should not have moderator powers. -- Anton Khirnov ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] Fwd: Your message to ffmpeg-devel awaits moderator approval
On Thu, 19 Dec 2024 17:51:24 +0100, Anton Khirnov wrote: > Quoting compn (2024-12-19 17:32:26) > > On Thu, 19 Dec 2024 14:58:34 +0100, Anton Khirnov wrote: > > > I saw no announcement of any CC action related to that thread. > > > > i didnt moderate that standard*set thread. CC did , as specified here: > > > > https://lists.ffmpeg.org/pipermail/ffmpeg-devel/2024-December/337678.html > > Then I apologize for the speculation. Thought I still cannot find any > announcement by the CC that the thread in question was blocked. no worries. does the CC have a mailing list? said another way, would having a cc mailing list help to organize discussions and decisions / announcements? -compn ___ ffmpeg-devel mailing list ffmpeg-devel@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 12/17] swscale/csputils: add internal colorspace math helpers
Hi On Mon, Dec 16, 2024 at 12:17:33PM +0100, Niklas Haas wrote: > From: Niklas Haas > > Logic is, for the most part, a straight port of similar logic in > liplacebo's colorspace.c, with some general edits and refactors. > --- > libswscale/Makefile | 1 + > libswscale/csputils.c | 418 ++ > libswscale/csputils.h | 114 > 3 files changed, 533 insertions(+) > create mode 100644 libswscale/csputils.c > create mode 100644 libswscale/csputils.h should be ok. I wonder if this couldnt all be done using fix point integers making it all bitexact though thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Democracy is the form of government in which you can choose your dictator 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 14/17] swscale/lut3d: add 3DLUT dispatch system
Hi On Mon, Dec 16, 2024 at 12:17:35PM +0100, Niklas Haas wrote: > From: Niklas Haas > > This is a lightweight wrapper around the underlying color management system, > whose job it is merely to manage the 3DLUT state and apply them to the frame > data. This is where we might add platform-specific optimizations in the > future. > > I also plan on adding support for more pixel formats in the future. In > particular, we could support YUV or XYZ input formats directly using only > negligible additional code in the 3DLUT setup functions. This would eliminate > the major source of slowdown, which is currently the roundtrip to RGBA64. > --- > libswscale/Makefile | 1 + > libswscale/lut3d.c | 290 > libswscale/lut3d.h | 98 +++ > 3 files changed, 389 insertions(+) > create mode 100644 libswscale/lut3d.c > create mode 100644 libswscale/lut3d.h should be ok thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB In fact, the RIAA has been known to suggest that students drop out of college or go to community college in order to be able to afford settlements. -- The RIAA 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] Fwd: Your message to ffmpeg-devel awaits moderator approval
Hi, On Thu, Dec 19, 2024 at 11:51 AM Anton Khirnov wrote: > Quoting compn (2024-12-19 17:32:26) > > i didnt moderate that standard*set thread. CC did , as specified here: > > > > > https://lists.ffmpeg.org/pipermail/ffmpeg-devel/2024-December/337678.html > > Then I apologize for the speculation. Thought I still cannot find any > announcement by the CC that the thread in question was blocked. > > > > Which mail? I added rules to block two threads as notified publicly by > > > Ronald since said threads were too heated. > Just https://ffmpeg.org//pipermail/ffmpeg-devel/2024-November/336701.html I did not send a second email in the standard*set thread, maybe I should have done that. No additional threads were blocked. Ronald ___ ffmpeg-devel mailing list ffmpeg-devel@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 15/17] swscale/graph: add color mapping pass
On Mon, Dec 16, 2024 at 12:17:36PM +0100, Niklas Haas wrote: > From: Niklas Haas > > This leverages the previously introduced color management subsystem in order > to adapt between transfer functions and color spaces, as well as for HDR tone > mapping. > > Take special care to handle grayscale formats without a colorspace > gracefully. > --- > libswscale/graph.c | 95 +- > 1 file changed, 93 insertions(+), 2 deletions(-) still ok and also all previously approved ones obviously thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB If a bugfix only changes things apparently unrelated to the bug with no further explanation, that is a good sign that the bugfix is wrong. signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2 09/17] avfilter/vf_scale: add colorspace and transfer property options
Hi On Mon, Dec 16, 2024 at 12:17:30PM +0100, Niklas Haas wrote: > From: Niklas Haas > > In the long run, it would be ideal if we could add these to the avfilter > negotiation as well, but for now, this is a good start. > --- > doc/filters.texi | 56 > libavfilter/vf_scale.c | 73 +- > 2 files changed, 128 insertions(+), 1 deletion(-) LGTM thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB No snowflake in an avalanche ever feels responsible. -- Voltaire signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2 11/17] avfilter/vf_scale: strip metadata when changing colorspace
On Mon, Dec 16, 2024 at 12:17:32PM +0100, Niklas Haas wrote: > From: Niklas Haas > > This is no longer relevant after a change in color space. > --- > libavfilter/vf_scale.c | 12 > 1 file changed, 12 insertions(+) LGTM thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Homeopathy is like voting while filling the ballot out with transparent ink. Sometimes the outcome one wanted occurs. Rarely its worse than filling out a ballot properly. 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] Fwd: Your message to ffmpeg-devel awaits moderator approval
On Thu, 19 Dec 2024 20:40:55 +, Kieran Kunhya via ffmpeg-devel wrote: > Please can you confirm you will be resigning your moderator status in light > of the election censorship you have undertaken while at the same time being > a candidate for CC? i have no intention to resign from being ml admin. i took the initiative to moderate the thread from flames, but as another ml admin undid said moderation. not much i can do. i'm not getting into any revert wars with other admins. -compn ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 2/3] arm: vp9mc: Load only 12 pixels in the 4 pixel wide horizontal filter
This reduces the amount the horizontal filters read beyond the filter
width to a consistent 1 pixel. The data is not used so this is usually
not noticeable. It becomes a problem when the application allocates
frame buffers only for the aligned picture size and the end of it is at
a page boundary. This happens for picture sizes which are a multiple of
the page size like 1280x640. The frame buffer allocation is based on
its most likely done via mmap + MAP_ANONYMOUS so start and end of the
buffer are page aligned and the previous and next page are not
necessarily mapped.
This mirrors the aarch64 change.
Signed-off-by: Janne Grunau
---
libavcodec/arm/vp9mc_neon.S | 13 ++---
1 file changed, 10 insertions(+), 3 deletions(-)
diff --git a/libavcodec/arm/vp9mc_neon.S b/libavcodec/arm/vp9mc_neon.S
index bd8cda7c308f..2ec729bb314d 100644
--- a/libavcodec/arm/vp9mc_neon.S
+++ b/libavcodec/arm/vp9mc_neon.S
@@ -279,11 +279,13 @@ function \type\()_8tap_\size\()h_\idx1\idx2
sub r1, r1, r5
.endif
@ size >= 16 loads two qwords and increments r2,
-@ for size 4/8 it's enough with one qword and no
-@ postincrement
+@ size 4 loads 1 d word, increments r2 and loads 1 32-bit lane
+@ for size 8 it's enough with one qword and no postincrement
.if \size >= 16
sub r3, r3, r5
sub r3, r3, #8
+.elseif \size == 4
+sub r3, r3, #8
.endif
@ Load the filter vector
vld1.16 {q0}, [r12,:128]
@@ -295,9 +297,14 @@ function \type\()_8tap_\size\()h_\idx1\idx2
.if \size >= 16
vld1.8 {d18, d19, d20}, [r2]!
vld1.8 {d24, d25, d26}, [r7]!
-.else
+.elseif \size == 8
vld1.8 {q9}, [r2]
vld1.8 {q12}, [r7]
+.else @ size == 4
+vld1.8 {d18}, [r2]!
+vld1.8 {d24}, [r7]!
+vld1.32 {d19[0]}, [r2]
+vld1.32 {d25[0]}, [r7]
.endif
vmovl.u8q8, d18
vmovl.u8q9, d19
--
2.45.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 3/3] vp9: recon: Use emulated edge to prevent buffer overflows
The arm/aarch64 horizontal filter reads one additional pixel beyond what
the filter uses. This can become an issue if the application does not
allocate larger buffers than what's required for the pixel data. If the
motion vector points to the bottom right edge of the picture this
becomes a read buffer overflow. This triggers segfaults in Firefox for
video resolutions which result in a page aligned picture size like
1280x640.
Prevent this by using emulated edge in this case.
Fixes: https://bugzilla.mozilla.org/show_bug.cgi?id=1881185
Signed-off-by: Janne Grunau
---
libavcodec/vp9recon.c | 8
1 file changed, 8 insertions(+)
diff --git a/libavcodec/vp9recon.c b/libavcodec/vp9recon.c
index ef08ed17c8e5..1f1b99a03c8a 100644
--- a/libavcodec/vp9recon.c
+++ b/libavcodec/vp9recon.c
@@ -319,7 +319,11 @@ static av_always_inline void mc_luma_unscaled(VP9TileData
*td, const vp9_mc_func
// The arm/aarch64 _hv filters read one more row than what actually is
// needed, so switch to emulated edge one pixel sooner vertically
// (!!my * 5) than horizontally (!!mx * 4).
+// The arm/aarch64 _h filters read one more pixel than what actually is
+// needed, so switch to emulated edge if that would read beyond the bottom
+// right block.
if (x < !!mx * 3 || y < !!my * 3 ||
+((x + !!mx * 5 > w - bw) && (y + !!my * 5 + 1 > h - bh)) ||
x + !!mx * 4 > w - bw || y + !!my * 5 > h - bh) {
s->vdsp.emulated_edge_mc(td->edge_emu_buffer,
ref - !!my * 3 * ref_stride - !!mx * 3 *
bytesperpixel,
@@ -358,7 +362,11 @@ static av_always_inline void
mc_chroma_unscaled(VP9TileData *td, const vp9_mc_fu
// The arm/aarch64 _hv filters read one more row than what actually is
// needed, so switch to emulated edge one pixel sooner vertically
// (!!my * 5) than horizontally (!!mx * 4).
+// The arm/aarch64 _h filters read one more pixel than what actually is
+// needed, so switch to emulated edge if that would read beyond the bottom
+// right block.
if (x < !!mx * 3 || y < !!my * 3 ||
+((x + !!mx * 5 > w - bw) && (y + !!my * 5 + 1 > h - bh)) ||
x + !!mx * 4 > w - bw || y + !!my * 5 > h - bh) {
s->vdsp.emulated_edge_mc(td->edge_emu_buffer,
ref_u - !!my * 3 * src_stride_u - !!mx * 3 *
bytesperpixel,
--
2.45.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 1/3] aarch64: vp9mc: Load only 12 pixels in the 4 pixel wide horizontal filter
This reduces the amount the horizontal filters read beyond the filter
width to a consistent 1 pixel. The data is not used so this is usually
not noticeable. It becomes a problem when the application allocates
frame buffers only for the aligned picture size and the end of it is at
a page boundary. This happens for picture sizes which are a multiple of
the page size like 1280x640. The frame buffer allocation is based on
its most likely done via mmap + MAP_ANONYMOUS so start and end of the
buffer are page aligned and the previous and next page are not
necessarily mapped.
Under these conditions like seen by Firefox a read beyond the end of the
buffer results in a segfault.
After the over-read is reduced to a single pixel it's reasonable to use
VP9's emulated edge motion compensation for this.
Fixes: https://bugzilla.mozilla.org/show_bug.cgi?id=1881185
Signed-off-by: Janne Grunau
---
libavcodec/aarch64/vp9mc_neon.S | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/libavcodec/aarch64/vp9mc_neon.S b/libavcodec/aarch64/vp9mc_neon.S
index abf2bae9db07..38f44ca56d0d 100644
--- a/libavcodec/aarch64/vp9mc_neon.S
+++ b/libavcodec/aarch64/vp9mc_neon.S
@@ -230,6 +230,9 @@ function \type\()_8tap_\size\()h_\idx1\idx2
// reduced dst stride
.if \size >= 16
sub x1, x1, x5
+.elseif \size == 4
+add x12, x2, #8
+add x13, x7, #8
.endif
// size >= 16 loads two qwords and increments x2,
// for size 4/8 it's enough with one qword and no
@@ -248,9 +251,14 @@ function \type\()_8tap_\size\()h_\idx1\idx2
.if \size >= 16
ld1 {v4.8b, v5.8b, v6.8b}, [x2], #24
ld1 {v16.8b, v17.8b, v18.8b}, [x7], #24
-.else
+.elseif \size == 8
ld1 {v4.8b, v5.8b}, [x2]
ld1 {v16.8b, v17.8b}, [x7]
+.else // \size == 4
+ld1 {v4.8b}, [x2]
+ld1 {v16.8b}, [x7]
+ld1 {v5.s}[0], [x12], x3
+ld1 {v17.s}[0], [x13], x3
.endif
uxtlv4.8h, v4.8b
uxtlv5.8h, v5.8b
--
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] Fwd: Your message to ffmpeg-devel awaits moderator approval
On Thu, 19 Dec 2024, 20:30 compn, wrote: > On Thu, 19 Dec 2024 20:15:10 +, Kieran Kunhya via ffmpeg-devel > wrote: > > > Some Animals are More Equal Than Others. > > > > Kieran > > and now a CC candidate calling devs animals ? > This is one of the most famous literary quotes: https://www.dictionary.com/browse/all-animals-are-equal--but-some-animals-are-more-equal-than-others It's interesting how Michael's bizarre signature quotes are of no concern to you yet this one is. Also I'm not a CC candidate. Voters should keep in mind the outright slide towards authoritarianism in this 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] Fwd: Your message to ffmpeg-devel awaits moderator approval
On Thu, 19 Dec 2024 20:15:10 +, Kieran Kunhya via ffmpeg-devel wrote: > Some Animals are More Equal Than Others. > > Kieran and now a CC candidate calling devs animals ? -compn ___ ffmpeg-devel mailing list ffmpeg-devel@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] Fwd: Your message to ffmpeg-devel awaits moderator approval
On Thu, 19 Dec 2024 20:35:43 +, Kieran Kunhya via ffmpeg-devel wrote: > On Thu, 19 Dec 2024, 20:30 compn, wrote: > > > On Thu, 19 Dec 2024 20:15:10 +, Kieran Kunhya via ffmpeg-devel > > wrote: > > > > > Some Animals are More Equal Than Others. > > > > > > Kieran > > > > and now a CC candidate calling devs animals ? > > > > This is one of the most famous literary quotes: > https://www.dictionary.com/browse/all-animals-are-equal--but-some-animals-are-more-equal-than-others > > It's interesting how Michael's bizarre signature quotes are of no concern > to you yet this one is. > > Also I'm not a CC candidate. my bad. -compn ___ ffmpeg-devel mailing list ffmpeg-devel@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] Fwd: Your message to ffmpeg-devel awaits moderator approval
On Thu, 19 Dec 2024, 20:38 compn, wrote: > On Thu, 19 Dec 2024 20:35:43 +, Kieran Kunhya via ffmpeg-devel > wrote: > > > On Thu, 19 Dec 2024, 20:30 compn, wrote: > > > > > On Thu, 19 Dec 2024 20:15:10 +, Kieran Kunhya via ffmpeg-devel > > > wrote: > > > > > > > Some Animals are More Equal Than Others. > > > > > > > > Kieran > > > > > > and now a CC candidate calling devs animals ? > > > > > > > This is one of the most famous literary quotes: > > > https://www.dictionary.com/browse/all-animals-are-equal--but-some-animals-are-more-equal-than-others > > > > It's interesting how Michael's bizarre signature quotes are of no concern > > to you yet this one is. > > > > Also I'm not a CC candidate. > > my bad. > > -compn > Please can you confirm you will be resigning your moderator status in light of the election censorship you have undertaken while at the same time being a candidate for CC? 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] [ANNOUNCE] upcoming vote: CC election
Hi On Wed, Dec 18, 2024 at 07:40:43PM -1000, compn wrote: > On Thu, 19 Dec 2024 03:22:46 +0100, Michael Niedermayer wrote: > > i think we need to have a separate mailing list to talk about non > development stuff. > > i think there are a lot of people who wish to contribute to ffmpeg and > develop on ffmpeg but they dont care about booths or which dev said > what to what other dev. I think the "which dev said what" belongs nowhere (with extreemly few exceptions like maybe in a thread about CC candidates so they can talk about their plans) threads about booths need to be more positive and friendlier thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Some people wanted to paint the bikeshed green, some blue and some pink. People argued and fought, when they finally agreed, only rust was left. 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] [ANNOUNCE] upcoming vote: CC election
Hi Kieran First before replying, id like to say, that i hope we can resolve this and in the future work together in a mutually more friendly way. On Wed, Dec 18, 2024 at 10:18:20PM -0500, Kieran Kunhya via ffmpeg-devel wrote: > > 1a. Prior context: > > For a long time FFmpeg booths where organized by various FFmpeg developers > > like Thilo but also others. They where always announced publically, they > > surely had a touch of hobbyists and a "non professional" community > > > > On NAB 2023 theres a booth paid by VideoLabs, with VideoLabs money to > > promote consulting on open source projects. > > it used the FFmpeg name and logo. Without the FFmpeg community knowing > > about it or approving it. > > They gave out videolabs buisness cards > > Kieran and jb where the 2 people from FFmpeg associated with this booth. > > I was not associated with this booth, I merely carried some items to > assist those constructing. > Thilo was present on this booth too. I belive Thilo was merely a visitor, but thats something he would have to confirm. And i dont want to drag him into this thread as there is (at least currently) little value in that. [...] > It's important for the community to know what address is associated > with the booth. I disagree. > > > 2. and the most recent case > > Nicolas was banned twice from FFmpeg by the CC, Kieran was never banned by > > the CC > > > > If you look at the thread "RFC: complete rework of s337m support" > > Kieran provocates Nicolas, > > Nicolas replies quite offensively to Kieran > > Kieran reports this to the CC > > and jb and ronald vote for a third ban of Nicolas, > > ronald states that he would not have voted for a ban if Nicolas apologized. > > > > Various people have been offensive, few have appologized, some people have > > been > > banned repeatedly, many have never been banned. > > Bans are often a bad solution but they should be used consistently. > > > > I see a bias in the CCs decissions. > > Some people say there is no bias. My first question, do you see a bias in > > the CCs decissions ? (as a whole not based on what i write here) > > And if so what do you plan to do about it ? > > But your opinions in this thread are not biased and are factual? Everyone sees events from their location and perspective. thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB No human being will ever know the Truth, for even if they happen to say it by chance, they would not even known they had done so. -- Xenophanes 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] [ANNOUNCE] upcoming vote: CC election
On Thu, Dec 19, 2024 at 7:25 PM Michael Niedermayer wrote: > > Hi Kieran > > First before replying, id like to say, that i hope we can resolve this and > in the future work together in a mutually more friendly way. > > On Wed, Dec 18, 2024 at 10:18:20PM -0500, Kieran Kunhya via ffmpeg-devel > wrote: > > > 1a. Prior context: > > > For a long time FFmpeg booths where organized by various FFmpeg developers > > > like Thilo but also others. They where always announced publically, they > > > surely had a touch of hobbyists and a "non professional" community > > > > > > On NAB 2023 theres a booth paid by VideoLabs, with VideoLabs money to > > > promote consulting on open source projects. > > > it used the FFmpeg name and logo. Without the FFmpeg community knowing > > > about it or approving it. > > > They gave out videolabs buisness cards > > > Kieran and jb where the 2 people from FFmpeg associated with this booth. > > > > I was not associated with this booth, I merely carried some items to > > assist those constructing. > > > Thilo was present on this booth too. > > I belive Thilo was merely a visitor, but thats something he would have to > confirm. > And i dont want to drag him into this thread as there is (at least currently) > little value in that. Thilo stayed at the same place as the people constructing and staffing the booth. He also was present on the booth. Interesting how I need to answer for myself but Thilo does not in your worldview. > > It's important for the community to know what address is associated > > with the booth. > > I disagree. So it could be any corporation and you'd be ok with that? 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] Fwd: Your message to ffmpeg-devel awaits moderator approval
On 2024-12-19 06:46 -1000, compn wrote: > On Thu, 19 Dec 2024 13:16:23 -0300, James Almer wrote: > > > On 12/19/2024 1:12 PM, compn wrote: > > > On Thu, 19 Dec 2024 10:04:53 -0300, James Almer wrote: > > >> I have no idea who added the rule for "upcoming vote", but i just > > >> removed it. > > >> > > > > > > i added upcoming vote to mod as devs were getting personal about booths > > > and whatnot. as you've removed it, now we see the flames on the list. > > > > You can't silently and unilaterally add a filter to stop a thread in its > > tracks. That is something that needs to go through the CC, and publicly > > announced. > > could you link me to the actual rules that state any of this? > > none of what you said is in the ffmpeg code of conduct. > https://ffmpeg.org/community.html > > if you cannot link me to rules that show any of what you said i broke > the rules of, i would like an apology. > > > It speaks poorly of how you would perform as part of the CC if you think > > acting alone and making bad use of your ml admin privileges is ok. > > keeping out flames is part of the ml admin duties. see for ex: > emergency moderation, moderate all users, mod individual, spam filtering > options. > > these stop flames duties were told to me by previous roots > (gabu, diego) and current roots (michael, alex). I agree that ml admins are needed and need to take action sometimes. I *fully disagree* with silent action like it happened in this case. If such an action is taken, that should be clearly communicated right here; and what it is about, how long it will last and what's going to happen with the queued emails. The decentralized/freedom aspects of email are a strong part about what makes email good. Thank you Kieran for complaining about this by opening this thread! Alexander > > reading the mails stuck in the moderation queue and clearing the > moderation queue is also part of the duties of the ml admin. > > -compn ___ ffmpeg-devel mailing list ffmpeg-devel@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] [ANNOUNCE] upcoming vote: CC election
Hi On Thu, Dec 19, 2024 at 08:27:50AM -0500, Ronald S. Bultje wrote: > Hi, > > On Thu, Dec 19, 2024 at 8:05 AM Kieran Kunhya via ffmpeg-devel < > ffmpeg-devel@ffmpeg.org> wrote: > > > On Thu, 19 Dec 2024, 02:22 Michael Niedermayer, > > wrote: > > > > > Kieran reports this to the CC > > > and jb and ronald vote for a third ban of Nicolas, > > > ronald states that he would not have voted for a ban if Nicolas > > apologized. > > > > The "if Nicolas had apologized" part is a bit terse, there's things going yes, i in fact seem to have missed the mail you sent to Nicolas. It is in my inbox but i must have thought that was also going to -devel so i skiped it thinking id read it later on -devel. Probably the subject "Re: [FFmpeg-devel] ... helped that confusion thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Those who are best at talking, realize last or never when they are wrong. signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] Your message to ffmpeg-devel awaits moderator approval
Hi On Thu, Dec 19, 2024 at 11:12:21AM +0100, Marvin Scholz wrote: > > > On 19 Dec 2024, at 10:34, Anton Khirnov wrote: > > > Quoting Kieran Kunhya via ffmpeg-devel (2024-12-19 09:58:14) > >> Hello, > >> > >> My messages are being blocked on the mailing list. How is this fair that > >> one person can unilaterally decide this? > > > > This also happened to one mail I sent a few weeks ago. I thought it was > > a thread block put in place by CC, but a CC member confirmed to me > > recently this was not the case. > > > > Indirect evidence points towards compn adding the block in both cases. > > IMO it's utterly unacceptable that a random unelected person (not even a > > part of GA at that) just unilaterally decides to usurp CC powers and > > censor the ML. > > > > CCing root - I request that ML moderator privileges are removed from > > everyone who does not have a legitimate reason to have them (that is > > server administrators and CC members). I further request that ONLY CC > > members engage in actual moderation (besides approving mails from > > non-subscribed people). > > I agree on that, whoever implemented such moderation rule, especially for > a thread about the next CC vote, should have their access to be able to do > this revoked immediately > as this is a clear abuse of admin powers. If people want, iam sure anton can extend the end date of the vote so any surge in debate or any temporary moderation to calm a debate has no effect on the vote. 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".
Re: [FFmpeg-devel] Coverity access
Hi Kieran (also thx to compn for reminding me about this mail) On Fri, Dec 13, 2024 at 01:30:43AM +, Kieran Kunhya via ffmpeg-devel wrote: > Hello, > > This person asked for coverity access: > https://x.com/acentauri92/status/1867186643704099105 > > I don't know if they should have access. In the past i have given access to everyone i recognized as a FFmpeg developer/contributor and have not replied to everyone else. Based on the idea that someone else might recognize a requester Is this someone you know ? The name doesnt ring a bell git log --author centauri shows nothing thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Everything should be made as simple as possible, but not simpler. -- Albert Einstein 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 06/14] avformat/flvenc: refactor fourcc writing
Hi
On Tue, Dec 17, 2024 at 11:23:39PM +0100, Timo Rothenpieler wrote:
> On 15.12.2024 23:41, Michael Niedermayer wrote:
> > Hi Timo
> >
> > On Thu, Dec 12, 2024 at 08:55:31PM +0100, Timo Rothenpieler wrote:
> > > ---
> > > libavformat/flvenc.c | 96 ++--
> > > 1 file changed, 47 insertions(+), 49 deletions(-)
> > >
> > > diff --git a/libavformat/flvenc.c b/libavformat/flvenc.c
> > > index 21e2bca5be..fbe5416353 100644
> > > --- a/libavformat/flvenc.c
> > > +++ b/libavformat/flvenc.c
> > > @@ -493,6 +493,45 @@ static void write_metadata(AVFormatContext *s,
> > > unsigned int ts)
> > > avio_wb32(pb, flv->metadata_totalsize + 11);
> > > }
> > > +static void write_codec_fourcc(AVIOContext *pb, enum AVCodecID codec_id)
> > > +{
> > > +switch (codec_id) {
> > > +case AV_CODEC_ID_AAC:
> > > +avio_write(pb, "mp4a", 4);
> > > +return;
> > > +case AV_CODEC_ID_OPUS:
> > > +avio_write(pb, "Opus", 4);
> > > +return;
> > > +case AV_CODEC_ID_FLAC:
> > > +avio_write(pb, "fLaC", 4);
> > > +return;
> > > +case AV_CODEC_ID_MP3:
> > > +avio_write(pb, ".mp3", 4);
> > > +return;
> > > +case AV_CODEC_ID_AC3:
> > > +avio_write(pb, "ac-3", 4);
> > > +return;
> > > +case AV_CODEC_ID_EAC3:
> > > +avio_write(pb, "ec-3", 4);
> > > +return;
> > > +case AV_CODEC_ID_H264:
> > > +avio_write(pb, "avc1", 4);
> > > +return;
> > > +case AV_CODEC_ID_HEVC:
> > > +avio_write(pb, "hvc1", 4);
> > > +return;
> > > +case AV_CODEC_ID_AV1:
> > > +avio_write(pb, "av01", 4);
> > > +return;
> > > +case AV_CODEC_ID_VP9:
> > > +avio_write(pb, "vp09", 4);
> > > +return;
> > > +default:
> > > +av_log(NULL, AV_LOG_ERROR, "Invalid codec FourCC write
> > > requested.\n");
> > > +av_assert0(0);
> > > +}
> > > +}
> >
> > from the commit message i would have thought i would see something
> > similar to ff_codec_bmp_tags[]
> >
> > such a table is more compact and can be used in both directions
>
> I implemented it like this since it's in the hot path of the muxer, and
> iterating over an array seems a bit unnecessary there.
hmm
doing
streamcontext->fourcc = write_codec_fourcc()
once and then reusing context->fourcc
is faster, if we write large quantities of fourccs
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Give a rich man 100$ and he will turn it into 1000$.
Give a poor man 1000$ and he will spend it.
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] [PATCHv2 1/2] avformat/iff: SndAnim decoding
On Wed, Dec 11, 2024 at 09:27:51AM +1100, Peter Ross wrote: > Fixes ticket #5553. > --- > Additional hardening thanks to target_dem_fuzzer.c > > libavformat/iff.c | 311 +++--- > 1 file changed, 210 insertions(+), 101 deletions(-) > will apply -- Peter (A907 E02F A6E5 0CD2 34CD 20D2 6760 79C5 AC40 DD6B) 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] [ANNOUNCE] upcoming vote: CC election
Hi, On Thu, Dec 19, 2024 at 2:02 PM Michael Niedermayer wrote: > Hi > > On Thu, Dec 19, 2024 at 08:27:50AM -0500, Ronald S. Bultje wrote: > > Hi, > > > > On Thu, Dec 19, 2024 at 8:05 AM Kieran Kunhya via ffmpeg-devel < > > ffmpeg-devel@ffmpeg.org> wrote: > > > > > On Thu, 19 Dec 2024, 02:22 Michael Niedermayer, < > mich...@niedermayer.cc> > > > wrote: > > > > > > > Kieran reports this to the CC > > > > and jb and ronald vote for a third ban of Nicolas, > > > > ronald states that he would not have voted for a ban if Nicolas > > > apologized. > > > > > > > The "if Nicolas had apologized" part is a bit terse, there's things going > > yes, i in fact seem to have missed the mail you sent to Nicolas. It is in > my inbox but i must have thought that was also going to -devel so i skiped > it thinking id read it later on -devel. Probably the subject > "Re: [FFmpeg-devel] ... > helped that confusion > Perhaps a good lesson / suggestion for the next CC to change email subjects when responding to "calamities" :-). Ronald ___ ffmpeg-devel mailing list ffmpeg-devel@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] [ANNOUNCE] upcoming vote: CC election
Hi Marth64 On Wed, Dec 18, 2024 at 10:27:40PM -0600, Marth64 wrote: > Hi Michael, > > > 2. and the most recent case > Continuing where I left off. > > Let us analyze the s337m situation. > * Contributor shares significant work, as an RFC, in good faith > * A back and forth exchange happens with technical feedback and history > * Then, two senior contributors exchange inflammatory remarks, > presumably fueled by damaged relations > * Conversation was reported to CC but outcome could not be reconciled > with consistent enforcement > > The s337 thread actually is irrelevant to the broader issue, but let > us pick it apart for a minute. > This particular thread should have been handled in two angles, > > (1) The technical debate between the senior engineers should have been > weighed in on by TC > Yes, TC wasn't directly "summoned", but I imagine we can employ some > proactivity if we see a tense > technical discussion. The point of the TC, in my eyes, is to settle > deadlocked technical debates. > That is, as a collective response from the TC. Even if that is, "We > already talked about this once, case closed." > > (2) The inflammatory remarks weren't moderated. This is the broader issue. > These types of interactions are different from some random person > coming on say, IRC, and offending people. > These are senior contributors in a deeply fueled discussion. No ban > will fix this. > > In fact, saying the word ban, voting for a ban, or applying a ban > doesn't seem to do anything. > Based on the example you provided, even after 3 attempts some people don't > care. > I'm not saying we jump to ban people. This is not a PHP video games forum. > But, waving the word "ban" should be used judiciously and may need to > be redefined, so that it is taken seriously. > Likewise, exercising and applying the ban should be taken seriously > too, especially when considering senior contributors. > Rubber voting/stamping bans and ignoring similar offenses is not > effective. I would hope a CC of 5 can work through this. > > So we need to be more clear with a nudge of improvement and push: get > this toxicity off the ML. [...] > Folks should be encouraged to think, > (1) Is what you're saying adding value and even relevant to the conversation? > (2) If we're stuck in a bitter technical debate, can the TC help? (yes > probably) > (3) Did I buffer my thoughts or react on impulse? > (4) Could I have ignored the "igniting" remark and focused on the > technical part of the discussion? I fully agree > > We have a Code of Conduct, does it need to be improved? I tried (with a text written by a LLM so it was fully neutral and not "my" text) and it had immedeate opposition maybe you can take a look at that patch and see if that combined with your suggestions could be a starting point Btw, i also wanted to say, in case you fail to receive enough support for a CC seat. Please ignore that and try to help anyway the ffmpeg community is in need for your help, i think thx -- 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] Fwd: Your message to ffmpeg-devel awaits moderator approval
Hi compn On Thu, Dec 19, 2024 at 06:16:03AM -1000, compn wrote: > On Thu, 19 Dec 2024 08:58:14 +, Kieran Kunhya via ffmpeg-devel > wrote: > > > Hello, > > > > My messages are being blocked on the mailing list. > > your message, and the message of others in that specific thread was > not blocked. it was held for moderator approval as you quoted below. > > > The reason it is being held: > > > > Header matched regexp: ^Subject:.*upcoming.*vote > > > > Either the message will get posted to the list, or you will receive > > notification of the moderator's decision. If you would like to cancel > > this posting, please visit the following URL: > > > How is this fair that one person can unilaterally decide this? > > as ml admin if i see flames i try to tamper them down a bit. This was a brave decission and IMO it was the correct decission. You saw people fighting, and you stepped between them to stop it. thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB When you are offended at any man's fault, turn to yourself and study your own failings. Then you will forget your anger. -- Epictetus signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avfilter/vf_scale: remove systematic PAL8 hack
Hi On Wed, Dec 18, 2024 at 12:48:03PM -0500, Ronald S. Bultje wrote: > Hi, > > On Wed, Dec 18, 2024 at 5:29 AM Niklas Haas wrote: > > > On Wed, 18 Dec 2024 02:32:07 +0100 Michael Niedermayer < > > mich...@niedermayer.cc> wrote: > > > Hi > > > > > > On Tue, Dec 17, 2024 at 10:31:42AM +0100, Niklas Haas wrote: > > > > On Tue, 17 Dec 2024 01:48:02 +0100 Michael Niedermayer < > > mich...@niedermayer.cc> wrote: > > > > > Hi > > > > > > > > > > On Mon, Dec 16, 2024 at 02:57:53PM +0100, Niklas Haas wrote: > > > > > > From: Niklas Haas > > > > > > > > > > > > This is not a good way of generating a PAL8 output. > > > > > > > > > > of course not > > > > > > > > > > but this breaks fate and features > > > > > > > > It doesn't really break a feature because we have a better replacement > > already > > > > included in libavfilter, IMO. > > > > > > swscale could convert to pal8 before, it cant after the patch. > > > So it lost a feature and breaks users code unless iam missing > > > something ? > > > > It is worth pointing out that *libswscale* does not directly output PAL8; > > this rather is (and always was) handled by vf_scale. So in some sense, this > > functionality already depends on libavfilter. > > > > That said, I do agree that simply regressing existing use cases should not > > be done without some sort of mechanism for automatically invoking the > > proper > > replacement. > > > > I will retract this patch for now, then, and put the corresponding issue on > > hold. I think that a full discussion of how to handle this better will have > > to wait until we have a better dither handling inside swscale. > > > > I would commit it, but instead of failing, emit a warning (recommending to > use the palettegen filter instead) and continue the old behaviour (as a > fallback). A future libswscale could include palettegen. (which would fix this issue instead of requiring users to switch to a different filter that may not even be available in the software they are using) thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB If you think the mosad wants you dead since a long time then you are either wrong or dead since a long time. signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v3 01/16] avformat/flvenc: implement support for multi-track video
From: Dennis Sädtler
Based on enhanced-rtmp v2 spec published by Veovera:
https://veovera.github.io/enhanced-rtmp/docs/enhanced/enhanced-rtmp-v2
This implementation maintains some backwards compatibility by only
writing the track information for track indices > 0. This means that
older FFmpeg versions - and possibly other software - can still read the
first video track properly and skip over unsupported packets.
Signed-off-by: Dennis Sädtler
---
libavformat/flv.h| 7 ++
libavformat/flvenc.c | 160 ++-
2 files changed, 120 insertions(+), 47 deletions(-)
diff --git a/libavformat/flv.h b/libavformat/flv.h
index f710963b92..653c2bc82c 100644
--- a/libavformat/flv.h
+++ b/libavformat/flv.h
@@ -125,6 +125,13 @@ enum {
PacketTypeCodedFramesX = 3,
PacketTypeMetadata = 4,
PacketTypeMPEG2TSSequenceStart = 5,
+PacketTypeMultitrack= 6,
+};
+
+enum {
+ MultitrackTypeOneTrack = 0x00,
+ MultitrackTypeManyTracks = 0x10,
+ MultitrackTypeManyTracksManyCodecs = 0x20,
};
enum {
diff --git a/libavformat/flvenc.c b/libavformat/flvenc.c
index 1c7ba61776..b40770bb8a 100644
--- a/libavformat/flvenc.c
+++ b/libavformat/flvenc.c
@@ -126,8 +126,9 @@ typedef struct FLVContext {
AVCodecParameters *data_par;
int flags;
-int64_t last_ts[FLV_STREAM_TYPE_NB];
-int metadata_pkt_written;
+int64_t *last_ts;
+int *metadata_pkt_written;
+int *video_track_idx_map;
} FLVContext;
static int get_audio_flags(AVFormatContext *s, AVCodecParameters *par)
@@ -485,7 +486,7 @@ static void write_metadata(AVFormatContext *s, unsigned int
ts)
avio_wb32(pb, flv->metadata_totalsize + 11);
}
-static void flv_write_metadata_packet(AVFormatContext *s, AVCodecParameters
*par, unsigned int ts)
+static void flv_write_metadata_packet(AVFormatContext *s, AVCodecParameters
*par, unsigned int ts, int stream_idx)
{
AVIOContext *pb = s->pb;
FLVContext *flv = s->priv_data;
@@ -495,7 +496,9 @@ static void flv_write_metadata_packet(AVFormatContext *s,
AVCodecParameters *par
int64_t total_size = 0;
const AVPacketSideData *side_data = NULL;
-if (flv->metadata_pkt_written) return;
+if (flv->metadata_pkt_written[stream_idx])
+return;
+
if (par->codec_id == AV_CODEC_ID_HEVC || par->codec_id == AV_CODEC_ID_AV1
||
par->codec_id == AV_CODEC_ID_VP9) {
int flags_size = 5;
@@ -617,7 +620,7 @@ static void flv_write_metadata_packet(AVFormatContext *s,
AVCodecParameters *par
avio_wb24(pb, total_size);
avio_skip(pb, total_size + 10 - 3);
avio_wb32(pb, total_size + 11); // previous tag size
-flv->metadata_pkt_written = 1;
+flv->metadata_pkt_written[stream_idx] = 1;
}
}
@@ -632,7 +635,7 @@ static int unsupported_codec(AVFormatContext *s,
return AVERROR(ENOSYS);
}
-static void flv_write_codec_header(AVFormatContext* s, AVCodecParameters* par,
int64_t ts) {
+static void flv_write_codec_header(AVFormatContext* s, AVCodecParameters* par,
int64_t ts, int stream_index) {
int64_t data_size;
AVIOContext *pb = s->pb;
FLVContext *flv = s->priv_data;
@@ -682,12 +685,32 @@ static void flv_write_codec_header(AVFormatContext* s,
AVCodecParameters* par, i
}
avio_write(pb, par->extradata, par->extradata_size);
} else {
-if (par->codec_id == AV_CODEC_ID_HEVC) {
-avio_w8(pb, FLV_IS_EX_HEADER | PacketTypeSequenceStart |
FLV_FRAME_KEY); // ExVideoTagHeader mode with PacketTypeSequenceStart
-avio_write(pb, "hvc1", 4);
-} else if (par->codec_id == AV_CODEC_ID_AV1 || par->codec_id ==
AV_CODEC_ID_VP9) {
-avio_w8(pb, FLV_IS_EX_HEADER | PacketTypeSequenceStart |
FLV_FRAME_KEY);
-avio_write(pb, par->codec_id == AV_CODEC_ID_AV1 ? "av01" :
"vp09", 4);
+int track_idx = flv->video_track_idx_map[stream_index];
+// If video stream has track_idx > 0 we need to send H.264 as
extended video packet
+int extended_flv = (par->codec_id == AV_CODEC_ID_H264 &&
track_idx) ||
+par->codec_id == AV_CODEC_ID_HEVC ||
+par->codec_id == AV_CODEC_ID_AV1 ||
+par->codec_id == AV_CODEC_ID_VP9;
+
+if (extended_flv) {
+if (track_idx) {
+avio_w8(pb, FLV_IS_EX_HEADER | PacketTypeMultitrack |
FLV_FRAME_KEY);
+avio_w8(pb, MultitrackTypeOneTrack |
PacketTypeSequenceStart);
+} else {
+avio_w8(pb, FLV_IS_EX_HEADER | PacketTypeSequenceStart |
FLV_FRAME_KEY);
+}
+
+if (par->codec_id == AV_CODEC_ID_H264)
+avio_write(pb, "avc1", 4);
+else if (par->codec_id == AV_CODEC_ID_HEVC)
+
[FFmpeg-devel] [PATCH v3 00/16] Implement enhanced rtmp/flv v2 spec
This should address most of the comments received on the previous iteration. Added a test, and found one more issue that allowed muxing invalid files, which is fixed by patch 16/16. Dennis Sädtler (2): avformat/flvenc: implement support for multi-track video avformat/flvdec: add support for demuxing multi-track FLV Timo Rothenpieler (14): avformat/flvenc: add enhanced audio codecs avformat/flvenc: remove !size check for audio packets avformat/flvdec: add enhanced audio codecs avformat/flvenc: refactor fourcc writing avformat/flvenc: write enhanced rtmp multichannel info for audio with more than two channels avformat/flvdec: parse enhanced rtmp multichannel info avformat/flvenc: add support for writing multi track audio avformat/flvdec: add support for reading multi track audio avformat/rtmpproto: add more enhanced rtmp codecs avformat/flvdec: stop shadowing local variables avformat/flvdec: support all multi-track modes avformat/rtmpproto: reserve enough space for statusmsg fate/flvenc: add test for multitrack flv avformat/flvenc: prevent writing legacy codecs into extended video tracks libavformat/flv.h | 21 + libavformat/flvdec.c | 663 + libavformat/flvenc.c | 458 + libavformat/rtmpproto.c| 11 +- tests/fate/flvenc.mak | 4 + tests/ref/fate/enhanced-flv-multitrack | 526 6 files changed, 1372 insertions(+), 311 deletions(-) create mode 100644 tests/ref/fate/enhanced-flv-multitrack -- 2.45.2 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v3 12/16] avformat/flvdec: stop shadowing local variables
---
libavformat/flvdec.c | 44 ++--
1 file changed, 22 insertions(+), 22 deletions(-)
diff --git a/libavformat/flvdec.c b/libavformat/flvdec.c
index 15312cfa02..c66c37efa2 100644
--- a/libavformat/flvdec.c
+++ b/libavformat/flvdec.c
@@ -1396,8 +1396,8 @@ retry:
if (enhanced_flv && (flags & FLV_VIDEO_FRAMETYPE_MASK) ==
FLV_FRAME_VIDEO_INFO_CMD) {
if (pkt_type == PacketTypeMetadata) {
-int ret = flv_parse_video_color_info(s, st, next);
-av_log(s, AV_LOG_DEBUG, "enhanced flv parse metadata ret %d
and skip\n", ret);
+int sret = flv_parse_video_color_info(s, st, next);
+av_log(s, AV_LOG_DEBUG, "enhanced flv parse metadata ret %d
and skip\n", sret);
}
goto skip;
} else if ((flags & FLV_VIDEO_FRAMETYPE_MASK) ==
FLV_FRAME_VIDEO_INFO_CMD) {
@@ -1500,25 +1500,25 @@ skip:
if ((s->pb->seekable & AVIO_SEEKABLE_NORMAL) &&
(!s->duration || s->duration == AV_NOPTS_VALUE) &&
!flv->searched_for_end) {
-int size;
+int final_size;
const int64_t pos = avio_tell(s->pb);
// Read the last 4 bytes of the file, this should be the size of the
// previous FLV tag. Use the timestamp of its payload as duration.
int64_t fsize = avio_size(s->pb);
retry_duration:
avio_seek(s->pb, fsize - 4, SEEK_SET);
-size = avio_rb32(s->pb);
-if (size > 0 && size < fsize) {
-// Seek to the start of the last FLV tag at position (fsize - 4 -
size)
+final_size = avio_rb32(s->pb);
+if (final_size > 0 && final_size < fsize) {
+// Seek to the start of the last FLV tag at position (fsize - 4 -
final_size)
// but skip the byte indicating the type.
-avio_seek(s->pb, fsize - 3 - size, SEEK_SET);
-if (size == avio_rb24(s->pb) + 11) {
+avio_seek(s->pb, fsize - 3 - final_size, SEEK_SET);
+if (final_size == avio_rb24(s->pb) + 11) {
uint32_t ts = avio_rb24(s->pb);
ts |= (unsigned)avio_r8(s->pb) << 24;
if (ts)
s->duration = ts * (int64_t)AV_TIME_BASE / 1000;
-else if (fsize >= 8 && fsize - 8 >= size) {
-fsize -= size+4;
+else if (fsize >= 8 && fsize - 8 >= final_size) {
+fsize -= final_size+4;
goto retry_duration;
}
}
@@ -1612,10 +1612,10 @@ retry_duration:
goto leave;
}
} else if (stream_type == FLV_STREAM_TYPE_VIDEO) {
-int ret = flv_set_video_codec(s, st, codec_id, 1);
-if (ret < 0)
-return ret;
-size -= ret;
+int sret = flv_set_video_codec(s, st, codec_id, 1);
+if (sret < 0)
+return sret;
+size -= sret;
} else if (stream_type == FLV_STREAM_TYPE_SUBTITLE) {
st->codecpar->codec_id = AV_CODEC_ID_TEXT;
} else if (stream_type == FLV_STREAM_TYPE_DATA) {
@@ -1705,20 +1705,20 @@ retry_duration:
pkt->stream_index = st->index;
pkt->pos = pos;
if (!multitrack && flv->new_extradata[stream_type]) {
-int ret = av_packet_add_side_data(pkt, AV_PKT_DATA_NEW_EXTRADATA,
- flv->new_extradata[stream_type],
-
flv->new_extradata_size[stream_type]);
-if (ret >= 0) {
+int sret = av_packet_add_side_data(pkt, AV_PKT_DATA_NEW_EXTRADATA,
+ flv->new_extradata[stream_type],
+
flv->new_extradata_size[stream_type]);
+if (sret >= 0) {
flv->new_extradata[stream_type] = NULL;
flv->new_extradata_size[stream_type] = 0;
}
} else if (multitrack &&
flv->mt_extradata_cnt > track_idx &&
flv->mt_extradata[track_idx]) {
-int ret = av_packet_add_side_data(pkt, AV_PKT_DATA_NEW_EXTRADATA,
- flv->mt_extradata[track_idx],
- flv->mt_extradata_sz[track_idx]);
-if (ret >= 0) {
+int sret = av_packet_add_side_data(pkt, AV_PKT_DATA_NEW_EXTRADATA,
+ flv->mt_extradata[track_idx],
+ flv->mt_extradata_sz[track_idx]);
+if (sret >= 0) {
flv->mt_extradata[track_idx] = NULL;
flv->mt_extradata_sz[track_idx] = 0;
}
--
2.45.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v3 11/16] avformat/rtmpproto: add more enhanced rtmp codecs
---
libavformat/rtmpproto.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/libavformat/rtmpproto.c b/libavformat/rtmpproto.c
index b3b1eedacb..bb974390d3 100644
--- a/libavformat/rtmpproto.c
+++ b/libavformat/rtmpproto.c
@@ -356,8 +356,15 @@ static int gen_connect(URLContext *s, RTMPContext *rt)
while(fourcc_data - rt->enhanced_codecs < fourcc_str_len) {
unsigned char fourcc[5];
-if (!strncmp(fourcc_data, "hvc1", 4) ||
+if (!strncmp(fourcc_data, "ac-3", 4) ||
!strncmp(fourcc_data, "av01", 4) ||
+!strncmp(fourcc_data, "avc1", 4) ||
+!strncmp(fourcc_data, "ec-3", 4) ||
+!strncmp(fourcc_data, "fLaC", 4) ||
+!strncmp(fourcc_data, "hvc1", 4) ||
+!strncmp(fourcc_data, ".mp3", 4) ||
+!strncmp(fourcc_data, "mp4a", 4) ||
+!strncmp(fourcc_data, "Opus", 4) ||
!strncmp(fourcc_data, "vp09", 4)) {
av_strlcpy(fourcc, fourcc_data, sizeof(fourcc));
ff_amf_write_string(&p, fourcc);
--
2.45.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v3 03/16] avformat/flvenc: add enhanced audio codecs
---
libavformat/flv.h| 6 ++
libavformat/flvenc.c | 149 +++
2 files changed, 114 insertions(+), 41 deletions(-)
diff --git a/libavformat/flv.h b/libavformat/flv.h
index 653c2bc82c..d030d576f3 100644
--- a/libavformat/flv.h
+++ b/libavformat/flv.h
@@ -103,6 +103,7 @@ enum {
FLV_CODECID_NELLYMOSER = 6 << FLV_AUDIO_CODECID_OFFSET,
FLV_CODECID_PCM_ALAW = 7 << FLV_AUDIO_CODECID_OFFSET,
FLV_CODECID_PCM_MULAW= 8 << FLV_AUDIO_CODECID_OFFSET,
+FLV_CODECID_EX_HEADER= 9 << FLV_AUDIO_CODECID_OFFSET,
FLV_CODECID_AAC = 10<< FLV_AUDIO_CODECID_OFFSET,
FLV_CODECID_SPEEX= 11<< FLV_AUDIO_CODECID_OFFSET,
};
@@ -128,6 +129,11 @@ enum {
PacketTypeMultitrack= 6,
};
+enum {
+AudioPacketTypeSequenceStart = 0,
+AudioPacketTypeCodedFrames= 1,
+};
+
enum {
MultitrackTypeOneTrack = 0x00,
MultitrackTypeManyTracks = 0x10,
diff --git a/libavformat/flvenc.c b/libavformat/flvenc.c
index b40770bb8a..1818b5482a 100644
--- a/libavformat/flvenc.c
+++ b/libavformat/flvenc.c
@@ -69,6 +69,10 @@ static const AVCodecTag flv_audio_codec_ids[] = {
{ AV_CODEC_ID_PCM_MULAW, FLV_CODECID_PCM_MULAW >>
FLV_AUDIO_CODECID_OFFSET },
{ AV_CODEC_ID_PCM_ALAW, FLV_CODECID_PCM_ALAW >>
FLV_AUDIO_CODECID_OFFSET },
{ AV_CODEC_ID_SPEEX, FLV_CODECID_SPEEX >>
FLV_AUDIO_CODECID_OFFSET },
+{ AV_CODEC_ID_OPUS, MKBETAG('O', 'p', 'u', 's') },
+{ AV_CODEC_ID_FLAC, MKBETAG('f', 'L', 'a', 'C') },
+{ AV_CODEC_ID_AC3,MKBETAG('a', 'c', '-', '3') },
+{ AV_CODEC_ID_EAC3, MKBETAG('e', 'c', '-', '3') },
{ AV_CODEC_ID_NONE, 0 }
};
@@ -139,6 +143,9 @@ static int get_audio_flags(AVFormatContext *s,
AVCodecParameters *par)
if (par->codec_id == AV_CODEC_ID_AAC) // specs force these parameters
return FLV_CODECID_AAC | FLV_SAMPLERATE_44100HZ |
FLV_SAMPLESSIZE_16BIT | FLV_STEREO;
+if (par->codec_id == AV_CODEC_ID_OPUS || par->codec_id == AV_CODEC_ID_FLAC
+|| par->codec_id == AV_CODEC_ID_AC3 || par->codec_id ==
AV_CODEC_ID_EAC3)
+return FLV_CODECID_EX_HEADER; // only needed for codec support check
else if (par->codec_id == AV_CODEC_ID_SPEEX) {
if (par->sample_rate != 16000) {
av_log(s, AV_LOG_ERROR,
@@ -635,6 +642,42 @@ static int unsupported_codec(AVFormatContext *s,
return AVERROR(ENOSYS);
}
+static void flv_write_aac_header(AVFormatContext* s, AVCodecParameters* par)
+{
+AVIOContext *pb = s->pb;
+FLVContext *flv = s->priv_data;
+
+if (!par->extradata_size && (flv->flags & FLV_AAC_SEQ_HEADER_DETECT)) {
+PutBitContext pbc;
+int samplerate_index;
+int channels = par->ch_layout.nb_channels
+- (par->ch_layout.nb_channels == 8 ? 1 : 0);
+uint8_t data[2];
+
+for (samplerate_index = 0; samplerate_index < 16;
+samplerate_index++)
+if (par->sample_rate
+== ff_mpeg4audio_sample_rates[samplerate_index])
+break;
+
+init_put_bits(&pbc, data, sizeof(data));
+put_bits(&pbc, 5, par->profile + 1); //profile
+put_bits(&pbc, 4, samplerate_index); //sample rate index
+put_bits(&pbc, 4, channels);
+put_bits(&pbc, 1, 0); //frame length - 1024 samples
+put_bits(&pbc, 1, 0); //does not depend on core coder
+put_bits(&pbc, 1, 0); //is not extension
+flush_put_bits(&pbc);
+
+avio_w8(pb, data[0]);
+avio_w8(pb, data[1]);
+
+av_log(s, AV_LOG_WARNING, "AAC sequence header: %02x %02x.\n",
+data[0], data[1]);
+}
+avio_write(pb, par->extradata, par->extradata_size);
+}
+
static void flv_write_codec_header(AVFormatContext* s, AVCodecParameters* par,
int64_t ts, int stream_index) {
int64_t data_size;
AVIOContext *pb = s->pb;
@@ -642,7 +685,9 @@ static void flv_write_codec_header(AVFormatContext* s,
AVCodecParameters* par, i
if (par->codec_id == AV_CODEC_ID_AAC || par->codec_id == AV_CODEC_ID_H264
|| par->codec_id == AV_CODEC_ID_MPEG4 || par->codec_id ==
AV_CODEC_ID_HEVC
-|| par->codec_id == AV_CODEC_ID_AV1 || par->codec_id ==
AV_CODEC_ID_VP9) {
+|| par->codec_id == AV_CODEC_ID_AV1 || par->codec_id ==
AV_CODEC_ID_VP9
+|| par->codec_id == AV_CODEC_ID_OPUS || par->codec_id ==
AV_CODEC_ID_FLAC
+|| par->codec_id == AV_CODEC_ID_AC3 || par->codec_id ==
AV_CODEC_ID_EAC3) {
int64_t pos;
avio_w8(pb,
par->codec_type == AVMEDIA_TYPE_VIDEO ?
@@ -651,39 +696,38 @@ static void flv_write_codec_header(AVFormatContext* s,
AVCodecParameters* par, i
put_timestamp(pb, ts);
avio_wb24(pb, 0); // streamid
pos = avio_tell(pb);
-if (par->codec_id == A
[FFmpeg-devel] [PATCH v3 02/16] avformat/flvdec: add support for demuxing multi-track FLV
From: Dennis Sädtler
Based on enhanced-rtmp v2 spec published by Veovera:
https://veovera.github.io/enhanced-rtmp/docs/enhanced/enhanced-rtmp-v2
Signed-off-by: Dennis Sädtler
---
libavformat/flvdec.c | 119 +++
1 file changed, 97 insertions(+), 22 deletions(-)
diff --git a/libavformat/flvdec.c b/libavformat/flvdec.c
index 08482eb2db..35d70838e3 100644
--- a/libavformat/flvdec.c
+++ b/libavformat/flvdec.c
@@ -104,6 +104,10 @@ typedef struct FLVContext {
FLVMetaVideoColor *metaVideoColor;
int meta_color_info_flag;
+
+uint8_t **mt_extradata;
+int *mt_extradata_sz;
+int mt_extradata_cnt;
} FLVContext;
/* AMF date type */
@@ -186,7 +190,7 @@ static void add_keyframes_index(AVFormatContext *s)
}
}
-static AVStream *create_stream(AVFormatContext *s, int codec_type)
+static AVStream *create_stream(AVFormatContext *s, int codec_type, int
track_idx)
{
FFFormatContext *const si = ffformatcontext(s);
FLVContext *flv = s->priv_data;
@@ -194,6 +198,11 @@ static AVStream *create_stream(AVFormatContext *s, int
codec_type)
if (!st)
return NULL;
st->codecpar->codec_type = codec_type;
+st->id = track_idx;
+avpriv_set_pts_info(st, 32, 1, 1000); /* 32 bit pts in ms */
+if (track_idx)
+return st;
+
if (s->nb_streams>=3 ||( s->nb_streams==2
&& s->streams[0]->codecpar->codec_type !=
AVMEDIA_TYPE_SUBTITLE
&& s->streams[1]->codecpar->codec_type !=
AVMEDIA_TYPE_SUBTITLE
@@ -210,8 +219,6 @@ static AVStream *create_stream(AVFormatContext *s, int
codec_type)
st->avg_frame_rate = flv->framerate;
}
-
-avpriv_set_pts_info(st, 32, 1, 1000); /* 32 bit pts in ms */
flv->last_keyframe_stream_index = s->nb_streams - 1;
add_keyframes_index(s);
return st;
@@ -351,6 +358,7 @@ static int flv_same_video_codec(AVCodecParameters *vpar,
uint32_t flv_codecid)
case FLV_CODECID_VP6A:
return vpar->codec_id == AV_CODEC_ID_VP6A;
case FLV_CODECID_H264:
+case MKBETAG('a', 'v', 'c', '1'):
return vpar->codec_id == AV_CODEC_ID_H264;
default:
return vpar->codec_tag == flv_codecid;
@@ -407,6 +415,7 @@ static int flv_set_video_codec(AVFormatContext *s, AVStream
*vstream,
ret = 1; // 1 byte body size adjustment for flv_read_packet()
break;
case FLV_CODECID_H264:
+case MKBETAG('a', 'v', 'c', '1'):
par->codec_id = AV_CODEC_ID_H264;
vstreami->need_parsing = AVSTREAM_PARSE_HEADERS;
break;
@@ -676,7 +685,7 @@ static int amf_parse_object(AVFormatContext *s, AVStream
*astream,
} else if (!strcmp(key, "height") && vpar) {
vpar->height = num_val;
} else if (!strcmp(key, "datastream")) {
-AVStream *st = create_stream(s, AVMEDIA_TYPE_SUBTITLE);
+AVStream *st = create_stream(s, AVMEDIA_TYPE_SUBTITLE,
0);
if (!st)
return AVERROR(ENOMEM);
st->codecpar->codec_id = AV_CODEC_ID_TEXT;
@@ -884,8 +893,11 @@ static int flv_read_close(AVFormatContext *s)
{
int i;
FLVContext *flv = s->priv_data;
-for (i=0; inew_extradata[i]);
+for (i = 0; i < flv->mt_extradata_cnt; i++)
+av_freep(&flv->mt_extradata[i]);
+av_freep(&flv->mt_extradata_sz);
av_freep(&flv->keyframe_times);
av_freep(&flv->keyframe_filepositions);
av_freep(&flv->metaVideoColor);
@@ -905,18 +917,47 @@ static int flv_get_extradata(AVFormatContext *s, AVStream
*st, int size)
}
static int flv_queue_extradata(FLVContext *flv, AVIOContext *pb, int stream,
- int size)
+ int size, int multitrack)
{
if (!size)
return 0;
-av_free(flv->new_extradata[stream]);
-flv->new_extradata[stream] = av_mallocz(size +
-AV_INPUT_BUFFER_PADDING_SIZE);
-if (!flv->new_extradata[stream])
-return AVERROR(ENOMEM);
-flv->new_extradata_size[stream] = size;
-avio_read(pb, flv->new_extradata[stream], size);
+if (!multitrack) {
+av_free(flv->new_extradata[stream]);
+flv->new_extradata[stream] = av_mallocz(size +
+AV_INPUT_BUFFER_PADDING_SIZE);
+if (!flv->new_extradata[stream])
+return AVERROR(ENOMEM);
+flv->new_extradata_size[stream] = size;
+avio_read(pb, flv->new_extradata[stream], size);
+} else {
+int new_count = stream + 1;
+
+if (flv->mt_extradata_cnt < new_count) {
+flv->mt_extradata = av_realloc(flv->mt_extradata,
+ sizeof(*flv->mt_extradata) *
+ new_count);
+flv->mt_extradata_sz = av_realloc(flv->mt_ex
[FFmpeg-devel] [PATCH v3 04/16] avformat/flvenc: remove !size check for audio packets
---
libavformat/flvenc.c | 7 ---
1 file changed, 7 deletions(-)
diff --git a/libavformat/flvenc.c b/libavformat/flvenc.c
index 1818b5482a..78235af233 100644
--- a/libavformat/flvenc.c
+++ b/libavformat/flvenc.c
@@ -1070,11 +1070,6 @@ static int flv_write_packet(AVFormatContext *s, AVPacket
*pkt)
|| par->codec_id == AV_CODEC_ID_AC3
|| par->codec_id == AV_CODEC_ID_EAC3;
-if (par->codec_type == AVMEDIA_TYPE_AUDIO && !pkt->size) {
-av_log(s, AV_LOG_WARNING, "Empty audio Packet\n");
-return AVERROR(EINVAL);
-}
-
if (extended_audio)
flags_size = 5;
else if (par->codec_id == AV_CODEC_ID_VP6F || par->codec_id ==
AV_CODEC_ID_VP6A ||
@@ -1149,8 +1144,6 @@ static int flv_write_packet(AVFormatContext *s, AVPacket
*pkt)
case AVMEDIA_TYPE_AUDIO:
flags = get_audio_flags(s, par);
-av_assert0(size);
-
avio_w8(pb, FLV_TAG_TYPE_AUDIO);
break;
case AVMEDIA_TYPE_SUBTITLE:
--
2.45.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v3 05/16] avformat/flvdec: add enhanced audio codecs
---
libavformat/flv.h| 8 +++
libavformat/flvdec.c | 119 +++
2 files changed, 116 insertions(+), 11 deletions(-)
diff --git a/libavformat/flv.h b/libavformat/flv.h
index d030d576f3..8926db6388 100644
--- a/libavformat/flv.h
+++ b/libavformat/flv.h
@@ -132,6 +132,14 @@ enum {
enum {
AudioPacketTypeSequenceStart = 0,
AudioPacketTypeCodedFrames= 1,
+AudioPacketTypeMultichannelConfig = 4,
+AudioPacketTypeMultitrack = 5,
+};
+
+enum {
+AudioChannelOrderUnspecified = 0,
+AudioChannelOrderNative = 1,
+AudioChannelOrderCustom = 2,
};
enum {
diff --git a/libavformat/flvdec.c b/libavformat/flvdec.c
index 35d70838e3..f9859c0980 100644
--- a/libavformat/flvdec.c
+++ b/libavformat/flvdec.c
@@ -224,12 +224,33 @@ static AVStream *create_stream(AVFormatContext *s, int
codec_type, int track_idx
return st;
}
-static int flv_same_audio_codec(AVCodecParameters *apar, int flags)
+static int flv_same_audio_codec(AVCodecParameters *apar, int flags, uint32_t
codec_fourcc)
{
int bits_per_coded_sample = (flags & FLV_AUDIO_SAMPLESIZE_MASK) ? 16 : 8;
int flv_codecid = flags & FLV_AUDIO_CODECID_MASK;
int codec_id;
+switch (codec_fourcc) {
+case MKBETAG('m', 'p', '4', 'a'):
+return apar->codec_id == AV_CODEC_ID_AAC;
+case MKBETAG('O', 'p', 'u', 's'):
+return apar->codec_id == AV_CODEC_ID_OPUS;
+case MKBETAG('.', 'm', 'p', '3'):
+return apar->codec_id == AV_CODEC_ID_MP3;
+case MKBETAG('f', 'L', 'a', 'C'):
+return apar->codec_id == AV_CODEC_ID_FLAC;
+case MKBETAG('a', 'c', '-', '3'):
+return apar->codec_id == AV_CODEC_ID_AC3;
+case MKBETAG('e', 'c', '-', '3'):
+return apar->codec_id == AV_CODEC_ID_EAC3;
+case 0:
+// Not enhanced flv, continue as normal.
+break;
+default:
+// Unknown FOURCC
+return 0;
+}
+
if (!apar->codec_id && !apar->codec_tag)
return 1;
@@ -328,6 +349,24 @@ static void flv_set_audio_codec(AVFormatContext *s,
AVStream *astream,
apar->sample_rate = 8000;
apar->codec_id= AV_CODEC_ID_PCM_ALAW;
break;
+case MKBETAG('m', 'p', '4', 'a'):
+apar->codec_id = AV_CODEC_ID_AAC;
+return;
+case MKBETAG('O', 'p', 'u', 's'):
+apar->codec_id = AV_CODEC_ID_OPUS;
+return;
+case MKBETAG('.', 'm', 'p', '3'):
+apar->codec_id = AV_CODEC_ID_MP3;
+return;
+case MKBETAG('f', 'L', 'a', 'C'):
+apar->codec_id = AV_CODEC_ID_FLAC;
+return;
+case MKBETAG('a', 'c', '-', '3'):
+apar->codec_id = AV_CODEC_ID_AC3;
+return;
+case MKBETAG('e', 'c', '-', '3'):
+apar->codec_id = AV_CODEC_ID_EAC3;
+return;
default:
avpriv_request_sample(s, "Audio codec (%x)",
flv_codecid >> FLV_AUDIO_CODECID_OFFSET);
@@ -1249,7 +1288,7 @@ static int flv_read_packet(AVFormatContext *s, AVPacket
*pkt)
int multitrack = 0;
int pkt_type = 0;
uint8_t track_idx = 0;
-uint32_t video_codec_id = 0;
+uint32_t codec_id = 0;
retry:
/* pkt size is repeated at end. skip it */
@@ -1293,16 +1332,31 @@ retry:
stream_type = FLV_STREAM_TYPE_AUDIO;
flags= avio_r8(s->pb);
size--;
+
+if ((flags & FLV_AUDIO_CODECID_MASK) == FLV_CODECID_EX_HEADER) {
+enhanced_flv = 1;
+pkt_type = flags & ~FLV_AUDIO_CODECID_MASK;
+
+channels = 0;
+
+if (pkt_type == AudioPacketTypeMultitrack) {
+av_log(s, AV_LOG_ERROR, "Multitrack audio is unsupported!\n");
+return AVERROR_PATCHWELCOME;
+}
+
+codec_id = avio_rb32(s->pb);
+size -= 4;
+}
} else if (type == FLV_TAG_TYPE_VIDEO) {
stream_type = FLV_STREAM_TYPE_VIDEO;
flags= avio_r8(s->pb);
-video_codec_id = flags & FLV_VIDEO_CODECID_MASK;
+codec_id = flags & FLV_VIDEO_CODECID_MASK;
/*
* Reference Enhancing FLV 2023-03-v1.0.0-B.8
*
https://github.com/veovera/enhanced-rtmp/blob/main/enhanced-rtmp-v1.pdf
* */
enhanced_flv = (flags >> 7) & 1;
-pkt_type = enhanced_flv ? video_codec_id : 0;
+pkt_type = enhanced_flv ? codec_id : 0;
size--;
if (pkt_type == PacketTypeMultitrack) {
@@ -1320,7 +1374,7 @@ retry:
}
if (enhanced_flv) {
-video_codec_id = avio_rb32(s->pb);
+codec_id = avio_rb32(s->pb);
size -= 4;
}
if (multitrack) {
@@ -1388,11 +1442,11 @@ skip:
st = s->streams[i];
if (stream_type == FLV_STREAM_TYPE_AUDIO) {
if (st->codecpar->codec_type == AVMEDIA_TYPE_AUDIO &&
-(s->audio_codec_id || flv_same_audio_codec(st->codecpar,
flags)))
+(s->audio_codec_id || flv_same_a
[FFmpeg-devel] [PATCH v3 15/16] fate/flvenc: add test for multitrack flv
--- tests/fate/flvenc.mak | 4 + tests/ref/fate/enhanced-flv-multitrack | 526 + 2 files changed, 530 insertions(+) create mode 100644 tests/ref/fate/enhanced-flv-multitrack diff --git a/tests/fate/flvenc.mak b/tests/fate/flvenc.mak index e3703a8cc5..7b656e944f 100644 --- a/tests/fate/flvenc.mak +++ b/tests/fate/flvenc.mak @@ -13,6 +13,10 @@ FATE_ENHANCED_FLVENC_FFMPEG-$(call REMUX, FLV IVF, FLV_DEMUXER AV1_DECODER AV1_P fate-enhanced-flv-av1: CMD = stream_remux ivf $(TARGET_SAMPLES)/av1/seq_hdr_op_param_info.ivf "-c:v av1" \ flv "-c copy" "-c:v av1" "-c copy" +FATE_ENHANCED_FLVENC_FFMPEG-$(call REMUX, FLV, FLV_DEMUXER AAC_PARSER AC3_PARSER OPUS_PARSER FLAC_PARSER VP9_PARSER AV1_PARSER HEVC_PARSER H264_PARSER) += fate-enhanced-flv-multitrack +fate-enhanced-flv-multitrack: CMD = stream_remux flv $(TARGET_SAMPLES)/flv/multitrack.flv "" flv "-map 0" "" "-c copy -map 0" \ + "-show_entries stream_group=index,id,nb_streams,type:stream_group_components:stream_group_stream=index" + FATE_FFMPEG_FFPROBE += $(FATE_FLVENC_FFMPEG_FFPROBE-yes) FATE_SAMPLES_FFMPEG += $(FATE_ENHANCED_FLVENC_FFMPEG-yes) fate-flvenc: $(FATE_FLVENC_FFMPEG_FFPROBE-yes) $(FATE_ENHANCED_FLVENC_FFMPEG-yes) diff --git a/tests/ref/fate/enhanced-flv-multitrack b/tests/ref/fate/enhanced-flv-multitrack new file mode 100644 index 00..d6c838eba9 --- /dev/null +++ b/tests/ref/fate/enhanced-flv-multitrack @@ -0,0 +1,526 @@ +#extradata 0: 46, 0x6fed1203 +#extradata 1: 26, 0x5e13070a +#extradata 2: 12, 0x044800b1 +#extradata 3: 27, 0x5f3604aa +#extradata 4: 17, 0x1d8a047e +#extradata 5: 34, 0x2b7301d1 +#extradata 6: 2483, 0x3e1a58a8 +#extradata 8: 46, 0x6fed1203 +#extradata 9: 26, 0x5e13070a +#tb 0: 1/1000 +#media_type 0: video +#codec_id 0: h264 +#dimensions 0: 1920x1080 +#sar 0: 1/1 +#tb 1: 1/1000 +#media_type 1: audio +#codec_id 1: aac +#sample_rate 1: 48000 +#channel_layout_name 1: 5.1 +#tb 2: 1/1000 +#media_type 2: video +#codec_id 2: vp9 +#dimensions 2: 1920x1080 +#sar 2: 0/1 +#tb 3: 1/1000 +#media_type 3: audio +#codec_id 3: opus +#sample_rate 3: 48000 +#channel_layout_name 3: 5.1 +#tb 4: 1/1000 +#media_type 4: video +#codec_id 4: av1 +#dimensions 4: 1920x1080 +#sar 4: 0/1 +#tb 5: 1/1000 +#media_type 5: audio +#codec_id 5: flac +#sample_rate 5: 48000 +#channel_layout_name 5: 5.1 +#tb 6: 1/1000 +#media_type 6: video +#codec_id 6: hevc +#dimensions 6: 1920x1080 +#sar 6: 1/1 +#tb 7: 1/1000 +#media_type 7: audio +#codec_id 7: ac3 +#sample_rate 7: 48000 +#channel_layout_name 7: 5.1(side) +#tb 8: 1/1000 +#media_type 8: video +#codec_id 8: h264 +#dimensions 8: 1920x1080 +#sar 8: 1/1 +#tb 9: 1/1000 +#media_type 9: audio +#codec_id 9: aac +#sample_rate 9: 48000 +#channel_layout_name 9: 5.1 +0,-62, 21, 41, 1106, 0x1088ff56 +6,-62, 21, 41, 606, 0xfed0238f +8,-62, 21, 41, 1106, 0x1088ff56 +0,-21,188, 41, 71, 0x3aba0538, F=0x0 +6,-21,230, 41, 122, 0x75a01d96, F=0x0 +8,-21,188, 41, 71, 0x3aba0538, F=0x0 +1, 0, 0, 21, 36, 0x9be90826 +9, 0, 0, 21, 36, 0x9be90826 +3, 14, 14,0, 15, 0x59350be2 +7, 16, 16, 32, 1792, 0xee09f476 +0, 21,104, 41, 68, 0xd4bd03eb, F=0x0 +1, 21, 21, 21, 19, 0x1b470383 +2, 21, 21, 42, 210, 0x8f8f5b9d +4, 21, 21, 42, 64, 0xaa18197a +5, 21, 21,0, 32, 0x6c35052d +6, 21,146, 41, 112, 0x7bac13f3, F=0x0 +8, 21,104, 41, 68, 0xd4bd03eb, F=0x0 +9, 21, 21, 21, 19, 0x1b470383 +3, 35, 35,0, 15, 0x59350be2 +1, 42, 42, 21, 19, 0x1b470383 +9, 42, 42, 21, 19, 0x1b470383 +7, 48, 48, 32, 1792, 0xee09f476 +3, 55, 55,0, 15, 0x59350be2 +0, 63, 63, 41, 68, 0xacca0330, F=0x0 +2, 63, 63, 42, 48, 0xbdc5114d, F=0x0 +4, 63, 63, 42, 118, 0x65d0215d, F=0x0 +6, 63, 63, 41, 109, 0x1bf51b57, F=0x0 +8, 63, 63, 41, 68, 0xacca0330, F=0x0 +1, 64, 64, 21, 19, 0x1b470383 +9, 64, 64, 21, 19, 0x1b470383 +3, 75, 75,0, 15, 0x59350be2 +7, 80, 80, 32, 1792, 0xee09f476 +1, 85, 85, 21, 19, 0x1b470383 +9, 85, 85, 21, 19, 0x1b470383 +3, 94, 94,0, 15, 0x59350be2 +0,104,
[FFmpeg-devel] [PATCH v3 13/16] avformat/flvdec: support all multi-track modes
---
libavformat/flvdec.c | 571 +++
1 file changed, 310 insertions(+), 261 deletions(-)
diff --git a/libavformat/flvdec.c b/libavformat/flvdec.c
index c66c37efa2..39e872f473 100644
--- a/libavformat/flvdec.c
+++ b/libavformat/flvdec.c
@@ -1275,6 +1275,7 @@ static int flv_read_packet(AVFormatContext *s, AVPacket
*pkt)
{
FLVContext *flv = s->priv_data;
int ret, i, size, flags;
+int res = 0;
enum FlvTagType type;
int stream_type=-1;
int64_t next, pos, meta_pos;
@@ -1289,6 +1290,7 @@ static int flv_read_packet(AVFormatContext *s, AVPacket
*pkt)
int pkt_type = 0;
uint8_t track_idx = 0;
uint32_t codec_id = 0;
+int multitrack_type = MultitrackTypeOneTrack;
retry:
/* pkt size is repeated at end. skip it */
@@ -1339,14 +1341,9 @@ retry:
if (pkt_type == AudioPacketTypeMultitrack) {
uint8_t types = avio_r8(s->pb);
-int multitrack_type = types >> 4;
+multitrack_type = types & 0xF0;
pkt_type = types & 0xF;
-if (multitrack_type != MultitrackTypeOneTrack) {
-av_log(s, AV_LOG_ERROR, "Audio multitrack types other than
MultitrackTypeOneTrack are unsupported!\n");
-return AVERROR_PATCHWELCOME;
-}
-
multitrack = 1;
size--;
}
@@ -1373,14 +1370,9 @@ retry:
if (pkt_type == PacketTypeMultitrack) {
uint8_t types = avio_r8(s->pb);
-int multitrack_type = types >> 4;
+multitrack_type = types & 0xF0;
pkt_type = types & 0xF;
-if (multitrack_type != MultitrackTypeOneTrack) {
-av_log(s, AV_LOG_ERROR, "Multitrack types other than
MultitrackTypeOneTrack are unsupported!\n");
-return AVERROR_PATCHWELCOME;
-}
-
multitrack = 1;
size--;
}
@@ -1449,293 +1441,350 @@ skip:
goto leave;
}
-/* now find stream */
-for (i = 0; i < s->nb_streams; i++) {
-st = s->streams[i];
-if (stream_type == FLV_STREAM_TYPE_AUDIO) {
-if (st->codecpar->codec_type == AVMEDIA_TYPE_AUDIO &&
-(s->audio_codec_id || flv_same_audio_codec(st->codecpar,
flags, codec_id)) &&
-st->id == track_idx)
-break;
-} else if (stream_type == FLV_STREAM_TYPE_VIDEO) {
-if (st->codecpar->codec_type == AVMEDIA_TYPE_VIDEO &&
-(s->video_codec_id || flv_same_video_codec(st->codecpar,
codec_id)) &&
-st->id == track_idx)
-break;
-} else if (stream_type == FLV_STREAM_TYPE_SUBTITLE) {
-if (st->codecpar->codec_type == AVMEDIA_TYPE_SUBTITLE)
-break;
-} else if (stream_type == FLV_STREAM_TYPE_DATA) {
-if (st->codecpar->codec_type == AVMEDIA_TYPE_DATA)
-break;
+for (;;) {
+int track_size = size;
+
+if (multitrack_type != MultitrackTypeOneTrack) {
+track_size = avio_rb24(s->pb);
+size -= 3;
}
-}
-if (i == s->nb_streams) {
-static const enum AVMediaType stream_types[] = {AVMEDIA_TYPE_VIDEO,
AVMEDIA_TYPE_AUDIO, AVMEDIA_TYPE_SUBTITLE, AVMEDIA_TYPE_DATA};
-st = create_stream(s, stream_types[stream_type], track_idx);
-if (!st)
-return AVERROR(ENOMEM);
-}
-av_log(s, AV_LOG_TRACE, "%d %X %d \n", stream_type, flags, st->discard);
-if (flv->time_pos <= pos) {
-dts += flv->time_offset;
-}
+/* now find stream */
+for (i = 0; i < s->nb_streams; i++) {
+st = s->streams[i];
+if (stream_type == FLV_STREAM_TYPE_AUDIO) {
+if (st->codecpar->codec_type == AVMEDIA_TYPE_AUDIO &&
+(s->audio_codec_id || flv_same_audio_codec(st->codecpar,
flags, codec_id)) &&
+st->id == track_idx)
+break;
+} else if (stream_type == FLV_STREAM_TYPE_VIDEO) {
+if (st->codecpar->codec_type == AVMEDIA_TYPE_VIDEO &&
+(s->video_codec_id || flv_same_video_codec(st->codecpar,
codec_id)) &&
+st->id == track_idx)
+break;
+} else if (stream_type == FLV_STREAM_TYPE_SUBTITLE) {
+if (st->codecpar->codec_type == AVMEDIA_TYPE_SUBTITLE)
+break;
+} else if (stream_type == FLV_STREAM_TYPE_DATA) {
+if (st->codecpar->codec_type == AVMEDIA_TYPE_DATA)
+break;
+}
+}
+if (i == s->nb_streams) {
+static const enum AVMediaType stream_types[] =
{AVMEDIA_TYPE_VIDEO, AVMEDIA_TYPE_AUDIO, AVMEDIA_TYPE_SUBTITLE,
AVMEDIA_TYPE_DATA};
+st = create_stream(s, stream_types[stream_type], track_idx);
+if (!st)
+
[FFmpeg-devel] [PATCH v3 06/16] avformat/flvenc: refactor fourcc writing
---
libavformat/flvenc.c | 96 ++--
1 file changed, 47 insertions(+), 49 deletions(-)
diff --git a/libavformat/flvenc.c b/libavformat/flvenc.c
index 78235af233..5973e6be8d 100644
--- a/libavformat/flvenc.c
+++ b/libavformat/flvenc.c
@@ -493,6 +493,45 @@ static void write_metadata(AVFormatContext *s, unsigned
int ts)
avio_wb32(pb, flv->metadata_totalsize + 11);
}
+static void write_codec_fourcc(AVIOContext *pb, enum AVCodecID codec_id)
+{
+switch (codec_id) {
+case AV_CODEC_ID_AAC:
+avio_write(pb, "mp4a", 4);
+return;
+case AV_CODEC_ID_OPUS:
+avio_write(pb, "Opus", 4);
+return;
+case AV_CODEC_ID_FLAC:
+avio_write(pb, "fLaC", 4);
+return;
+case AV_CODEC_ID_MP3:
+avio_write(pb, ".mp3", 4);
+return;
+case AV_CODEC_ID_AC3:
+avio_write(pb, "ac-3", 4);
+return;
+case AV_CODEC_ID_EAC3:
+avio_write(pb, "ec-3", 4);
+return;
+case AV_CODEC_ID_H264:
+avio_write(pb, "avc1", 4);
+return;
+case AV_CODEC_ID_HEVC:
+avio_write(pb, "hvc1", 4);
+return;
+case AV_CODEC_ID_AV1:
+avio_write(pb, "av01", 4);
+return;
+case AV_CODEC_ID_VP9:
+avio_write(pb, "vp09", 4);
+return;
+default:
+av_log(NULL, AV_LOG_ERROR, "Invalid codec FourCC write requested.\n");
+av_assert0(0);
+}
+}
+
static void flv_write_metadata_packet(AVFormatContext *s, AVCodecParameters
*par, unsigned int ts, int stream_idx)
{
AVIOContext *pb = s->pb;
@@ -529,13 +568,8 @@ static void flv_write_metadata_packet(AVFormatContext *s,
AVCodecParameters *par
put_timestamp(pb, ts); //ts = pkt->dts, gen
avio_wb24(pb, flv->reserved);
-if (par->codec_id == AV_CODEC_ID_HEVC) {
-avio_w8(pb, FLV_IS_EX_HEADER | PacketTypeMetadata|
FLV_FRAME_VIDEO_INFO_CMD); // ExVideoTagHeader mode with PacketTypeMetadata
-avio_write(pb, "hvc1", 4);
-} else if (par->codec_id == AV_CODEC_ID_AV1 || par->codec_id ==
AV_CODEC_ID_VP9) {
-avio_w8(pb, FLV_IS_EX_HEADER | PacketTypeMetadata|
FLV_FRAME_VIDEO_INFO_CMD);
-avio_write(pb, par->codec_id == AV_CODEC_ID_AV1 ? "av01" : "vp09",
4);
-}
+avio_w8(pb, FLV_IS_EX_HEADER | PacketTypeMetadata |
FLV_FRAME_VIDEO_INFO_CMD); // ExVideoTagHeader mode with PacketTypeMetadata
+write_codec_fourcc(pb, par->codec_id);
avio_w8(pb, AMF_DATA_TYPE_STRING);
put_amf_string(pb, "colorInfo");
@@ -704,24 +738,14 @@ static void flv_write_codec_header(AVFormatContext* s,
AVCodecParameters* par, i
if (extended_flv) {
avio_w8(pb, FLV_CODECID_EX_HEADER |
AudioPacketTypeSequenceStart);
+write_codec_fourcc(pb, par->codec_id);
if (par->codec_id == AV_CODEC_ID_AAC) {
-avio_write(pb, "mp4a", 4);
flv_write_aac_header(s, par);
-} else if (par->codec_id == AV_CODEC_ID_OPUS) {
-avio_write(pb, "Opus", 4);
+} else if (par->codec_id == AV_CODEC_ID_OPUS || par->codec_id
== AV_CODEC_ID_FLAC) {
av_assert0(par->extradata_size);
avio_write(pb, par->extradata, par->extradata_size);
-} else if (par->codec_id == AV_CODEC_ID_FLAC) {
-avio_write(pb, "fLaC", 4);
-av_assert0(par->extradata_size);
-avio_write(pb, par->extradata, par->extradata_size);
-} else if (par->codec_id == AV_CODEC_ID_MP3)
-avio_write(pb, ".mp3", 4);
-else if (par->codec_id == AV_CODEC_ID_AC3)
-avio_write(pb, "ac-3", 4);
-else if (par->codec_id == AV_CODEC_ID_EAC3)
-avio_write(pb, "ec-3", 4);
+}
} else if (par->codec_id == AV_CODEC_ID_AAC) {
avio_w8(pb, get_audio_flags(s, par));
avio_w8(pb, 0); // AAC sequence header
@@ -744,14 +768,7 @@ static void flv_write_codec_header(AVFormatContext* s,
AVCodecParameters* par, i
avio_w8(pb, FLV_IS_EX_HEADER | PacketTypeSequenceStart |
FLV_FRAME_KEY);
}
-if (par->codec_id == AV_CODEC_ID_H264)
-avio_write(pb, "avc1", 4);
-else if (par->codec_id == AV_CODEC_ID_HEVC)
-avio_write(pb, "hvc1", 4);
-else if (par->codec_id == AV_CODEC_ID_AV1)
-avio_write(pb, "av01", 4);
-else if (par->codec_id == AV_CODEC_ID_VP9)
-avio_write(pb, "vp09", 4);
+write_codec_fourcc(pb, par->codec_id);
if (track_idx)
avio_w8(pb, track_idx);
@@ -1243,14 +1260,7 @@ static int flv_write_packet(AVFormatContext *s, AVPacket
*pkt)
[FFmpeg-devel] [PATCH v3 14/16] avformat/rtmpproto: reserve enough space for statusmsg
---
libavformat/rtmpproto.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavformat/rtmpproto.c b/libavformat/rtmpproto.c
index bb974390d3..a34020b092 100644
--- a/libavformat/rtmpproto.c
+++ b/libavformat/rtmpproto.c
@@ -2004,7 +2004,7 @@ static int send_invoke_response(URLContext *s, RTMPPacket
*pkt)
pp = spkt.data;
ff_amf_write_string(&pp, "onFCPublish");
} else if (!strcmp(command, "publish")) {
-char statusmsg[128];
+char statusmsg[sizeof(filename) + 32];
snprintf(statusmsg, sizeof(statusmsg), "%s is now published",
filename);
ret = write_begin(s);
if (ret < 0)
--
2.45.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v3 16/16] avformat/flvenc: prevent writing legacy codecs into extended video tracks
---
libavformat/flvenc.c | 15 ++-
1 file changed, 14 insertions(+), 1 deletion(-)
diff --git a/libavformat/flvenc.c b/libavformat/flvenc.c
index 09a930fb1a..f3f32dc433 100644
--- a/libavformat/flvenc.c
+++ b/libavformat/flvenc.c
@@ -970,6 +970,15 @@ static int flv_init(struct AVFormatContext *s)
switch (par->codec_type) {
case AVMEDIA_TYPE_VIDEO:
+if (video_ctr &&
+par->codec_id != AV_CODEC_ID_VP8 &&
+par->codec_id != AV_CODEC_ID_VP9 &&
+par->codec_id != AV_CODEC_ID_AV1 &&
+par->codec_id != AV_CODEC_ID_H264 &&
+par->codec_id != AV_CODEC_ID_HEVC) {
+av_log(s, AV_LOG_ERROR, "Unsupported multi-track video
codec.\n");
+return AVERROR(EINVAL);
+}
if (s->streams[i]->avg_frame_rate.den &&
s->streams[i]->avg_frame_rate.num) {
flv->framerate = av_q2d(s->streams[i]->avg_frame_rate);
@@ -1012,7 +1021,7 @@ static int flv_init(struct AVFormatContext *s)
par->codec_id != AV_CODEC_ID_FLAC &&
par->codec_id != AV_CODEC_ID_AC3 &&
par->codec_id != AV_CODEC_ID_EAC3) {
-av_log(s, AV_LOG_ERROR, "Unsupported multi-track codec.\n");
+av_log(s, AV_LOG_ERROR, "Unsupported multi-track audio
codec.\n");
return AVERROR(EINVAL);
}
flv->track_idx_map[i] = audio_ctr++;
@@ -1390,6 +1399,10 @@ static int flv_write_packet(AVFormatContext *s, AVPacket
*pkt)
write_codec_fourcc(pb, par->codec_id);
if (track_idx)
avio_w8(pb, track_idx);
+} else if (track_idx) {
+av_log(s, AV_LOG_ERROR, "Attempted to write legacy codec into
extended flv track.\n");
+ret = AVERROR(EINVAL);
+goto fail;
} else {
av_assert1(flags >= 0);
avio_w8(pb, flags);
--
2.45.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v3 09/16] avformat/flvenc: add support for writing multi track audio
---
libavformat/flvenc.c | 92
1 file changed, 68 insertions(+), 24 deletions(-)
diff --git a/libavformat/flvenc.c b/libavformat/flvenc.c
index 5623b119fd..09a930fb1a 100644
--- a/libavformat/flvenc.c
+++ b/libavformat/flvenc.c
@@ -132,7 +132,7 @@ typedef struct FLVContext {
int flags;
int64_t *last_ts;
int *metadata_pkt_written;
-int *video_track_idx_map;
+int *track_idx_map;
} FLVContext;
static int get_audio_flags(AVFormatContext *s, AVCodecParameters *par)
@@ -765,19 +765,33 @@ static int
flv_get_multichannel_body_size(AVCodecParameters* par)
return res;
}
-static void flv_write_multichannel_header(AVFormatContext* s,
AVCodecParameters* par, int64_t ts)
+static void flv_write_multichannel_header(AVFormatContext* s,
AVCodecParameters* par, int64_t ts, int stream_index)
{
AVIOContext *pb = s->pb;
+FLVContext *flv = s->priv_data;
+
+int track_idx = flv->track_idx_map[stream_index];
int data_size = flv_get_multichannel_body_size(par);
+if (track_idx)
+data_size += 2;
avio_w8(pb, FLV_TAG_TYPE_AUDIO);
avio_wb24(pb, data_size + 5); // size
put_timestamp(pb, ts);
avio_wb24(pb, 0); // streamid
-avio_w8(pb, FLV_CODECID_EX_HEADER | AudioPacketTypeMultichannelConfig);
+if (track_idx) {
+avio_w8(pb, FLV_CODECID_EX_HEADER | AudioPacketTypeMultitrack);
+avio_w8(pb, MultitrackTypeOneTrack |
AudioPacketTypeMultichannelConfig);
+} else {
+avio_w8(pb, FLV_CODECID_EX_HEADER | AudioPacketTypeMultichannelConfig);
+}
+
write_codec_fourcc(pb, par->codec_id);
+if (track_idx)
+avio_w8(pb, track_idx);
+
flv_write_multichannel_body(s, par);
avio_wb32(pb, data_size + 5 + 11); // previous tag size
@@ -787,6 +801,7 @@ static void flv_write_codec_header(AVFormatContext* s,
AVCodecParameters* par, i
int64_t data_size;
AVIOContext *pb = s->pb;
FLVContext *flv = s->priv_data;
+int track_idx = flv->track_idx_map[stream_index];
int extended_flv = 0;
if (par->codec_id == AV_CODEC_ID_AAC || par->codec_id == AV_CODEC_ID_H264
@@ -803,15 +818,26 @@ static void flv_write_codec_header(AVFormatContext* s,
AVCodecParameters* par, i
avio_wb24(pb, 0); // streamid
pos = avio_tell(pb);
if (par->codec_type == AVMEDIA_TYPE_AUDIO) {
-extended_flv = par->codec_id == AV_CODEC_ID_OPUS
-|| par->codec_id == AV_CODEC_ID_FLAC
-|| par->codec_id == AV_CODEC_ID_AC3
-|| par->codec_id == AV_CODEC_ID_EAC3;
+extended_flv = (par->codec_id == AV_CODEC_ID_AAC && track_idx)
+|| (par->codec_id == AV_CODEC_ID_MP3 &&
track_idx)
+|| par->codec_id == AV_CODEC_ID_OPUS
+|| par->codec_id == AV_CODEC_ID_FLAC
+|| par->codec_id == AV_CODEC_ID_AC3
+|| par->codec_id == AV_CODEC_ID_EAC3;
if (extended_flv) {
-avio_w8(pb, FLV_CODECID_EX_HEADER |
AudioPacketTypeSequenceStart);
+if (track_idx) {
+avio_w8(pb, FLV_CODECID_EX_HEADER |
AudioPacketTypeMultitrack);
+avio_w8(pb, MultitrackTypeOneTrack |
AudioPacketTypeSequenceStart);
+} else {
+avio_w8(pb, FLV_CODECID_EX_HEADER |
AudioPacketTypeSequenceStart);
+}
+
write_codec_fourcc(pb, par->codec_id);
+if (track_idx)
+avio_w8(pb, track_idx);
+
if (par->codec_id == AV_CODEC_ID_AAC) {
flv_write_aac_header(s, par);
} else if (par->codec_id == AV_CODEC_ID_OPUS || par->codec_id
== AV_CODEC_ID_FLAC) {
@@ -825,7 +851,6 @@ static void flv_write_codec_header(AVFormatContext* s,
AVCodecParameters* par, i
flv_write_aac_header(s, par);
}
} else {
-int track_idx = flv->video_track_idx_map[stream_index];
// If video stream has track_idx > 0 we need to send H.264 as
extended video packet
extended_flv = (par->codec_id == AV_CODEC_ID_H264 && track_idx) ||
par->codec_id == AV_CODEC_ID_HEVC ||
@@ -869,7 +894,7 @@ static void flv_write_codec_header(AVFormatContext* s,
AVCodecParameters* par, i
if (par->codec_type == AVMEDIA_TYPE_AUDIO && (extended_flv ||
(av_channel_layout_compare(&par->ch_layout,
&(AVChannelLayout)AV_CHANNEL_LAYOUT_STEREO) == 1 &&
av_channel_layout_compare(&par->ch_layout,
&(AVChannelLayout)AV_CHANNEL_LAYOUT_MONO) == 1)))
-flv_write_multichannel_header(s, par, ts);
+flv_write_multichannel_header(s, par, ts, stream_index);
}
static int flv_append_keyframe_info(AVFormatContext *s, FLVC
[FFmpeg-devel] [PATCH v3 10/16] avformat/flvdec: add support for reading multi track audio
---
libavformat/flvdec.c | 21 ++---
1 file changed, 18 insertions(+), 3 deletions(-)
diff --git a/libavformat/flvdec.c b/libavformat/flvdec.c
index fbc8bc9d32..15312cfa02 100644
--- a/libavformat/flvdec.c
+++ b/libavformat/flvdec.c
@@ -1338,12 +1338,26 @@ retry:
pkt_type = flags & ~FLV_AUDIO_CODECID_MASK;
if (pkt_type == AudioPacketTypeMultitrack) {
-av_log(s, AV_LOG_ERROR, "Multitrack audio is unsupported!\n");
-return AVERROR_PATCHWELCOME;
+uint8_t types = avio_r8(s->pb);
+int multitrack_type = types >> 4;
+pkt_type = types & 0xF;
+
+if (multitrack_type != MultitrackTypeOneTrack) {
+av_log(s, AV_LOG_ERROR, "Audio multitrack types other than
MultitrackTypeOneTrack are unsupported!\n");
+return AVERROR_PATCHWELCOME;
+}
+
+multitrack = 1;
+size--;
}
codec_id = avio_rb32(s->pb);
size -= 4;
+
+if (multitrack) {
+track_idx = avio_r8(s->pb);
+size--;
+}
}
} else if (type == FLV_TAG_TYPE_VIDEO) {
stream_type = FLV_STREAM_TYPE_VIDEO;
@@ -1440,7 +1454,8 @@ skip:
st = s->streams[i];
if (stream_type == FLV_STREAM_TYPE_AUDIO) {
if (st->codecpar->codec_type == AVMEDIA_TYPE_AUDIO &&
-(s->audio_codec_id || flv_same_audio_codec(st->codecpar,
flags, codec_id)))
+(s->audio_codec_id || flv_same_audio_codec(st->codecpar,
flags, codec_id)) &&
+st->id == track_idx)
break;
} else if (stream_type == FLV_STREAM_TYPE_VIDEO) {
if (st->codecpar->codec_type == AVMEDIA_TYPE_VIDEO &&
--
2.45.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v3 07/16] avformat/flvenc: write enhanced rtmp multichannel info for audio with more than two channels
---
libavformat/flvenc.c | 93
1 file changed, 85 insertions(+), 8 deletions(-)
diff --git a/libavformat/flvenc.c b/libavformat/flvenc.c
index 5973e6be8d..5623b119fd 100644
--- a/libavformat/flvenc.c
+++ b/libavformat/flvenc.c
@@ -712,10 +712,82 @@ static void flv_write_aac_header(AVFormatContext* s,
AVCodecParameters* par)
avio_write(pb, par->extradata, par->extradata_size);
}
+static void flv_write_multichannel_body(AVFormatContext* s, AVCodecParameters*
par)
+{
+AVIOContext *pb = s->pb;
+
+switch (par->ch_layout.order) {
+case AV_CHANNEL_ORDER_NATIVE:
+avio_w8(pb, AudioChannelOrderNative);
+break;
+case AV_CHANNEL_ORDER_CUSTOM:
+avio_w8(pb, AudioChannelOrderCustom);
+break;
+default:
+avio_w8(pb, AudioChannelOrderUnspecified);
+break;
+}
+
+avio_w8(pb, par->ch_layout.nb_channels);
+
+if (par->ch_layout.order == AV_CHANNEL_ORDER_NATIVE) {
+// The first 18 entries are identical between FFmpeg and flv
+uint32_t mask = par->ch_layout.u.mask & 0x03;
+// The remaining 6 flv entries are in the right order, but start at
AV_CHAN_LOW_FREQUENCY_2
+mask |= (par->ch_layout.u.mask >> (AV_CHAN_LOW_FREQUENCY_2 - 18)) &
0xFC;
+
+avio_wb32(pb, mask);
+} else if (par->ch_layout.order == AV_CHANNEL_ORDER_CUSTOM) {
+for (int i = 0; i < par->ch_layout.nb_channels; i++) {
+enum AVChannel id = par->ch_layout.u.map[i].id;
+if (id >= AV_CHAN_FRONT_LEFT && id <= AV_CHAN_TOP_BACK_RIGHT) {
+avio_w8(pb, id - AV_CHAN_FRONT_LEFT + 0);
+} else if (id >= AV_CHAN_LOW_FREQUENCY_2 && id <=
AV_CHAN_BOTTOM_FRONT_RIGHT) {
+avio_w8(pb, id - AV_CHAN_LOW_FREQUENCY_2 + 18);
+} else if (id == AV_CHAN_UNUSED) {
+avio_w8(pb, 0xFE);
+} else {
+avio_w8(pb, 0xFF); // unknown
+}
+}
+}
+}
+
+static int flv_get_multichannel_body_size(AVCodecParameters* par)
+{
+int res = 2;
+
+if (par->ch_layout.order == AV_CHANNEL_ORDER_NATIVE)
+res += 4;
+else if (par->ch_layout.order == AV_CHANNEL_ORDER_CUSTOM)
+res += par->ch_layout.nb_channels;
+
+return res;
+}
+
+static void flv_write_multichannel_header(AVFormatContext* s,
AVCodecParameters* par, int64_t ts)
+{
+AVIOContext *pb = s->pb;
+int data_size = flv_get_multichannel_body_size(par);
+
+avio_w8(pb, FLV_TAG_TYPE_AUDIO);
+avio_wb24(pb, data_size + 5); // size
+put_timestamp(pb, ts);
+avio_wb24(pb, 0); // streamid
+
+avio_w8(pb, FLV_CODECID_EX_HEADER | AudioPacketTypeMultichannelConfig);
+write_codec_fourcc(pb, par->codec_id);
+
+flv_write_multichannel_body(s, par);
+
+avio_wb32(pb, data_size + 5 + 11); // previous tag size
+}
+
static void flv_write_codec_header(AVFormatContext* s, AVCodecParameters* par,
int64_t ts, int stream_index) {
int64_t data_size;
AVIOContext *pb = s->pb;
FLVContext *flv = s->priv_data;
+int extended_flv = 0;
if (par->codec_id == AV_CODEC_ID_AAC || par->codec_id == AV_CODEC_ID_H264
|| par->codec_id == AV_CODEC_ID_MPEG4 || par->codec_id ==
AV_CODEC_ID_HEVC
@@ -731,10 +803,10 @@ static void flv_write_codec_header(AVFormatContext* s,
AVCodecParameters* par, i
avio_wb24(pb, 0); // streamid
pos = avio_tell(pb);
if (par->codec_type == AVMEDIA_TYPE_AUDIO) {
-int extended_flv = par->codec_id == AV_CODEC_ID_OPUS
-|| par->codec_id == AV_CODEC_ID_FLAC
-|| par->codec_id == AV_CODEC_ID_AC3
-|| par->codec_id == AV_CODEC_ID_EAC3;
+extended_flv = par->codec_id == AV_CODEC_ID_OPUS
+|| par->codec_id == AV_CODEC_ID_FLAC
+|| par->codec_id == AV_CODEC_ID_AC3
+|| par->codec_id == AV_CODEC_ID_EAC3;
if (extended_flv) {
avio_w8(pb, FLV_CODECID_EX_HEADER |
AudioPacketTypeSequenceStart);
@@ -755,10 +827,10 @@ static void flv_write_codec_header(AVFormatContext* s,
AVCodecParameters* par, i
} else {
int track_idx = flv->video_track_idx_map[stream_index];
// If video stream has track_idx > 0 we need to send H.264 as
extended video packet
-int extended_flv = (par->codec_id == AV_CODEC_ID_H264 &&
track_idx) ||
-par->codec_id == AV_CODEC_ID_HEVC ||
-par->codec_id == AV_CODEC_ID_AV1 ||
-par->codec_id == AV_CODEC_ID_VP9;
+extended_flv = (par->codec_id == AV_CODEC_ID_H264 && track_idx) ||
+par->codec_id == AV_CODEC_ID_HEVC ||
+par->codec_id == AV_CODEC_ID_AV1 ||
+
[FFmpeg-devel] [PATCH v3 08/16] avformat/flvdec: parse enhanced rtmp multichannel info
---
libavformat/flvdec.c | 41 +
1 file changed, 25 insertions(+), 16 deletions(-)
diff --git a/libavformat/flvdec.c b/libavformat/flvdec.c
index f9859c0980..fbc8bc9d32 100644
--- a/libavformat/flvdec.c
+++ b/libavformat/flvdec.c
@@ -1337,8 +1337,6 @@ retry:
enhanced_flv = 1;
pkt_type = flags & ~FLV_AUDIO_CODECID_MASK;
-channels = 0;
-
if (pkt_type == AudioPacketTypeMultitrack) {
av_log(s, AV_LOG_ERROR, "Multitrack audio is unsupported!\n");
return AVERROR_PATCHWELCOME;
@@ -1548,12 +1546,9 @@ retry_duration:
avcodec_parameters_free(&par);
}
} else if (stream_type == FLV_STREAM_TYPE_AUDIO) {
-if (!st->codecpar->codec_id) {
+if (!st->codecpar->codec_id)
flv_set_audio_codec(s, st, st->codecpar,
codec_id ? codec_id : (flags &
FLV_AUDIO_CODECID_MASK));
-flv->last_sample_rate = 0;
-flv->last_channels = 0;
-}
// These are not signalled in the flags anymore
channels = 0;
@@ -1564,26 +1559,40 @@ retry_duration:
channels = avio_r8(s->pb);
size -= 2;
+av_channel_layout_uninit(&st->codecpar->ch_layout);
+
if (channel_order == AudioChannelOrderCustom) {
+ret = av_channel_layout_custom_init(&st->codecpar->ch_layout,
channels);
+if (ret < 0)
+return ret;
+
for (i = 0; i < channels; i++) {
-avio_r8(s->pb); // audio channel mapping
+uint8_t id = avio_r8(s->pb);
size--;
+
+if (id < 18)
+st->codecpar->ch_layout.u.map[i].id = id;
+else if (id >= 18 && id <= 23)
+st->codecpar->ch_layout.u.map[i].id = id - 18 +
AV_CHAN_LOW_FREQUENCY_2;
+else if (id == 0xFE)
+st->codecpar->ch_layout.u.map[i].id = AV_CHAN_UNUSED;
+else
+st->codecpar->ch_layout.u.map[i].id = AV_CHAN_UNKNOWN;
}
} else if (channel_order == AudioChannelOrderNative) {
-avio_rb32(s->pb); // audio channel flags
+uint64_t mask = avio_rb32(s->pb);
size -= 4;
-}
-if (!av_channel_layout_check(&st->codecpar->ch_layout)) {
-///TODO: This can be much more sophisticated with above info.
+// The first 18 entries in the mask match ours, but the
remaining 6 entries start at AV_CHAN_LOW_FREQUENCY_2
+mask = (mask & 0x3) | ((mask & 0xFC) <<
(AV_CHAN_LOW_FREQUENCY_2 - 18));
+ret = av_channel_layout_from_mask(&st->codecpar->ch_layout,
mask);
+if (ret < 0)
+return ret;
+} else {
av_channel_layout_default(&st->codecpar->ch_layout, channels);
-flv->last_channels = channels;
}
-if (channels != flv->last_channels) {
-flv->last_channels = channels;
-ff_add_param_change(pkt, channels, 0, 0, 0, 0);
-}
+av_log(s, AV_LOG_DEBUG, "Set channel data from MultiChannel
info.\n");
goto leave;
}
--
2.45.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v2] avcodec/h264: fix stride calculation in slice_table for multi-slice field video deblocking
fix for https://trac.ffmpeg.org/ticket/11360
Signed-off-by: Lingyi Kong
---
libavcodec/h264_mb.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/h264_mb.c b/libavcodec/h264_mb.c
index 4e94136313..6083f7ad84 100644
--- a/libavcodec/h264_mb.c
+++ b/libavcodec/h264_mb.c
@@ -529,7 +529,7 @@ static av_always_inline void xchg_mb_border(const
H264Context *h, H264SliceConte
}
if (sl->deblocking_filter == 2) {
-deblock_topleft = h->slice_table[sl->mb_xy - 1 - h->mb_stride]
== sl->slice_num;
+deblock_topleft = h->slice_table[sl->mb_xy - 1 - (h->mb_stride
<< MB_FIELD(sl))] == sl->slice_num;
deblock_top = sl->top_type;
} else {
deblock_topleft = (sl->mb_x > 0);
--
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] [PATCH v3] avcodec/h264_mb: Fix tmp buffer overlap in mc_part_weighted
When decoding a bitstream with weighted-bipred enabled, the results on ARM and x86 platforms may differ. The reason for the inconsistency is that the value of STRIDE_ALIGN differs between platforms. And STRIDE_ALIGN is set to the buffer stride of temporary buffers for U and V components in mc_part_weighted. If the buffer stride is 32 or 64 (as on x86 platforms), the U and V pixels can be interleaved row by row without overlapping, resulting in correct output. However, on ARM platforms where the stride is 16, the V component will overwrite part of the U component's pixels, leading to incorrect predicted pixels. Fixes: ticket 11357 Signed-off-by: Bin Peng --- libavcodec/h264_mb.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/libavcodec/h264_mb.c b/libavcodec/h264_mb.c index 4e94136313..b480cd312b 100644 --- a/libavcodec/h264_mb.c +++ b/libavcodec/h264_mb.c @@ -407,8 +407,8 @@ static av_always_inline void mc_part_weighted(const H264Context *h, H264SliceCon /* don't optimize for luma-only case, since B-frames usually * use implicit weights => chroma too. */ uint8_t *tmp_cb = sl->bipred_scratchpad; -uint8_t *tmp_cr = sl->bipred_scratchpad + (16 << pixel_shift); -uint8_t *tmp_y = sl->bipred_scratchpad + 16 * sl->mb_uvlinesize; +uint8_t *tmp_cr = sl->bipred_scratchpad + (16 * sl->mb_uvlinesize); +uint8_t *tmp_y = sl->bipred_scratchpad + (32 * sl->mb_uvlinesize); int refn0 = sl->ref_cache[0][scan8[n]]; int refn1 = sl->ref_cache[1][scan8[n]]; -- 2.25.1 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] Coverity access
On 12/19/2024 5:04 PM, Michael Niedermayer wrote: Hi Kieran (also thx to compn for reminding me about this mail) On Fri, Dec 13, 2024 at 01:30:43AM +, Kieran Kunhya via ffmpeg-devel wrote: Hello, This person asked for coverity access: https://x.com/acentauri92/status/1867186643704099105 I don't know if they should have access. In the past i have given access to everyone i recognized as a FFmpeg developer/contributor and have not replied to everyone else. Based on the idea that someone else might recognize a requester Is this someone you know ? The name doesnt ring a bell git log --author centauri shows nothing Then no. 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] Fwd: Your message to ffmpeg-devel awaits moderator approval
On Thu, Dec 19, 2024 at 7:52 PM Michael Niedermayer wrote: > > Hi compn > > On Thu, Dec 19, 2024 at 06:16:03AM -1000, compn wrote: > > On Thu, 19 Dec 2024 08:58:14 +, Kieran Kunhya via ffmpeg-devel > > wrote: > > > > > Hello, > > > > > > My messages are being blocked on the mailing list. > > > > your message, and the message of others in that specific thread was > > not blocked. it was held for moderator approval as you quoted below. > > > > > The reason it is being held: > > > > > > Header matched regexp: ^Subject:.*upcoming.*vote > > > > > > Either the message will get posted to the list, or you will receive > > > notification of the moderator's decision. If you would like to cancel > > > this posting, please visit the following URL: > > > > > How is this fair that one person can unilaterally decide this? > > > > > as ml admin if i see flames i try to tamper them down a bit. > > This was a brave decission and IMO it was the correct decission. > You saw people fighting, and you stepped between them to stop it. A CC candidate is blocking discussion in a thread about the CC election. That's "brave" in your mind? Compn campaigning for and then following through pre-election with authoritarian behaviour is truly incredible. And it being called "brave" from the person who repeatedly reminds us how important his (but not anyone else's) free speech is. Some Animals are More Equal Than Others. 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] Coverity access
On Thu, 19 Dec 2024 21:04:50 +0100, Michael Niedermayer wrote: > Hi Kieran > > (also thx to compn for reminding me about this mail) > > On Fri, Dec 13, 2024 at 01:30:43AM +, Kieran Kunhya via ffmpeg-devel > wrote: > > Hello, > > > > This person asked for coverity access: > > https://x.com/acentauri92/status/1867186643704099105 > > > > I don't know if they should have access. > > In the past i have given access to everyone i recognized as a FFmpeg > developer/contributor and have not replied to everyone else. Based > on the idea that someone else might recognize a requester > > Is this someone you know ? The name doesnt ring a bell > git log --author centauri > shows nothing if our goal is to attract new developers it would be better to invite person (using ffmpeg x account) to join us on irc or the mailing list to talk. otherwise just rejecting new developers seems like a not great idea or solution. well just my 2c -compn ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] swscale/unscaled: add pal8 -> gbr(a)p special converter
Hi On Wed, Dec 18, 2024 at 03:24:59PM +0100, Niklas Haas wrote: > From: Niklas Haas > > Fixes: ticket #9520 > Signed-off-by: Niklas Haas > Sponsored-by: Sovereign Tech Fund > --- > libswscale/swscale.c | 2 + > libswscale/swscale_unscaled.c | 81 ++- > 2 files changed, 81 insertions(+), 2 deletions(-) > > diff --git a/libswscale/swscale.c b/libswscale/swscale.c > index 96634acfd6..bd5b6370db 100644 > --- a/libswscale/swscale.c > +++ b/libswscale/swscale.c > @@ -910,6 +910,8 @@ void ff_update_palette(SwsInternal *c, const uint32_t > *pal) > case AV_PIX_FMT_BGR32_1: > #if HAVE_BIGENDIAN > case AV_PIX_FMT_BGR24: > +case AV_PIX_FMT_BGRP: > +case AV_PIX_FMT_BGRAP: > #endif breaks MIPS src/libswscale/swscale.c: In function ‘ff_update_palette’: src/libswscale/swscale.c:913:14: error: ‘AV_PIX_FMT_BGRP’ undeclared (first use in this function); did you mean ‘AV_PIX_FMT_BGR0’? case AV_PIX_FMT_BGRP: ^~~ AV_PIX_FMT_BGR0 src/libswscale/swscale.c:913:14: note: each undeclared identifier is reported only once for each function it appears in src/libswscale/swscale.c:914:14: error: ‘AV_PIX_FMT_BGRAP’ undeclared (first use in this function); did you mean ‘AV_PIX_FMT_BGRP’? case AV_PIX_FMT_BGRAP: ^~~~ AV_PIX_FMT_BGRP thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Frequently ignored answer#1 FFmpeg bugs should be sent to our bugtracker. User questions about the command line tools should be sent to the ffmpeg-user ML. And questions about how to use libav* should be sent to the libav-user ML. signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] Fwd: Your message to ffmpeg-devel awaits moderator approval
On Fri, 20 Dec 2024 06:24:46 +0100, Anton Khirnov wrote: > Quoting Michael Niedermayer (2024-12-19 20:52:39) > > This was a brave decission and IMO it was the correct decission. > > You saw people fighting, and you stepped between them to stop it. > > So what we have here is a server admin approving and encouraging his > buddy to perform arbitrary censorship with no oversight. Said buddy was > granted moderator privileges for no reason anyone can articulate, sees > no difference between acting as a moderator and acting as a private > person, recently resurfaced after 6+ years of complete absence, and yet > apparently feels entirely at liberty to censor whatever he wants. > > I really hope that makes it clear to everyone why there needs to be a > proper process for access to infrastructure, and "just leave everything > to Michael" leads exactly to the situation we have now, and all the > similar situations we've had in the past. > > No, Michael, it's not "unfriendly people". It's you. It's always been > you. Other projects do not have these problems at such a regular basis. > > >-- >Anton Khirnov the CC allows personal attacks to continue like this? -compn ___ ffmpeg-devel mailing list ffmpeg-devel@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 stride calculation in slice_table for multi-slice field video deblocking
fix for https://trac.ffmpeg.org/ticket/11360
Signed-off-by: Lingyi Kong
---
libavcodec/h264_mb.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/h264_mb.c b/libavcodec/h264_mb.c
index 4e94136313..6083f7ad84 100644
--- a/libavcodec/h264_mb.c
+++ b/libavcodec/h264_mb.c
@@ -529,7 +529,7 @@ static av_always_inline void xchg_mb_border(const
H264Context *h, H264SliceConte
}
if (sl->deblocking_filter == 2) {
-deblock_topleft = h->slice_table[sl->mb_xy - 1 - h->mb_stride]
== sl->slice_num;
+deblock_topleft = h->slice_table[sl->mb_xy - 1 - (h->mb_stride
<< MB_FIELD(sl))] == sl->slice_num;
deblock_top = sl->top_type;
} else {
deblock_topleft = (sl->mb_x > 0);
--
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] Fwd: Your message to ffmpeg-devel awaits moderator approval
On Fri, 20 Dec 2024 01:35:01 +, Kieran Kunhya via ffmpeg-devel wrote: > On Thu, Dec 19, 2024 at 9:11 PM compn wrote: > > > > On Thu, 19 Dec 2024 20:40:55 +, Kieran Kunhya via ffmpeg-devel > > wrote: > > > > > Please can you confirm you will be resigning your moderator status in > > > light > > > of the election censorship you have undertaken while at the same time > > > being > > > a candidate for CC? > > > > i have no intention to resign from being ml admin. > > > > i took the initiative to moderate the thread from flames, but as > > another ml admin undid said moderation. not much i can do. i'm > > not getting into any revert wars with other admins. > > Just for the avoidance of doubt, you don't see an issue stopping > emails discussing the CC election while being a CC candidate. > I think this speaks for itself without further explanation. yes, it shows that if elected, as a cc member, i will swiftly act to stop flames quickly. without banning anyone. a few mails maybe delayed by a few hours , but that will be a small price to pay for peace on ffmpeg-devel. thus giving the cc time to act and make a decision later. after all we are a volunteer project and are not all active 24/7. thanks for your kind words, kieran. its always a pleasure to discuss things with you. -compn ___ ffmpeg-devel mailing list ffmpeg-devel@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] ffv1dec: add support for hardware acceleration
Hi On Fri, Dec 20, 2024 at 02:44:43AM +0900, Lynne via ffmpeg-devel wrote: > --- > libavcodec/ffv1.h| 2 + > libavcodec/ffv1dec.c | 451 +-- > 2 files changed, 268 insertions(+), 185 deletions(-) breaks fate on ubuntu x86-64 TESTffmpeg-loopback-decoding --- ./tests/ref/fate/ffmpeg-loopback-decoding 2024-12-11 21:54:14.484823827 +0100 +++ tests/data/fate/ffmpeg-loopback-decoding2024-12-20 02:28:25.556896430 +0100 @@ -5,53 +5,53 @@ #codec_id 0: rawvideo #dimensions 0: 704x288 #sar 0: 0/1 -0, 0, 0,1, 304128, 0xf6aa0942 -0, 1, 1,1, 304128, 0x5752d4ab -0, 2, 2,1, 304128, 0x3052ede5 -0, 3, 3,1, 304128, 0xdaf807b7 -0, 4, 4,1, 304128, 0x8f5c9990 -0, 5, 5,1, 304128, 0x75b58b80 -0, 6, 6,1, 304128, 0x5b9c7b06 -0, 7, 7,1, 304128, 0xee9c177a -0, 8, 8,1, 304128, 0x4fefb449 -0, 9, 9,1, 304128, 0x0a6d565d -0, 10, 10,1, 304128, 0x25fe7635 -0, 11, 11,1, 304128, 0x1d36be60 -0, 12, 12,1, 304128, 0xa63f571a -0, 13, 13,1, 304128, 0x7ec1f6b5 -0, 14, 14,1, 304128, 0x8c240ccf -0, 15, 15,1, 304128, 0x41bbbc2a -0, 16, 16,1, 304128, 0x611319e8 -0, 17, 17,1, 304128, 0x929d83ad -0, 18, 18,1, 304128, 0x45ae42a0 -0, 19, 19,1, 304128, 0x9dd20a04 -0, 20, 20,1, 304128, 0x61230985 -0, 21, 21,1, 304128, 0x643a6d0f -0, 22, 22,1, 304128, 0x5dd530dd -0, 23, 23,1, 304128, 0x92c56539 -0, 24, 24,1, 304128, 0xc364f034 -0, 25, 25,1, 304128, 0x7a476be9 -0, 26, 26,1, 304128, 0xee4ac625 -0, 27, 27,1, 304128, 0x9e9c13c4 -0, 28, 28,1, 304128, 0x6097cda9 -0, 29, 29,1, 304128, 0x3a6c370c -0, 30, 30,1, 304128, 0xfa740b74 -0, 31, 31,1, 304128, 0x9d13798e -0, 32, 32,1, 304128, 0x61b5ffc1 -0, 33, 33,1, 304128, 0x34b30667 -0, 34, 34,1, 304128, 0x303681b4 -0, 35, 35,1, 304128, 0xe63508fc -0, 36, 36,1, 304128, 0x10ef6b65 -0, 37, 37,1, 304128, 0x17c8d2b5 -0, 38, 38,1, 304128, 0x053d9db5 -0, 39, 39,1, 304128, 0x43dd5c5b -0, 40, 40,1, 304128, 0xba4b65f2 -0, 41, 41,1, 304128, 0x4dc70aa2 -0, 42, 42,1, 304128, 0x9e2a528f -0, 43, 43,1, 304128, 0x53df2931 -0, 44, 44,1, 304128, 0xe1d12fbd -0, 45, 45,1, 304128, 0xcb863c4c -0, 46, 46,1, 304128, 0x528e2e81 -0, 47, 47,1, 304128, 0x880c0b66 -0, 48, 48,1, 304128, 0x83ec648a -0, 49, 49,1, 304128, 0xa5d2555d +0, 0, 0,1, 304128, 0x27682f92 +0, 1, 1,1, 304128, 0x49a0e607 +0, 2, 2,1, 304128, 0x18d61056 +0, 3, 3,1, 304128, 0xfa3d00b5 +0, 4, 4,1, 304128, 0xf5666c5a +0, 5, 5,1, 304128, 0xe93336d6 +0, 6, 6,1, 304128, 0x4edd4565 +0, 7, 7,1, 304128, 0x25f28c87 +0, 8, 8,1, 304128, 0xc83ab404 +0, 9, 9,1, 304128, 0x2573204e +0, 10, 10,1, 304128, 0x6d8d80c6 +0, 11, 11,1, 304128, 0xb2ea1059 +0, 12, 12,1, 304128, 0x8d1769c0 +0, 13, 13,1, 304128, 0x7aa43e41 +0, 14, 14,1, 304128, 0xc33fb526 +0, 15, 15,1, 304128, 0x5fafa993 +0, 16, 16,1, 304128, 0x2368bce5 +0, 17, 17,1, 304128, 0x694b6be4 +0, 18, 18,1, 304128, 0x38442872 +0, 19, 19,1, 304128, 0xbfcb87cb +0, 20, 20,1, 304128, 0x5e8d459d +0, 21, 21,1, 304128, 0x5168b3c8 +0, 22, 22,1, 304128, 0x84222a1c +0, 23, 23,1, 304128, 0x567b951b +0, 24, 24,1, 304128, 0x26c1df6a +0, 25,
Re: [FFmpeg-devel] [PATCH] swscale/unscaled: add pal8 -> gbr(a)p special converter
On 12/18/2024 11:24 AM, Niklas Haas wrote:
From: Niklas Haas
Fixes: ticket #9520
Signed-off-by: Niklas Haas
Sponsored-by: Sovereign Tech Fund
---
libswscale/swscale.c | 2 +
libswscale/swscale_unscaled.c | 81 ++-
2 files changed, 81 insertions(+), 2 deletions(-)
diff --git a/libswscale/swscale.c b/libswscale/swscale.c
index 96634acfd6..bd5b6370db 100644
--- a/libswscale/swscale.c
+++ b/libswscale/swscale.c
@@ -910,6 +910,8 @@ void ff_update_palette(SwsInternal *c, const uint32_t *pal)
case AV_PIX_FMT_BGR32_1:
#if HAVE_BIGENDIAN
case AV_PIX_FMT_BGR24:
+case AV_PIX_FMT_BGRP:
+case AV_PIX_FMT_BGRAP:
These don't exist. And GBRP/GBRAP would need c->pal_rgb to be ordered in
a different way.
#endif
c->pal_rgb[i]= a + (r<<8) + (g<<16) + ((unsigned)b<<24);
break;
diff --git a/libswscale/swscale_unscaled.c b/libswscale/swscale_unscaled.c
index c7ad6b014a..973ffe0299 100644
--- a/libswscale/swscale_unscaled.c
+++ b/libswscale/swscale_unscaled.c
@@ -509,6 +509,34 @@ static void gray8aToPacked24(const uint8_t *src, uint8_t
*dst, int num_pixels,
}
}
+static void gray8aToPlanar8(const uint8_t *src, uint8_t *dstG, uint8_t *dstB,
+uint8_t *dstR, uint8_t *dstA, int num_pixels,
+const uint8_t *palette)
+{
+for (int i = 0; i < num_pixels; i++) {
+const uint8_t *rgb = &palette[src[i << 1] * 4];
+dstB[i] = rgb[0];
+dstG[i] = rgb[1];
+dstR[i] = rgb[2];
+if (dstA)
+dstA[i] = src[(i << 1) + 1];
+}
+}
+
+static void pal8ToPlanar8(const uint8_t *src, uint8_t *dstG, uint8_t *dstB,
+ uint8_t *dstR, uint8_t *dstA, int num_pixels,
+ const uint8_t *palette)
+{
+for (int i = 0; i < num_pixels; i++) {
+const uint8_t *rgba = &palette[src[i] * 4];
Does this work in both big and little endian? c->pal_rgb is uint32_t,
and ff_update_palette() sets it in a native endian way.
+dstB[i] = rgba[0];
+dstG[i] = rgba[1];
+dstR[i] = rgba[2];
+if (dstA)
+dstA[i] = rgba[3];
+}
+}
+
static int bswap_16bpc(SwsInternal *c, const uint8_t *const src[],
const int srcStride[], int srcSliceY, int
srcSliceH,
uint8_t *const dst[], const int dstStride[])
@@ -610,6 +638,45 @@ static int palToRgbWrapper(SwsInternal *c, const uint8_t
*const src[], const int
return srcSliceH;
}
+static int palToGbrpWrapper(SwsInternal *c, const uint8_t *const src[],
+const int srcStride[], int srcSliceY, int
srcSliceH,
+uint8_t *const dst[], const int dstStride[])
+{
+const enum AVPixelFormat srcFormat = c->opts.src_format;
+const enum AVPixelFormat dstFormat = c->opts.dst_format;
+void (*conv)(const uint8_t *src, uint8_t *dstG, uint8_t *dstB, uint8_t
*dstR,
+ uint8_t *dstA, int num_pixels, const uint8_t *palette) = NULL;
+
+const int num_planes = isALPHA(dstFormat) ? 4 : 3;
+const uint8_t *srcPtr = src[0];
+uint8_t *dstPtr[4] = {0};
+for (int i = 0; i < num_planes; i++)
+dstPtr[i] = dst[i] + dstStride[i] * srcSliceY;
+
+if (srcFormat == AV_PIX_FMT_YA8) {
+switch (dstFormat) {
+case AV_PIX_FMT_GBRP: conv = gray8aToPlanar8; break;
+case AV_PIX_FMT_GBRAP: conv = gray8aToPlanar8; break;
+}
+} else if (usePal(srcFormat)) {
+switch (dstFormat) {
+case AV_PIX_FMT_GBRP: conv = pal8ToPlanar8; break;
+case AV_PIX_FMT_GBRAP: conv = pal8ToPlanar8; break;
+}
+}
+
+av_assert1(conv);
+for (int y = 0; y < srcSliceH; y++) {
+conv(srcPtr, dstPtr[0], dstPtr[1], dstPtr[2], dstPtr[3], c->opts.src_w,
+(uint8_t *) c->pal_rgb);
+srcPtr += srcStride[0];
+for (int i = 0; i < num_planes; i++)
+dstPtr[i] += dstStride[i];
+}
+
+return srcSliceH;
+}
+
static void packed16togbra16(const uint8_t *src, int srcStride,
uint16_t *dst[], const int dstStride[], int
srcSliceH,
int src_alpha, int swap, int shift, int width)
@@ -2529,8 +2596,18 @@ void ff_get_unscaled_swscale(SwsInternal *c)
IS_DIFFERENT_ENDIANESS(srcFormat, dstFormat, AV_PIX_FMT_GBRAPF32))
c->convert_unscaled = bswap_32bpc;
-if (usePal(srcFormat) && isByteRGB(dstFormat))
-c->convert_unscaled = palToRgbWrapper;
+if (usePal(srcFormat)) {
+switch (dstFormat) {
+case AV_PIX_FMT_GBRP:
+case AV_PIX_FMT_GBRAP:
+c->convert_unscaled = palToGbrpWrapper;
+break;
+default:
+if (isByteRGB(dstFormat))
+c->convert_unscaled = palToRgbWrapper;
+break;
+}
+}
if (srcFo
Re: [FFmpeg-devel] Fwd: Your message to ffmpeg-devel awaits moderator approval
On Thu, Dec 19, 2024 at 9:11 PM compn wrote: > > On Thu, 19 Dec 2024 20:40:55 +, Kieran Kunhya via ffmpeg-devel > wrote: > > > Please can you confirm you will be resigning your moderator status in light > > of the election censorship you have undertaken while at the same time being > > a candidate for CC? > > i have no intention to resign from being ml admin. > > i took the initiative to moderate the thread from flames, but as > another ml admin undid said moderation. not much i can do. i'm > not getting into any revert wars with other admins. Just for the avoidance of doubt, you don't see an issue stopping emails discussing the CC election while being a CC candidate. I think this speaks for itself without further explanation. 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".
[FFmpeg-devel] [PATCH v2] avcodec/h264_mb: Fix tmp buffer overlap in mc_part_weighted
When decoding a bitstream with weighted-bipred enabled, the results on ARM and x86 platforms may differ. The reason for the inconsistency is that the value of STRIDE_ALIGN differs between platforms. And STRIDE_ALIGN is set to the buffer stride of temporary buffers for U and V components in mc_part_weighted. If the buffer stride is 32 or 64 (as on x86 platforms), the U and V pixels can be interleaved row by row without overlapping, resulting in correct output. However, on ARM platforms where the stride is 16, the V component will overwrite part of the U component's pixels, leading to incorrect predicted pixels. Fixes: ticket 11357 Signed-off-by: Bin Peng --- libavcodec/h264_mb.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/libavcodec/h264_mb.c b/libavcodec/h264_mb.c index 4e94136313..b480cd312b 100644 --- a/libavcodec/h264_mb.c +++ b/libavcodec/h264_mb.c @@ -407,8 +407,8 @@ static av_always_inline void mc_part_weighted(const H264Context *h, H264SliceCon /* don't optimize for luma-only case, since B-frames usually * use implicit weights => chroma too. */ uint8_t *tmp_cb = sl->bipred_scratchpad; -uint8_t *tmp_cr = sl->bipred_scratchpad + (16 << pixel_shift); -uint8_t *tmp_y = sl->bipred_scratchpad + 16 * sl->mb_uvlinesize; +uint8_t *tmp_cr = sl->bipred_scratchpad + (16 * sl->mb_uvlinesize); +uint8_t *tmp_y = sl->bipred_scratchpad + (32 * sl->mb_uvlinesize); int refn0 = sl->ref_cache[0][scan8[n]]; int refn1 = sl->ref_cache[1][scan8[n]]; -- 2.25.1 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] Fwd: Your message to ffmpeg-devel awaits moderator approval
Quoting Michael Niedermayer (2024-12-19 20:52:39) > This was a brave decission and IMO it was the correct decission. > You saw people fighting, and you stepped between them to stop it. So what we have here is a server admin approving and encouraging his buddy to perform arbitrary censorship with no oversight. Said buddy was granted moderator privileges for no reason anyone can articulate, sees no difference between acting as a moderator and acting as a private person, recently resurfaced after 6+ years of complete absence, and yet apparently feels entirely at liberty to censor whatever he wants. I really hope that makes it clear to everyone why there needs to be a proper process for access to infrastructure, and "just leave everything to Michael" leads exactly to the situation we have now, and all the similar situations we've had in the past. No, Michael, it's not "unfriendly people". It's you. It's always been you. Other projects do not have these problems at such a regular basis. -- Anton Khirnov ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v2] avcodec/h264: fix stride calculation in slice_table for multi-slice field video deblocking
fix for https://trac.ffmpeg.org/ticket/11360
Signed-off-by: Lingyi Kong
---
libavcodec/h264_mb.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/h264_mb.c b/libavcodec/h264_mb.c
index 4e94136313..6083f7ad84 100644
--- a/libavcodec/h264_mb.c
+++ b/libavcodec/h264_mb.c
@@ -529,7 +529,7 @@ static av_always_inline void xchg_mb_border(const
H264Context *h, H264SliceConte
}
if (sl->deblocking_filter == 2) {
-deblock_topleft = h->slice_table[sl->mb_xy - 1 - h->mb_stride] ==
sl->slice_num;
+deblock_topleft = h->slice_table[sl->mb_xy - 1 - (h->mb_stride <<
MB_FIELD(sl))] == sl->slice_num;
deblock_top = sl->top_type;
} else {
deblock_topleft = (sl->mb_x > 0);
--
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] [PATCH v3] avcodec/h264_mb: Fix tmp buffer overlap in mc_part_weighted
When decoding a bitstream with weighted-bipred enabled, the results on ARM and x86 platforms may differ. The reason for the inconsistency is that the value of STRIDE_ALIGN differs between platforms. And STRIDE_ALIGN is set to the buffer stride of temporary buffers for U and V components in mc_part_weighted. If the buffer stride is 32 or 64 (as on x86 platforms), the U and V pixels can be interleaved row by row without overlapping, resulting in correct output. However, on ARM platforms where the stride is 16, the V component will overwrite part of the U component's pixels, leading to incorrect predicted pixels. Fixes: ticket 11357 Signed-off-by: Bin Peng --- libavcodec/h264_mb.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/libavcodec/h264_mb.c b/libavcodec/h264_mb.c index 4e94136313..b480cd312b 100644 --- a/libavcodec/h264_mb.c +++ b/libavcodec/h264_mb.c @@ -407,8 +407,8 @@ static av_always_inline void mc_part_weighted(const H264Context *h, H264SliceCon /* don't optimize for luma-only case, since B-frames usually * use implicit weights => chroma too. */ uint8_t *tmp_cb = sl->bipred_scratchpad; -uint8_t *tmp_cr = sl->bipred_scratchpad + (16 << pixel_shift); -uint8_t *tmp_y = sl->bipred_scratchpad + 16 * sl->mb_uvlinesize; +uint8_t *tmp_cr = sl->bipred_scratchpad + (16 * sl->mb_uvlinesize); +uint8_t *tmp_y = sl->bipred_scratchpad + (32 * sl->mb_uvlinesize); int refn0 = sl->ref_cache[0][scan8[n]]; int refn1 = sl->ref_cache[1][scan8[n]]; -- 2.25.1 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
