On 11/22/2024 12:59 PM, epira...@gmail.com wrote:
> While I might not in principle disagree with the CCs action here, the (at
> least perceived) inaction of the CC
> in other cases makes this seem the CC has a huge double standard how to deal
> with things…
> (Or there is a big communication/tran
On 11/22/2024 12:41 PM, Nicolas George wrote:
> I do not agree with you on many things, including what you said on the
> criticised mail, but I fully agree with you that this intervention of a
> CC member is entirely inappropriate and abusive.
There are many things I've said lately that the CC cou
, complete bullshit.
The CC is a lame duck.
- Derek
Forwarded Message
Subject:Re: [FFmpeg-devel] [RFC] libpostproc splitout
Date: Thu, 21 Nov 2024 15:18:04 -0500
From: Ronald S. Bultje
To: Derek Buitenhuis
CC: c...@ffmpeg.org
Hi Derek,
On Thu, Nov 7, 2024
Buckle in, this'll be a bit of a ride. Part of it is inflamatory, and
part of it is paranoid (or not) rants. I accept this may be slander and
will pre-emptively ban myself for the sake of getting it in the open.
I do not wish to be involved in any voting or disucssions anymore,
related to the dire
On 11/12/2024 7:55 PM, compn wrote:
> On Tue, 12 Nov 2024 16:46:42 +
> Derek Buitenhuis wrote:
>
>> On 11/11/2024 7:34 PM, compn wrote:
>>> if your goal is to post old quotes, thats cool.
>>
>> Woosh.
>
> the quotes are from michael in 2015 s
On 11/12/2024 7:37 PM, compn wrote:
> concern trolling?
I am pointing out Michael's own logic isn't even consistent with itself.
What is logic *actually* is is that the of course *he* is trustworthy, to
him.
>
> you're concerned about one developer adding in a backdoor, so the
> solution is to
On 11/12/2024 6:41 PM, Rémi Denis-Courmont wrote:
> I don't think that Derek meant that literally. The GA is not a legal entity
> so it can't hold a domain name or a trademark in the first place, or for that
> matter physical servers or hosting service contracts. Just like the bank
> account, th
On 11/12/2024 5:05 PM, James Almer wrote:
> This is not true. I have write access to the website, for example, as do
> others. And Michael cuts releases because he was given the task, not
> because nobody else can or want. And nobody prevents anyone from just
> fetching a git tag instead (Distro
On 11/12/2024 5:07 PM, James Almer wrote:
> I personally don't agree with giving the domain/trademark to the general
> assembly, as some have argued. It's just not safe at all.
Sorry, I didn't necessarily mean giving it ot the GA. I mean having it in a
better state than being held hostage by some
On 11/11/2024 7:34 PM, compn wrote:
> if your goal is to post old quotes, thats cool.
Woosh.
> one of my goals is to make sure that certain developers, who made their
> own project and then ran it into the ground, arent made as admins
> again. they had a good run but couldnt even make an
> announ
On 11/11/2024 7:33 PM, Michael Niedermayer wrote:
>> This only convinces me further that it this whole setup ins't for for
>> purpose,
>> and is being run by people who have no concept of actual security. This is
>> totally insane.
Honestly, this is so exhausting and painful, I dread responding.
On 11/11/2024 4:42 PM, Michael Niedermayer wrote:
> Publically listing which developer provides which part of the DNS infra
> makes it easier to attack not harder.
> That said, i suspect who provides what was mentioned in the past already
It is already publically available info to anyone who can l
On 11/6/2024 2:48 PM, Michael Niedermayer wrote:
> do i unilaterally decide who i trust as root, maybe.
Q.E.D.
That, along with 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
On 11/10/2024 2:59 PM, Michael Niedermayer wrote:
> Its there since a long time:
> https://git.ffmpeg.org/gitweb/ffmpeg.git/blob/HEAD:/doc/infra.txt
[...]
> If something is missing, its not going to improve on its own.
> Someone will have to say _what_ is missing and work toward filling it in.
P
On 11/7/2024 11:33 PM, Michael Niedermayer wrote:
> And as a sidenote I and Derek where much friendlier towards each
> other from what i remember, than in the discussion today. I hope we will be
> friendlier towards each other in the future again.
On the contrary, I remember being a much, much big
On 11/9/2024 6:04 PM, Rémi Denis-Courmont wrote:
> What most people are concerned about right now is the incomplete
> documentation
> of any and all credentials - not just git write access - and more generally
> the lack of transparency. Once that is sorted out, we can start arguing about
> wha
On 11/7/2024 7:52 PM, Michael Niedermayer wrote:
> It also did not achieve the intended result. libpostproc did continue to
> live in FFmpeg since that 2012 till today.
Interesting way you've defined 'intended result' for yourself here.
> The goal of this project is to have a seperate libpostproc
On 11/7/2024 8:04 PM, Michael Niedermayer wrote:
> This is slander
>
> libpostproc was simply deleted from libav.
>
> The messed up repository you created in 2012, was never maintained by anyone
>
> of course copying something in a messed up form and deleting support for it
> is not worth 5k eu
On 11/6/2024 11:11 PM, Michael Niedermayer wrote:
> 1. split libpostproc out so it builds and links fine (already done) (send
> to SPI/STF/Invoice in future)
I did this in 2012, the git repo is still there:
http://git.videolan.org/?p=libpostproc.git;a=summary
This work was very easy and not
On 11/3/2024 4:37 PM, Michael Niedermayer wrote:
> I very strongly object to you calling me "misleading and disparagin"
I suspect this now deleted tweet meets the definition of "disparaging".
See: https://imgur.com/a/RdPW15a
The link was https://x.com/michael__ni/status/1853033116199219207
(I t
On 11/6/2024 11:11 PM, Michael Niedermayer wrote:
> 3. actually remove libpostproc from master repository (2025 future) (send
> to SPI/STF/Invoice in future)
I also did this exact work for Libav in 2012. It was very little work. Not 5k.
- Derek
___
On 10/18/2024 1:02 PM, Alexander Strasser via ffmpeg-devel wrote:
> Alexander Strasser (2):
> Reapply "tests/fate: disable compression for zlib-based codecs"
> fate: Make it possible to have alternative reference files
I want to add this here, since I brought it up on IRC.
I think this entire
Hi,
On 9/24/2024 3:22 PM, Devon Sookhoo wrote:
> Thanks for responding, I have been struggling to get any responses. I have
> tried to use the IRC on Libera, however the server seems to be down.
I suspect not too many people resonded on this list since it is more
for code review than anything. W
On 9/23/2024 4:34 PM, Vittorio Giovara wrote:
> Should we schedule deprecation for one of the two fields? I agree it's
> confusing for end users to check in two fields.
Warning: Hot take.
IMO r_frame_rate does more harm than good and should be nuked. Possibly
avg_frame_rate should also be nuked,
On 9/24/2024 12:27 AM, Michael Niedermayer wrote:
> An "average" is precissely one number (once the type of average is defined)
> Maybe you are thinkin of "approximate" instead of "average"
Which doesn't actually represent how it is set usually. Take one grep around
libavformat/*.c and you'll see
On 9/23/2024 3:36 PM, Devon Sookhoo wrote:
> I'm interested in implementing uncompressed MP4 parsing according to the
> newly released ISO/IEC 23001-17:2024. Would anyone be interested in further
> discussing this with me?
Since, as far as I am aware, there are no official (or unofficial) test vec
On 9/23/2024 1:40 PM, Ramiro Polla wrote:
> {
> +#if 0
> int cpu_flags = av_get_cpu_flags();
Are these '#if 0' throughout this patch intended?
- Derek
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg
On 8/31/2024 5:31 PM, James Almer wrote:
> Signed-off-by: James Almer
> ---
> libavcodec/avcodec.c | 2 ++
> libavcodec/avcodec.h | 5 +
> libavcodec/decode.c| 42 +-
> libavcodec/internal.h | 2 ++
> libavcodec/lcevcdec.c |
On 8/31/2024 5:31 PM, James Almer wrote:
> Signed-off-by: James Almer
> ---
> configure | 1 +
> libavcodec/hevc/hevcdec.c | 3 +++
> libavcodec/hevc/refs.c| 15 ++-
> 3 files changed, 18 insertions(+), 1 deletion(-)
Maybe I've misunderstood, but doesn't requiri
On 6/24/2024 1:13 AM, James Almer wrote:
> If Derek is also ok with this then LGTM.
I do not object.
- Derek
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or ema
On 6/23/2024 12:05 PM, Derek Buitenhuis wrote:
> If I sound grumpy, it's because I am... the set sat commentless.
The tone was unnecessary, sorry about that.
- Derek
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org
On 6/22/2024 9:11 PM, Lynne via ffmpeg-devel wrote:
> The API was committed 2 days ago, so changing these fields now
> is within the realms of acceptable.
> ---
You also had weeks to comment on 3 revisions of the set, and it would
have been nice to hear about this then instead of changing it after
On 6/18/2024 7:34 PM, James Almer wrote:
> nit: These three could be combined into a single av_log call.
v2 sent.
- Derek
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link
Signed-off-by: Derek Buitenhuis
---
libavformat/dump.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/libavformat/dump.c b/libavformat/dump.c
index 059fb84522..61a2c6a29f 100644
--- a/libavformat/dump.c
+++ b/libavformat/dump.c
@@ -259,7 +259,16 @@ static void
Signed-off-by: Derek Buitenhuis
---
As requested by James.
---
libavformat/dump.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/libavformat/dump.c b/libavformat/dump.c
index 059fb84522..8e8b9e1959 100644
--- a/libavformat/dump.c
+++ b/libavformat/dump.c
@@ -260,6 +260,15 @@ static
On 6/17/2024 8:20 PM, Derek Buitenhuis wrote:
> 12 files changed, 490 insertions(+), 1 deletion(-)
Will push later today if there are no objections.
- Derek
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listi
On 6/17/2024 9:33 PM, James Almer wrote:
> Personally I'd say yes, but other similar lavu APIs (Mastering, Ambient
> Viewing) don't seem to bother with it, so maybe just leave it as 0
> unless someone else has a strong opinion about it.
I'll leave it for consistency then.
- Derek
__
On 6/17/2024 9:07 PM, James Almer wrote:
> nit: { 0, 1 }.
If we set it to 0, 1 here, should it be set to that in the alloc function too?
It'll be 0, 0 at alloc time due to use of av_mallocz.
- Derek
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
On 6/17/2024 9:03 PM, James Almer wrote:
> Missing APIChanges entry (no need to resend, you can just amend before
> pushing).
Done locally for this and previous commit.
- Derek
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/ma
These boxes are created by the Apple Vision Pro and the iPhone 15+ when
capture for the Vision Pro is enabled.
Based off of the swift API:
*
https://developer.apple.com/documentation/coremedia/kcmformatdescriptionextension_horizontalfieldofview
Signed-off-by: Derek Buitenhuis
*
https://developer.apple.com/documentation/videotoolbox/kvtcompressionpropertykey_heroeye
Signed-off-by: Derek Buitenhuis
---
libavformat/mov.c | 283 ++
1 file changed, 283 insertions(+)
diff --git a/libavformat/mov.c b/libavformat/mov.c
index 9016cd5ad0
Signed-off-by: Derek Buitenhuis
---
fftools/ffprobe.c| 8
tests/ref/fate/matroska-spherical-mono | 2 ++
tests/ref/fate/matroska-spherical-mono-remux | 4
tests/ref/fate/matroska-stereo_mode | 8
tests/ref/fate/matroska-vp8-alpha
://developer.apple.com/documentation/videotoolbox/kvtcompressionpropertykey_horizontaldisparityadjustment
*
https://developer.apple.com/documentation/coremedia/kcmformatdescriptionextension_horizontalfieldofview
Signed-off-by: Derek Buitenhuis
---
libavutil/stereo3d.c | 52
These originate from the Apple Vision Pro, and are documented here:
https://developer.apple.com/documentation/coremedia/cmprojectiontype
Signed-off-by: Derek Buitenhuis
---
libavutil/spherical.c | 5 +
libavutil/spherical.h | 16
libavutil/version.h | 2 +-
3 files
Changes since v2:
* horizontal display adjustment is now a rational
Derek Buitenhuis (5):
avutil/spherical: Add more spherical types
avutil/stereo3d: Fill out stereo info provided by Vision Pro files
fftools/ffprobe: Print more Stereo 3D info from side data
avformat/mov: Add support for
On 6/17/2024 7:09 PM, James Almer wrote:
> No, it's av_d2q(), av_q2d(), and av_rescale() as needed. Same as we do
> for Mastering Display and Ambient Viewing Environment Metadata.
> The reason to use AVRational is that in this specific spec the values
> have a denominator of 1, but in others
On 6/17/2024 5:53 PM, James Almer wrote:
> Maybe this should be an AVRational then.
While that is probably 'more correct', it does mean that in 100% places
this could be used, it'll have to be converted back to the -1 to 1
range. Is there a simple way to do that with an AVRational that doe
On 6/17/2024 2:41 PM, Derek Buitenhuis wrote:
> Signed-off-by: Derek Buitenhuis
> ---
> libavformat/mov.c | 279 ++
> 1 file changed, 279 insertions(+)
Replaced by v3.
- Derek
___
ffmpeg-devel
*
https://developer.apple.com/documentation/videotoolbox/kvtcompressionpropertykey_heroeye
Signed-off-by: Derek Buitenhuis
---
Only difference from v2 is s/RECTANGULAR/RECTILINEAR/.
---
libavformat/mov.c | 279 ++
1 file changed, 279 insertions(+)
diff
These boxes are created by the Apple Vision Pro and the iPhone 15+ when
capture for the Vision Pro is enabled.
Based off of the swift API:
*
https://developer.apple.com/documentation/coremedia/kcmformatdescriptionextension_horizontalfieldofview
Signed-off-by: Derek Buitenhuis
*
https://developer.apple.com/documentation/videotoolbox/kvtcompressionpropertykey_heroeye
Signed-off-by: Derek Buitenhuis
---
libavformat/mov.c | 279 ++
1 file changed, 279 insertions(+)
diff --git a/libavformat/mov.c b/libavformat/mov.c
index 9016cd5ad0
Signed-off-by: Derek Buitenhuis
---
fftools/ffprobe.c| 8
tests/ref/fate/matroska-spherical-mono | 2 ++
tests/ref/fate/matroska-spherical-mono-remux | 4
tests/ref/fate/matroska-stereo_mode | 8
tests/ref/fate/matroska-vp8-alpha
://developer.apple.com/documentation/videotoolbox/kvtcompressionpropertykey_horizontaldisparityadjustment
*
https://developer.apple.com/documentation/coremedia/kcmformatdescriptionextension_horizontalfieldofview
Signed-off-by: Derek Buitenhuis
---
libavutil/stereo3d.c | 52
These originate from the Apple Vision Pro, and are documented here:
https://developer.apple.com/documentation/coremedia/cmprojectiontype
Signed-off-by: Derek Buitenhuis
---
libavutil/spherical.c | 5 +
libavutil/spherical.h | 16
libavutil/version.h | 2 +-
3 files
* All comments applied from previous review.
* Renamed rectangular to more industry standard rectilinear.
Derek Buitenhuis (5):
avutil/spherical: Add more spherical types
avutil/stereo3d: Fill out stereo info provided by Vision Pro files
fftools/ffprobe: Print more Stereo 3D info from side
On 6/14/2024 2:03 PM, Derek Buitenhuis wrote:
> I think setting it to 0 (AV_STEREO3D_2D) is correct rather than this (and is
> already
> done), and I don't think we need to reorder.
>
> I had discussed this with Vittorio and it was decided that it was good to
> disambi
On 6/11/2024 7:43 PM, Derek Buitenhuis wrote:
> Perhaps if type!=2D?
Changed locally to this and updated the test.
- Derek
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, vi
On 6/11/2024 7:44 PM, James Almer wrote:
> This should ideally be the enum with value 0, but until next major when
> such a change can happen, it would be IMO a good idea if you set
> spherical->projection to AV_SPHERICAL_RECTANGULAR in av_spherical_alloc().
I think setting it to 0 (AV_STEREO3D_
On 6/11/2024 7:09 PM, Michael Niedermayer wrote:
> side_data_type=Stereo 3D
> type=2D
> inverted=0
> +view=packed
> +primary_eye=none
Hmm. This does make me think we need a better way to print 'view' and
'inverted' in
FFprobe. Perhaps if type!=2D?
- Derek
On 6/10/2024 8:38 PM, James Almer wrote:
>> +remaining = atom.size;
>> +while (remaining > 0) {
>
> Maybe this loop should call mov_read_default, with proj and eyes added
> to mov_default_parse_table[]. Although i don't know if eyes may show up
> as child for other parent boxes or not.
>
These boxes are created by the Apple Vision Pro and the iPhone 15+ when
capture for the Vision Pro is enabled.
Based off of the swift API:
*
https://developer.apple.com/documentation/coremedia/kcmformatdescriptionextension_horizontalfieldofview
Signed-off-by: Derek Buitenhuis
*
https://developer.apple.com/documentation/videotoolbox/kvtcompressionpropertykey_heroeye
Signed-off-by: Derek Buitenhuis
---
libavformat/mov.c | 279 ++
1 file changed, 279 insertions(+)
diff --git a/libavformat/mov.c b/libavformat/mov.c
index 160e9626d7
Signed-off-by: Derek Buitenhuis
---
fftools/ffprobe.c | 8
1 file changed, 8 insertions(+)
diff --git a/fftools/ffprobe.c b/fftools/ffprobe.c
index 2d38e5dfdc..082cec8a64 100644
--- a/fftools/ffprobe.c
+++ b/fftools/ffprobe.c
@@ -2544,6 +2544,14 @@ static void print_pkt_side_data
://developer.apple.com/documentation/videotoolbox/kvtcompressionpropertykey_horizontaldisparityadjustment
*
https://developer.apple.com/documentation/coremedia/kcmformatdescriptionextension_horizontalfieldofview
Signed-off-by: Derek Buitenhuis
---
libavutil/stereo3d.c | 52
These originate from the Apple Vision Pro, and are documented here:
https://developer.apple.com/documentation/coremedia/cmprojectiontype
Signed-off-by: Derek Buitenhuis
---
libavutil/spherical.c | 3 +++
libavutil/spherical.h | 16
2 files changed, 19 insertions(+)
diff
* I like the idea that the 'dadj' box sits inside a 'cmfy' box, it seems very
wholesome.
[1] https://developer.apple.com/av-foundation/HEVC-Stereo-Video-Profile.pdf
Derek Buitenhuis (5):
avutil/spherical: Add more spherical types
avutil/stereo3d: Fill out stereo info
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
ffmpeg-d
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
https://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
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
ffmpeg-d
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 maybe
, 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 no
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
h
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.
- Der
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
ffmpeg-de
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 5
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 a
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
--- a
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(-)
di
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
d use 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/325
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 l
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
--- a
1 - 100 of 1045 matches
Mail list logo
