On 5/17/2024 7:50 PM, Michael Niedermayer wrote:
> The people on the booth are predominantly male. Similarly ffmpeg-devel
> is predominantly male. More gender diversity would be good.
That I can agree with.
- Derek
___
ffmpeg-devel mailing list
On 5/17/2024 2:49 PM, Michael Niedermayer wrote:
> Also we need more cute girls on these events, everything i hear
> its 100% male geeks/hackers.
This is gross and sexist.
- Derek
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
Both the codecpar's width and height, and the SAR num and den are
ints, which can overflow. Cast to int64_t, which is what av_reduce
takes.
Without this, occasionally, display_aspect_ratio can be negative in
ffprobe's -show_stream output.
Signed-off-by: Derek Buitenhuis
---
fftools/ffprobe.c
On 4/25/2024 9:22 PM, Martin Storsjö wrote:
> Thanks, these patches LGTM.
Pushed, thanks.
- Derek
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
Hi,
Replies inline.
On 4/26/2024 12:10 AM, Javier Matos Denizac via ffmpeg-devel wrote:
> Actually, I noticed that you publish release tarballs ->
> http://rtmpdump.mplayerhq.hu/download/, but I don’t see a release tarball for
> 2.4. Would y’all be willing to publish a release for 2.4 and
, chances of success
are very unlikely.
Some references:
* https://datatracker.ietf.org/doc/html/rfc6585
* https://datatracker.ietf.org/doc/html/rfc7231#section-7.1.3
This adds an AVOption to respect that header.
Signed-off-by: Derek Buitenhuis
---
doc/protocols.texi| 5 +
libavformat
That is what it actually does, and it will be needed for more
than the Expiry header soon.
Signed-off-by: Derek Buitenhuis
---
libavformat/http.c | 38 +++---
1 file changed, 19 insertions(+), 19 deletions(-)
diff --git a/libavformat/http.c b/libavformat/http.c
Changes since last set:
* Updated commit message with RFC references.
* Properly support Retry-After as both a date and integer number of seconds.
I have tested this against both an HTTP-Date and seconds, and confirmed
it to work.
Derek Buitenhuis (2):
avformat/http: Rename
On 4/24/2024 8:43 PM, Derek Buitenhuis wrote:
> Applied all your comments.
>
> Will wait a day and then push if no others appear.
Pushed all except Retry-After support, which I need to change.
While adding RFC references I noticed it can be in seconds, *or*
a date... fun.
Sending a
On 4/23/2024 10:46 PM, Michael Niedermayer wrote:
> Can you elaborate what the problem is ?
> I would have thought https://git.ffmpeg.org/rtmpdump.git
> is secure
I have to assume he means SHA-256, and not SHA-512.
git apparently supports using SHA-256 instead of SHA-1 hashes,
but support does
On 4/24/2024 12:13 PM, Martin Storsjö wrote:
> I had a look over this patchset, and I had a handful of minor comments,
> but overall, the patchset seems fine to me. Thanks!
Applied all your comments.
Will wait a day and then push if no others appear.
- Derek
On 4/24/2024 12:08 PM, Martin Storsjö wrote:
> Minor inconsistency; the corresponding variable in the other function was
> called conn_attempts, as a plural.
Renamed to the plural version.
- Derek
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
On 4/24/2024 11:58 AM, Martin Storsjö wrote:
> This function seems to handle both the literal status codes, like 429, and
> also AVERROR style error codes, as when called from handle_http_errors, so
> perhaps it would be good for consistency to add the AVERROR here too.
Good catch. Added.
-
On 4/24/2024 11:53 AM, Martin Storsjö wrote:
> Typo in the commit message
Fixed locally.
- Derek
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
On 4/24/2024 12:06 PM, Martin Storsjö wrote:
> Is this feature standardized in a RFC, or is it some other spec somewhere?
> I think it would be nice with a link to a spec in the commit message here.
It is in the RFC for 429 I noted in the commit I added that: RFC6585. It is also
probably in the
On 4/22/2024 3:25 PM, Derek Buitenhuis wrote:
> +{ ERROR_TAG(HTTP_TOO_MANY_REQUESTS), "Server returned 404 Too Many
> Requests" },
Derp.
Change locally to "Server returned 429 Too Many Requests".
- Derek
___
ffmpeg
On 4/16/2024 6:13 PM, Stefano Sabatini wrote:
>> +@item metadata
>> +An exported dictionary containing Icecast metadata from the bitstream, if
>> present.
>> +Only useful with the C API.
>
> Probably best to use impersonal verbal mode:
> Set an exported ...
This is not quite right. This is not
accomplished by the the existing
reconnect_delay_max default of 120.
Signed-off-by: Derek Buitenhuis
---
libavformat/http.c| 12 ++--
libavformat/version.h | 2 +-
2 files changed, 11 insertions(+), 3 deletions(-)
diff --git a/libavformat/http.c b/libavformat/http.c
index 06bd3e340e
Not every use case benefits from setting retries in terms of the backoff.
Signed-off-by: Derek Buitenhuis
---
libavformat/http.c| 12 +---
libavformat/version.h | 2 +-
2 files changed, 10 insertions(+), 4 deletions(-)
diff --git a/libavformat/http.c b/libavformat/http.c
index
This accurately reflects what it does, as per
e75bbcf493aeb549d04c56f49406aeee3950d93b.
Signed-off-by: Derek Buitenhuis
---
libavformat/http.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/libavformat/http.c b/libavformat/http.c
index 5ed481b63a
Signed-off-by: Derek Buitenhuis
---
doc/protocols.texi | 35 ++-
1 file changed, 34 insertions(+), 1 deletion(-)
diff --git a/doc/protocols.texi b/doc/protocols.texi
index 5ce1ddc8f4..ed70af4b33 100644
--- a/doc/protocols.texi
+++ b/doc/protocols.texi
@@ -492,6
This makes the list easier to maintain.
Signed-off-by: Derek Buitenhuis
---
doc/protocols.texi | 112 ++---
1 file changed, 56 insertions(+), 56 deletions(-)
diff --git a/doc/protocols.texi b/doc/protocols.texi
index f54600b846..5ce1ddc8f4 100644
unlikely.
This adds an AVOption to respect that header.
Signed-off-by: Derek Buitenhuis
---
libavformat/http.c| 12
libavformat/version.h | 2 +-
2 files changed, 13 insertions(+), 1 deletion(-)
diff --git a/libavformat/http.c b/libavformat/http.c
index e7603037f4..5ed481b63a
Many "bad" HTTP codes like 429 and 503 may include important info in
their headers.
Also, in general, there is no purpose in bailing here.
Signed-off-by: Derek Buitenhuis
---
libavformat/http.c | 25 -
1 file changed, 20 insertions(+), 5 deletions(-)
Added in thep previous commit.
Signed-off-by: Derek Buitenhuis
---
libavformat/http.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/libavformat/http.c b/libavformat/http.c
index ed20359552..bbace2694f 100644
--- a/libavformat/http.c
+++ b/libavformat/http.c
@@ -286,6 +286,7
This is a common error code from e.g. CDNs or cloud storage, and
it is useful to be able to handle it differently to a generic
4XX code.
Its source is RFC6585.
Signed-off-by: Derek Buitenhuis
---
libavutil/error.c | 1 +
libavutil/error.h | 1 +
libavutil/version.h | 2 +-
3 files changed
strtoull, per James' review.
* Added docs, as per Stefano's reviews./
* Added a new option to limit the total reconnect delay.
* Unfortunate, but HTTP connection management is messy business.
Original set link:
https://ffmpeg.org/pipermail/ffmpeg-devel/2024-April/325706.html
Derek
On 4/17/2024 8:33 PM, James Almer wrote:
>>> This was an unnecessary personal attack, please don't do that again. Repeat
>>> offense may result in temporary bans on the mailinglist and/or IRC. Please
>>> keep it civil.
>>
>> That does not make it untrue, however.
>
> It's ok to have opinions. But
On 4/17/2024 8:00 PM, Ronald S. Bultje wrote:
> This was an unnecessary personal attack, please don't do that again. Repeat
> offense may result in temporary bans on the mailinglist and/or IRC. Please
> keep it civil.
That does not make it untrue, however.
I would have preferred a ban.
- Derek
On 4/17/2024 2:54 PM, James Almer wrote:
> But why were there GPAC people at the FFmpeg booth?
> And i don't think a single person should represent the project in these
> conferences to begin with. All this should go through the GA, including
> who funds it and how.
That is a good question, and
On 4/17/2024 12:21 AM, Devin Heitmueller wrote:
> Hello all,
[...]
Yeah, this is exactly what I was screaming into the void about
for literal months, no literally 0 response.
Look for the thread: [FFmpeg-devel] FFmpeg at NAB 2024
It spans months.
My last mail is particularily relevant to your
On 4/15/2024 6:33 PM, Stefano Sabatini wrote:
> missing doc/protocols.texi update
Sent patch 7 and 8 to address this.
- Derek
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit
Signed-off-by: Derek Buitenhuis
---
doc/protocols.texi | 30 ++
1 file changed, 30 insertions(+)
diff --git a/doc/protocols.texi b/doc/protocols.texi
index 5ce1ddc8f4..60c6d831dd 100644
--- a/doc/protocols.texi
+++ b/doc/protocols.texi
@@ -492,6 +492,10 @@ contains
This makes the list easier to maintain.
Signed-off-by: Derek Buitenhuis
---
doc/protocols.texi | 112 ++---
1 file changed, 56 insertions(+), 56 deletions(-)
diff --git a/doc/protocols.texi b/doc/protocols.texi
index f54600b846..5ce1ddc8f4 100644
On 4/9/2024 4:15 PM, Derek Buitenhuis wrote:
> To me, it LGTM, but I would like someone more experience in H.264 internals
> to OK it, too - possibly Michael?
If there are no objections raised, I will merge this tomorrow.
- Derek
___
ffmpeg
On 4/15/2024 5:35 PM, James Almer wrote:
> Why strtoull for an int? If the value can't be negative, then make it
> unsigned and use strtoul instead.
Done, v2 sent.
- Derek
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
unlikely.
This adds an AVOption to respect that header.
Signed-off-by: Derek Buitenhuis
---
libavformat/http.c| 12
libavformat/version.h | 2 +-
2 files changed, 13 insertions(+), 1 deletion(-)
diff --git a/libavformat/http.c b/libavformat/http.c
index e7603037f4..5ed481b63a
On 4/15/2024 5:43 PM, Derek Buitenhuis wrote:
> ---
> libavutil/error.c | 1 +
> libavutil/error.h | 1 +
> libavutil/version.h | 2 +-
> 3 files changed, 3 insertions(+), 1 deletion(-)
This is a v2 I forgot to tag as v2. Woops.
- Derek
___
On 4/15/2024 5:31 PM, Andreas Rheinhardt wrote:
> Wouldn't you need to add a new entry to error_entries in error.c for this?
You are right, I missed that since grep failed me, as error.c uses macros, and
thus does not contain any AVERROR_HTTP_* directly.
I have sent a v2 for this patch.
- Derek
This is a common error code from e.g. CDNs or cloud storage, and
it is useful to be able to handle it differently to a generic
4XX code.
Its source is RFC6585.
Signed-off-by: Derek Buitenhuis
---
libavutil/error.c | 1 +
libavutil/error.h | 1 +
libavutil/version.h | 2 +-
3 files changed
Not every use case benefits from setting retries in terms of the backoff.
Signed-off-by: Derek Buitenhuis
---
libavformat/http.c| 12 +---
libavformat/version.h | 2 +-
2 files changed, 10 insertions(+), 4 deletions(-)
diff --git a/libavformat/http.c b/libavformat/http.c
index
This accurately reflects what it does, as per
e75bbcf493aeb549d04c56f49406aeee3950d93b.
Signed-off-by: Derek Buitenhuis
---
libavformat/http.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/libavformat/http.c b/libavformat/http.c
index 8f092f108d
unlikely.
This adds an AVOption to respect that header.
Signed-off-by: Derek Buitenhuis
---
libavformat/http.c| 12
libavformat/version.h | 2 +-
2 files changed, 13 insertions(+), 1 deletion(-)
diff --git a/libavformat/http.c b/libavformat/http.c
index e7603037f4..8f092f108d
Many "bad" HTTP codes like 429 and 503 may include important info in
their headers.
Also, in general, there is no purpose in bailing here.
Signed-off-by: Derek Buitenhuis
---
libavformat/http.c | 25 -
1 file changed, 20 insertions(+), 5 deletions(-)
Added in thep previous commit.
Signed-off-by: Derek Buitenhuis
---
libavformat/http.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/libavformat/http.c b/libavformat/http.c
index ed20359552..bbace2694f 100644
--- a/libavformat/http.c
+++ b/libavformat/http.c
@@ -286,6 +286,7
This is a common error code from e.g. CDNs or cloud storage, and
it is useful to be able to handle it differently to a generic
4XX code.
Its source is RFC6585.
Signed-off-by: Derek Buitenhuis
---
libavutil/error.h | 1 +
libavutil/version.h | 2 +-
2 files changed, 2 insertions(+), 1
This patch set adds support for properly handling HTTP 429 codes,
and their rate limiting, which is widely used and is standardized.
Derek Buitenhuis (6):
avutil/error: Add HTTP 429 Too Many Requests AVERROR code
avformat/http: Use AVERROR_HTTP_TOO_MANY_REQUESTS
avformat/http: Don't bail
On 4/3/2024 10:45 PM, arch1t3cht wrote:
> Can I bump this? It's my first time sending a patch here so let me know
> if I did something wrong.
To me, it LGTM, but I would like someone more experience in H.264 internals
to OK it, too - possibly Michael?
- Derek
On 11/1/2023 9:25 PM, Derek Buitenhuis wrote:
> This is certainly interesting considering we just had a giant thread about
> not using
> or using SPI, with multiple people accused of having corporate interests.
Adding to the list of wtf NAB things:
https://twitter.com/JanetGreco
On 3/5/2024 2:46 PM, James Almer wrote:
> It's a per packet/frame side data type.
>
> Signed-off-by: James Almer
> ---
> libavcodec/decode.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
LGTM
- Derek
___
ffmpeg-devel mailing list
On 3/4/2024 1:06 PM, Anton Khirnov wrote:
> +/**
> + * Decoding only. May be set by the caller before avcodec_open2() to an
> + * av_malloc()'ed array (or via AVOptions). Owned and freed by the
> decoder
> + * afterwards.
> + *
> + * By default, when some side data type is
On 2/9/2024 3:32 AM, Michael Niedermayer wrote:
> please make sure its marked on the bug tracker so it shows up here:
>
> https://trac.ffmpeg.org/query?status=new=open=reopened=~7.0
>
> thx
Done: https://trac.ffmpeg.org/ticket/10857
- Derek
___
Hello,
On 2/8/2024 6:02 AM, Pierre-Anthony Lemieux wrote:
> The suggested approach is that interested individuals email me, no
> later than Feb 10 at 23:59 UTC, a completed SOW using the template at
> [2].
I feel obliged to point out that the GA vote Michael called n this ends
on 11 Feb,after
Hi,
On 1/23/2024 7:22 PM, Michael Niedermayer wrote:
> What is blocking? (IMHO)
> * regressions (unless its non possible to fix before release)
> * crashes
> * security issues
> * data loss
> * privacy issues
> * anything the commuity agrees should be in the release
We discussed it at FOSDEM,
On 1/31/2024 9:44 PM, Derek Buitenhuis wrote:
> On 1/30/2024 1:48 AM, Michael Niedermayer wrote:
>> https://trac.ffmpeg.org/wiki/SponsoringPrograms/STF/2024
>
> Not to derail this fine thread, but what forks does the Merge Forks
> project refer to?
I do not believe this
On 1/30/2024 1:48 AM, Michael Niedermayer wrote:
> https://trac.ffmpeg.org/wiki/SponsoringPrograms/STF/2024
Not to derail this fine thread, but what forks does the Merge Forks
project refer to?
- Derek
___
ffmpeg-devel mailing list
On 1/28/2024 10:31 PM, Jean-Baptiste Kempf wrote:
> It would be a great idea to meet for a FFmpeg discussion, since quite a few
> of us will be there.
> So please bring your technical topics with you
I would like to propose discussion a solution to the current frame/stream side
data issue
On 1/29/2024 8:19 PM, Anton Khirnov wrote:
> I, for one, see a much bigger problem in the fact that it only starts
> being discussed on the ML this late, after so much underground dealings
> that bypassed the community entirely.
+1
- Derek
___
On 1/29/2024 8:09 PM, Vittorio Giovara wrote:
> This is not something that should be discussed on a public ML and the lack
> of visibility and clarity on how SPI/STM got involved this time around is
> at least disingenuous IMO.
I am more curious how Thilo managed to insert himself as the sole
>> On 1/28/2024 3:25 AM, Michael Niedermayer wrote:
>> As others have said, the whole model of using discrete projects here seems
>> opposed to
>> the actual intent of the STF - maintained and stable OSS long term.
>
> The whole suggestion here is based on what STF and SPI said. There was a
>
On 1/29/2024 3:02 PM, Kieran Kunhya wrote:
> In this project, acceptance of a patch is based on the technical contents
> of a patch, not a few vague paragraphs in a SoW. These decisions are made
> by the Technical Committee and the General Assembly.
>
> Tying the project contractually is
On 1/29/2024 2:26 AM, Jonatas L. Nogueira via ffmpeg-devel wrote:
> Because the General Assembly will already have exercised its sovereignty
> before the work started.
The contract needs to be shared with the GA for it to be able to actually
exercise its sovereignty.
Frankly this all seems
On 1/28/2024 3:25 AM, Michael Niedermayer wrote:
> At this point, what we need is a list of Projects so we can submit an
> application to STF
> at or before 12th Feb. (at the 14th they have a meeting and will review our
> submission)
> What STF told us, they need ATM is:
As others have said,
On 12/18/2023 2:58 PM, Petr Matousek wrote:
> +writer_print_integers(w, "data", sd->data+16, sd->size-16,
> "%02x", sd->size-16, 1, 1);
Wont this explode on malformed input where size < 16?
- Derek
___
ffmpeg-devel mailing list
On 11/28/2023 3:50 PM, Anton Khirnov wrote:
> Calling things generically bad is the opposite of helpful.
I cannot offer help on making a paragraph that I don't fully
understand become more comprehensible, as that would require
I understand it fully.
But, I would again like to state these votes
On 11/28/2023 2:30 PM, Derek Buitenhuis wrote:
> Direct insults are unacceptable and I have forwarded this to CC,
> which can hopefully look after the vote.
(I include myself in this, the irony wasn't lost on me.)
- Derek
___
ffmpeg-devel mailin
On 11/28/2023 2:25 PM, Paul B Mahol wrote:
> Looks like average IQ dropped bellow room temperature.
Direct insults are unacceptable and I have forwarded this to CC,
which can hopefully look after the vote.
- Derek
___
ffmpeg-devel mailing list
On 11/28/2023 1:23 PM, Anton Khirnov wrote:
> The system will assume you want to maximise the sum of weights of
> selected candidates. E.g. if X is given a weight of 10 and Y and Z have
> weights 8 and 6 respectively, then the voting algorithm will assume you
> prefer a committee with both Y
On 11/20/2023 3:44 PM, Thilo Borgmann via ffmpeg-devel wrote:
> the results are available at [1]. As they confirm the just updated GA list as
> well as the update procedure twice a year on Jan 1st & Jul 1st, I think the
> upcoming votes (extra GA members, TC/CC elections) can then proceed as
>
On 11/19/2023 2:19 PM, Derek Buitenhuis wrote:
> http://ffmpeg.org/pipermail/ffmpeg-devel/2023-November/317196.html
FFS. Here is the right link:
http://ffmpeg.org/pipermail/ffmpeg-devel/2023-November/316603.html
- Deek
___
ffmpeg-devel mailing l
On 11/19/2023 2:05 PM, Derek Buitenhuis wrote:
> So who signed? The "anonymous" corproate entity, on behalf of FFmpeg, with out
> our consent?
http://ffmpeg.org/pipermail/ffmpeg-devel/2023-November/317196.html
Prob unrelated I a
Hi,
Followup question...
On 11/1/2023 9:25 PM, Derek Buitenhuis wrote:
> This is certainly interesting considering we just had a giant thread about
> not using
> or using SPI, with multiple people accused of having corporate interests.
I noticed FFmpeg is on the NAB floor plan.
Thi
This is an invalid do-over and I refuse to take part.
Please enjoy my private URL.
- Derek
Forwarded Message
Subject:Poll: Repeat vote: GA voters list updates
Date: Sun, 12 Nov 2023 15:00:41 +0100 (CET)
From: Thilo Borgmann (CIVS poll supervisor)
Reply-To:
On 11/4/2023 4:22 PM, Derek Buitenhuis wrote:
> the sample duration of the last packet in the stts box. Pre-roll is
> store in the sgpb
Bah. Please try and ignore my various typos of 'sgpd'.
- Derek
___
ffmpeg-devel mailing list
ffmpeg
Hi,
I'm going to opine a bit here, and also comment on the mov/MP4 patch[0] that
accompanies
this set.
This is for both historical purposes, and to distill IRC logs into something
more
digestible for others on the list to gain context on the issue, so apologies for
re-treading ground.
On
On 11/1/2023 8:37 PM, Thilo Borgmann via ffmpeg-devel wrote:
> We reiceived an anonymous corporate sponsorship for the booth, so there are
> no
> costs for the FFmpeg project to it (and no obligations, of course).
This is certainly interesting considering we just had a giant thread about not
On 10/25/2023 2:14 PM, Thilo Borgmann via ffmpeg-devel wrote:
> To test the voting beforehand this time, I created a test vote with a fake-GA
> member list. All of the following people should have received a corresponding
> mail. If you are part of this list, but did not receive an email, check
On 10/10/2023 3:09 PM, James Almer wrote:
> The email was sent from ffc...@gmx.de, a domain that some email
> providers apparently dislike? Google at least is fine with it.
I did not get it, not even in my spam. Neither did Vittorio.
- Derek
___
On 10/10/2023 12:56 PM, Michael Niedermayer wrote:
> a vote on the General Assembly composition was apparently initiated with
> a duration of 6 days, i saw this in my inbox:
> "1009 23:49 Jean-Baptiste K (3,4K) Poll: FFmpeg AG members rules"
Without commenting on anything else, I thought it was
On 10/5/2023 6:32 PM, Lynne wrote:
> I counted 2048 with af-convert. Are you referring to qaac?
Referring to Apple's own documents, which have 2112 plastered everywhere.
- Derek
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
On 10/5/2023 11:46 PM, Stefano Sabatini wrote:
> I confirm it looks broken, sorry for that.
> I'll reach out SPI officials to get directions.
They replied to my ticket today. You and Michael should be
CCed.
- Derek
___
ffmpeg-devel mailing list
On 10/3/2023 5:07 AM, Lynne wrote:
> Despite this being a standard MDCT-based codec with a frame size of 1024,
> hence a delay of 1024 samples at the start, all major encoders, excluding
> faac and FFmpeg, use 2048 samples of padding.
Apple's uses 2112.
- Derek
On 9/29/2023 7:18 AM, Stefano Sabatini wrote:
> Once this is approved, follow instructions here to generate a refund request:
> https://www.spi-inc.org/treasurer/reimbursement-form/
One note: One step says to use the xe.com expensed calculator - however the
link provided is broken. Indeed the
On 9/26/2023 4:30 PM, Anton Khirnov wrote:
> This is disingenuous sophistry, and honestly I find it insulting that
> you expect people to swallow it.
I have been pretty silent on list, but as one of the people who has
access to the Twitter account as a delegate (but who was locked out
at the time
On 9/18/2023 6:18 PM, James Almer wrote:
> Only those that are relevant for the entire coded stream should be included.
>
> Signed-off-by: James Almer
> ---
> libavcodec/extract_extradata_bsf.c | 27 +++
> 1 file changed, 27 insertions(+)
+1'd on IRC, but doing so here,
Hello,
Nice to see you all again after so long.
My request is for my flights to/from Dublin, which cost 90.58 GBP.
- Derek
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit
On 9/24/2023 11:13 AM, Jean-Baptiste Kempf wrote:
> What are you talking about? This is just people in the room, who asked to be
> in the extra bucket, because they don't have the required commit numbers. It
> does not mean it's the complete list.
I do have the relevant commit numbers, I was
On 9/10/2023 4:32 PM, Lynne wrote:
> Both patches lgtm
Pushed.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with
On 9/10/2023 4:00 PM, llyyr wrote:
> Fixes: fc429d785e9e24c5520ce716d4bc3b5547e581eb
>
> cpb_cnt was initialized to 1 before
> fc429d785e9e24c5520ce716d4bc3b5547e581eb, so cpb_cnt_minus1 should be
> initialized to 0 instead of 1.
>
> Since we split fixed_rate into a general flag and a
Hi,
On 9/10/2023 6:51 AM, Zhao Zhili wrote:
> From: Zhao Zhili
>
> For bad interleaved files, manually interleave multiple tracks at the
> demuxer level can trigger seeking back and forth, which can be
> dramatically slow depending on the protocol. Demuxer level interleave
> can be useless
On 9/8/2023 2:09 PM, Michael Niedermayer wrote:
> Whats the scope of FFmpeg ?
> And is this direction that is taken optimal for FFmpeg, and what people want ?
Not that I don't think this is an issue worth discussing (it is), but I thought
it
was important to note that most/many of the people who
On 9/6/2023 6:31 PM, Kacper Michajlow wrote:
> What would be a downside of preferring CXX always if it exists?
FFmpeg runs in a multitude of environments with a multitude of portability
requirements. Needlessly linking a C++ runtime is not OK.
Further, we do not generally automatically change
On 9/5/2023 2:31 PM, James Almer wrote:
> Users relying on global side data being in the first packet need to call
> the inject() lavf function to enable said functionality. As that
> function is now deprecated, they will get the relevant warning and be
> directed to the global side data API.
>
On 9/4/2023 5:10 PM, James Almer wrote:
>> * Warn users they need to update their code to not use stream side data (?).
>>Will my code just silently change behavior if it was using stream
>>side data? I legitimately do not know due to the above.
>
> How so? This, like any other deprecated
On 9/4/2023 4:03 PM, James Almer wrote:
> 71 files changed, 737 insertions(+), 415 deletions(-)
I see no document updates, commit messages, or deprecation warnings
that would:
* Explain what and why this is happening - this should at the very
least be in the commit message(s), if not a doc
On 8/28/2023 5:06 PM, Zhao Zhili wrote:
> -if (!sample || (!(s->pb->seekable & AVIO_SEEKABLE_NORMAL) &&
> current_sample->pos < sample->pos) ||
> +if (!sample || (force_io_order && current_sample->pos <
> sample->pos) ||
Hmm, I think the name `io_order` is a misnomer: It
On 7/27/2023 9:16 AM, hung kuishing wrote:
> Let me briefly describe what I needed at that time:
> I have another prores encoder and another mov muxer, what I need to do are:
> 1. use "another mov muxer" to encapsulate prores bitstream generated by
> ffmpeg.
> 2. use ffmpeg to encapsulate prores
On 7/26/2023 10:28 AM, hung kuishing wrote:
> Signed-off-by: clarkh
> ---
> libavformat/Makefile | 2 ++
> libavformat/allformats.c | 2 ++
> libavformat/proresdec.c | 66
> libavformat/rawenc.c | 13
> 4 files changed, 83
Hello,
On 7/25/2023 12:21 PM, hung kuishing wrote:
> Signed-off-by: clarkh
> ---
> libavcodec/Makefile| 1 +
> libavcodec/parsers.c | 1 +
> libavcodec/prores_parser.c | 107 +
> libavformat/Makefile | 2 +
> libavformat/allformats.c
On 7/24/2023 3:37 AM, hung kuishing wrote:
> ---
> libavcodec/Makefile| 1 +
> libavcodec/parsers.c | 1 +
> libavcodec/prores_parser.c | 91 ++
> libavformat/Makefile | 2 +
> libavformat/allformats.c | 2 +
> libavformat/proresdec.c
1 - 100 of 1386 matches
Mail list logo
