Hi everyone I intend to create the release/8.0 branch in the next 1-2 weeks after that i intend to make teh 8.0 release in the following 1-2 weeks If theres something you want in it make sure its pushed before the branch is made. And if theres a bugfix that you want included make sure it either hits master before the branch point or cherry pick it into release/8.0 before the release Also name ideas as always are welcome, will choose teh one with most votes. If theres a tie, i plan to vote last so i can break ties thx -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The real ebay dictionary, page 1 "Used only once" - "Some unspecified defect prevented a second use" "In good condition" - "Can be repaird by experienced expert" "As is" - "You wouldnt want it even if you were payed for it, if you knew ..."
On 23/07/2025 13:43, Michael Niedermayer wrote:
Hi everyone
I intend to create the release/8.0 branch in the next 1-2 weeks after that i intend to make teh 8.0 release in the following 1-2 weeks
If theres something you want in it make sure its pushed before the branch is made.
Would it be sensible to enable tls verify by default with 8.0? Or would that have to go through a longer "deprecation" period? We've just added proper verification support to openssl, schannel and other backends already had it. It's just default-disabled for some reason. IMO it'd make sense to turn it on by default, it has surprised me and other people in the past that FFmpeg does not verify TLS certificates in any way by default.
On Wed, Jul 23, 2025 at 03:45:28PM +0200, Timo Rothenpieler wrote:
On 23/07/2025 13:43, Michael Niedermayer wrote:
Hi everyone
I intend to create the release/8.0 branch in the next 1-2 weeks after that i intend to make teh 8.0 release in the following 1-2 weeks
If theres something you want in it make sure its pushed before the branch is made.
Would it be sensible to enable tls verify by default with 8.0? Or would that have to go through a longer "deprecation" period?
We've just added proper verification support to openssl, schannel and other backends already had it. It's just default-disabled for some reason. IMO it'd make sense to turn it on by default, it has surprised me and other people in the past that FFmpeg does not verify TLS certificates in any way by default.
Is there some disadvantage ? if not i would suggest to enable it thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB What is kyc? Its a tool that makes you give out your real ID, while criminals give out a forged ID card.
On 23 Jul 2025, at 18:27, Michael Niedermayer <michael@niedermayer.cc> wrote:
On Wed, Jul 23, 2025 at 03:45:28PM +0200, Timo Rothenpieler wrote:
On 23/07/2025 13:43, Michael Niedermayer wrote:
Hi everyone
I intend to create the release/8.0 branch in the next 1-2 weeks after that i intend to make teh 8.0 release in the following 1-2 weeks
If theres something you want in it make sure its pushed before the branch is made.
Would it be sensible to enable tls verify by default with 8.0? Or would that have to go through a longer "deprecation" period?
We've just added proper verification support to openssl, schannel and other backends already had it. It's just default-disabled for some reason. IMO it'd make sense to turn it on by default, it has surprised me and other people in the past that FFmpeg does not verify TLS certificates in any way by default.
Is there some disadvantage ?
if not i would suggest to enable it
As long as there is a command line option to disable checking, it should be a good default. There are many sites out there with badly configured certificates, or self-signed ones, which would no longer work, otherwise. -Dimitry
On Wed, Jul 23, 2025 at 06:43:51PM +0200, Dimitry Andric wrote:
On 23 Jul 2025, at 18:27, Michael Niedermayer <michael@niedermayer.cc> wrote:
On Wed, Jul 23, 2025 at 03:45:28PM +0200, Timo Rothenpieler wrote:
On 23/07/2025 13:43, Michael Niedermayer wrote:
Hi everyone
I intend to create the release/8.0 branch in the next 1-2 weeks after that i intend to make teh 8.0 release in the following 1-2 weeks
If theres something you want in it make sure its pushed before the branch is made.
Would it be sensible to enable tls verify by default with 8.0? Or would that have to go through a longer "deprecation" period?
We've just added proper verification support to openssl, schannel and other backends already had it. It's just default-disabled for some reason. IMO it'd make sense to turn it on by default, it has surprised me and other people in the past that FFmpeg does not verify TLS certificates in any way by default.
Is there some disadvantage ?
if not i would suggest to enable it
As long as there is a command line option to disable checking, it should be a good default.
There are many sites out there with badly configured certificates, or self-signed ones, which would no longer work, otherwise.
the fix for this is to check crt.sh example: https://crt.sh/?q=ffmpeg.org and if there are or where correct certificates, reject the self signed one otherwise allow self signed by default with a warning thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Everything should be made as simple as possible, but not simpler. -- Albert Einstein
On July 23, 2025 10:48:51 AM PDT, Michael Niedermayer <michael@niedermayer.cc> wrote:
On Wed, Jul 23, 2025 at 06:43:51PM +0200, Dimitry Andric wrote:
As long as there is a command line option to disable checking, it should be a good default.
There are many sites out there with badly configured certificates, or self-signed ones, which would no longer work, otherwise.
agreed.
the fix for this is to check crt.sh
please do not make ffmpeg access other websites by default for privacy reasons. Jacob
On Wed, Jul 23, 2025 at 11:19:57AM -0700, Jacob Lifshay wrote:
On July 23, 2025 10:48:51 AM PDT, Michael Niedermayer <michael@niedermayer.cc> wrote:
On Wed, Jul 23, 2025 at 06:43:51PM +0200, Dimitry Andric wrote:
As long as there is a command line option to disable checking, it should be a good default.
There are many sites out there with badly configured certificates, or self-signed ones, which would no longer work, otherwise.
agreed.
the fix for this is to check crt.sh
please do not make ffmpeg access other websites by default for privacy reasons.
I understand and agree to this concern. thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB If one takes all money from those who grow wealth and gives it to those who do not grow wealth, 10 years later, almost the same people who where wealthy will be wealthy again, the same people who where poor will be poor again.
Michael Niedermayer (HE12025-07-23):
the fix for this is to check crt.sh
example: https://crt.sh/?q=ffmpeg.org
and if there are or where correct certificates, reject the self signed one otherwise allow self signed by default with a warning
“502 Bad Gateway” I doubt it can be a fix for anything. Anyway, that cannot be a fix: - the site could get compromised; - our users might not trust them; - the site could be down; - internet access might not be available; - the extra latency might be unacceptable; - … And it is our users' absolute right to access sites with self-signed or invalid certificate, starting with sites they operate themselves in test environments, without the say-so of any other site. Can somebody confirm there is an option to disable certificate checks (or at least turns them into a warning) that can be set by the caller for every protocol that ends in TLS? If not, that feature is not ready to be enabled by default. Also, I would prefer if there were at least one release cycle where the checks are done but not fatal, to let users adapt in their own time. Regards, -- Nicolas George
On Wed, Jul 23, 2025 at 08:40:22PM +0200, Nicolas George wrote:
Michael Niedermayer (HE12025-07-23):
the fix for this is to check crt.sh
example: https://crt.sh/?q=ffmpeg.org
and if there are or where correct certificates, reject the self signed one otherwise allow self signed by default with a warning
“502 Bad Gateway”
there are others like https://osint.sh/crt/
I doubt it can be a fix for anything.
Anyway, that cannot be a fix:
- the site could get compromised;
I think modifying these logs in an undetectable way is cryptographically not simple https://certificate.transparency.dev/howctworks/
- our users might not trust them;
The "Certificate Transparency" ? there should be no trust involved here. Its just an append only log of all certificates If you meant that the user might not trust a self signed certificate, even if there never was a better certificate, then the user cannot access the url in question if thats the only certificate the target url provides
- the site could be down;
thats detectable and then no self signed certificate would be accepted by default
- internet access might not be available;
thats detectable and then no self signed certificate would be accepted by default
- the extra latency might be unacceptable;
agree but note, this was a somewhat hypothetical suggestion. I think its an interresting idea. I dont expect anyone is going to just implement it like this. The shit performance of these public sites is one problem that would need to be solved first
- …
And it is our users' absolute right to access sites with self-signed or invalid certificate, starting with sites they operate themselves in test environments, without the say-so of any other site.
agree but that should not be default for a https url. People today expect https to be secure thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Whats the most studid thing your enemy could do ? Blow himself up Whats the most studid thing you could do ? Give up your rights and freedom because your enemy blew himself up.
On Wed, 23 Jul 2025 13:43:43 +0200 Michael Niedermayer <michael@niedermayer.cc> wrote:
Hi everyone
I intend to create the release/8.0 branch in the next 1-2 weeks after that i intend to make teh 8.0 release in the following 1-2 weeks
If theres something you want in it make sure its pushed before the branch is made.
And if theres a bugfix that you want included make sure it either hits master before the branch point or cherry pick it into release/8.0 before the release
Also name ideas as always are welcome, will choose teh one with most votes. If theres a tie, i plan to vote last so i can break ties
When can we formally remove YUV pixel formats? As far as I'm aware, nothing is blocking this, we just need to break the ABI for it. When is the best time to do that?
thx
-- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
The real ebay dictionary, page 1 "Used only once" - "Some unspecified defect prevented a second use" "In good condition" - "Can be repaird by experienced expert" "As is" - "You wouldnt want it even if you were payed for it, if you knew ..." _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".
On Wed, 23 Jul 2025 16:01:14 +0200 Niklas Haas <ffmpeg@haasn.xyz> wrote:
On Wed, 23 Jul 2025 13:43:43 +0200 Michael Niedermayer <michael@niedermayer.cc> wrote:
Hi everyone
I intend to create the release/8.0 branch in the next 1-2 weeks after that i intend to make teh 8.0 release in the following 1-2 weeks
If theres something you want in it make sure its pushed before the branch is made.
And if theres a bugfix that you want included make sure it either hits master before the branch point or cherry pick it into release/8.0 before the release
Also name ideas as always are welcome, will choose teh one with most votes. If theres a tie, i plan to vote last so i can break ties
When can we formally remove YUV pixel formats?
I of course meant to write YUVJ, although formally removing YUV would make our lives easier too.
As far as I'm aware, nothing is blocking this, we just need to break the ABI for it. When is the best time to do that?
thx
-- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
The real ebay dictionary, page 1 "Used only once" - "Some unspecified defect prevented a second use" "In good condition" - "Can be repaird by experienced expert" "As is" - "You wouldnt want it even if you were payed for it, if you knew ..." _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".
On 7/23/2025 11:01 AM, Niklas Haas wrote:
On Wed, 23 Jul 2025 16:01:14 +0200 Niklas Haas <ffmpeg@haasn.xyz> wrote:
On Wed, 23 Jul 2025 13:43:43 +0200 Michael Niedermayer <michael@niedermayer.cc> wrote:
Hi everyone
I intend to create the release/8.0 branch in the next 1-2 weeks after that i intend to make teh 8.0 release in the following 1-2 weeks
If theres something you want in it make sure its pushed before the branch is made.
And if theres a bugfix that you want included make sure it either hits master before the branch point or cherry pick it into release/8.0 before the release
Also name ideas as always are welcome, will choose teh one with most votes. If theres a tie, i plan to vote last so i can break ties
When can we formally remove YUV pixel formats?
It's an ABI break, so when we bump major soname, which we'd do early next year.
I of course meant to write YUVJ, although formally removing YUV would make our lives easier too.
How so?
As far as I'm aware, nothing is blocking this, we just need to break the ABI for it. When is the best time to do that?
thx
-- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
The real ebay dictionary, page 1 "Used only once" - "Some unspecified defect prevented a second use" "In good condition" - "Can be repaird by experienced expert" "As is" - "You wouldnt want it even if you were payed for it, if you knew ..." _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email ffmpeg-devel-request@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-request@ffmpeg.org with subject "unsubscribe".
ср, 23 июл. 2025 г., 14:43 Michael Niedermayer <michael@niedermayer.cc>:
Hi everyone
Hi. I still wish you put some time in making more accurate web changelog, with detailed (with git commit links) API changes, and new/closed bugs and regressions since last release (a bit like wine project does this part for example). -rc tarball is also much hoped for by me, at least.
I intend to create the release/8.0 branch in the next 1-2 weeks after that i intend to make teh 8.0 release in the following 1-2 weeks
If theres something you want in it make sure its pushed before the branch is made.
And if theres a bugfix that you want included make sure it either hits master before the branch point or cherry pick it into release/8.0 before the release
Also name ideas as always are welcome, will choose teh one with most votes. If theres a tie, i plan to vote last so i can break ties
thx
-- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
The real ebay dictionary, page 1 "Used only once" - "Some unspecified defect prevented a second use" "In good condition" - "Can be repaird by experienced expert" "As is" - "You wouldnt want it even if you were payed for it, if you knew ..." _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".
Hi Andrew On Fri, Jul 25, 2025 at 06:34:53PM +0300, Andrew Randrianasulu wrote:
ср, 23 июл. 2025 г., 14:43 Michael Niedermayer <michael@niedermayer.cc>:
Hi everyone
Hi.
I still wish you put some time in making more accurate web changelog, with detailed (with git commit links) API changes, and new/closed bugs and regressions since last release (a bit like wine project does this part for example).
You are welcome to write a better changelog and submit a patch the website git is here: https://git.ffmpeg.org/ffmpeg-web You are also welcom to do that for every future release if this is something you want to do.
-rc tarball is also much hoped for by me, at least.
you can just grab git master or git release/X.Y before the release thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Asymptotically faster algorithms should always be preferred if you have asymptotical amounts of data
On 7/23/2025 12:43 PM, Michael Niedermayer wrote:
Also name ideas as always are welcome, will choose teh one with most votes. If theres a tie, i plan to vote last so i can break ties
Eckart (Carl Eckart) - Derek
On July 23, 2025 4:43:43 AM PDT, Michael Niedermayer <michael@niedermayer.cc> wrote:
Hi everyone
I intend to create the release/8.0 branch in the next 1-2 weeks after that i intend to make teh 8.0 release in the following 1-2 weeks
If theres something you want in it make sure its pushed before the branch is made.
I'm expecting https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/20024 to be merged soon since all the review comments were resolved on Wednesday. Can you (or someone else) please merge that before creating the release/8.0 branch? Of course that's all assuming there aren't any more review issues that need to be resolved. Thanks, Jacob
Hi On Fri, Aug 01, 2025 at 03:17:48PM -0700, Jacob Lifshay wrote:
On July 23, 2025 4:43:43 AM PDT, Michael Niedermayer <michael@niedermayer.cc> wrote:
Hi everyone
I intend to create the release/8.0 branch in the next 1-2 weeks after that i intend to make teh 8.0 release in the following 1-2 weeks
If theres something you want in it make sure its pushed before the branch is made.
I'm expecting https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/20024 to be merged soon since all the review comments were resolved on Wednesday. Can you (or someone else) please merge that before creating the release/8.0 branch? Of course that's all assuming there aren't any more review issues that need to be resolved.
pr/20024 is in release/8.0 If you want, please send a patch to add yourself to .forgejo/CODEOWNERS and MAINTAINERS thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB I have never wished to cater to the crowd; for what I know they do not approve, and what they approve I do not know. -- Epicurus
Le mer. 23 juil. 2025 à 06:43, Michael Niedermayer <michael@niedermayer.cc> a écrit :
Hi everyone
I intend to create the release/8.0 branch in the next 1-2 weeks after that i intend to make teh 8.0 release in the following 1-2 weeks
If theres something you want in it make sure its pushed before the branch is made.
I would like to mention https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/20026 as well. It is a redo of one patch from a longer series that took me a long time to get in. This one was done in close coordination with developers and I've been surprised at how hard it's been to get a review of it since I really worked diligently to apply all recommendations. It is also blocking the rest of the work pending to get ffmpeg to finally properly support ogg bitstreams which would be a fantastic and much welcome improvement. Thanks for y'all hard work. -- Romain
And if theres a bugfix that you want included make sure it either hits master before the branch point or cherry pick it into release/8.0 before the release
Also name ideas as always are welcome, will choose teh one with most votes. If theres a tie, i plan to vote last so i can break ties
thx
-- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
The real ebay dictionary, page 1 "Used only once" - "Some unspecified defect prevented a second use" "In good condition" - "Can be repaird by experienced expert" "As is" - "You wouldnt want it even if you were payed for it, if you knew ..." _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".
Hi all On Fri, Aug 01, 2025 at 06:16:18PM -0500, Romain Beauxis wrote:
Le mer. 23 juil. 2025 à 06:43, Michael Niedermayer <michael@niedermayer.cc> a écrit :
Hi everyone
I intend to create the release/8.0 branch in the next 1-2 weeks after that i intend to make teh 8.0 release in the following 1-2 weeks
If theres something you want in it make sure its pushed before the branch is made.
I would like to mention https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/20026 as well.
I intend to make the release in the nest 24-48h so if nothing delays this, then thats as long as theres left to make any changes to 8.0 thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Awnsering whenever a program halts or runs forever is On a turing machine, in general impossible (turings halting problem). On any real computer, always possible as a real computer has a finite number of states N, and will either halt in less than N cycles or never halt.
On 20/08/2025 06:13, Michael Niedermayer via ffmpeg-devel wrote:
Hi all
On Fri, Aug 01, 2025 at 06:16:18PM -0500, Romain Beauxis wrote:
Le mer. 23 juil. 2025 à 06:43, Michael Niedermayer <michael@niedermayer.cc> a écrit :
Hi everyone
I intend to create the release/8.0 branch in the next 1-2 weeks after that i intend to make teh 8.0 release in the following 1-2 weeks
If theres something you want in it make sure its pushed before the branch is made.
I would like to mention https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/20026 as well.
I intend to make the release in the nest 24-48h so if nothing delays this, then thats as long as theres left to make any changes to 8.0
I'll write up a blog post as usual. It'll be quite long this time, as I'd like to mention in detail the work on Vulkan accelerated decoding and encoding, so if possible, I'd like to get the full 48 hours.
Hi On Wed, Aug 20, 2025 at 10:18:20AM +0900, Lynne via ffmpeg-devel wrote:
On 20/08/2025 06:13, Michael Niedermayer via ffmpeg-devel wrote:
Hi all
On Fri, Aug 01, 2025 at 06:16:18PM -0500, Romain Beauxis wrote:
Le mer. 23 juil. 2025 à 06:43, Michael Niedermayer <michael@niedermayer.cc> a écrit :
Hi everyone
I intend to create the release/8.0 branch in the next 1-2 weeks after that i intend to make teh 8.0 release in the following 1-2 weeks
If theres something you want in it make sure its pushed before the branch is made.
I would like to mention https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/20026 as well.
I intend to make the release in the nest 24-48h so if nothing delays this, then thats as long as theres left to make any changes to 8.0
I'll write up a blog post as usual.
It'll be quite long this time, as I'd like to mention in detail the work on Vulkan accelerated decoding and encoding, so if possible, I'd like to get the full 48 hours.
ok thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB It is dangerous to be right in matters on which the established authorities are wrong. -- Voltaire
On Tue, 19 Aug 2025 at 23:13, Michael Niedermayer via ffmpeg-devel <ffmpeg-devel@ffmpeg.org> wrote:
Hi all
On Fri, Aug 01, 2025 at 06:16:18PM -0500, Romain Beauxis wrote:
Le mer. 23 juil. 2025 à 06:43, Michael Niedermayer <michael@niedermayer.cc> a écrit :
Hi everyone
I intend to create the release/8.0 branch in the next 1-2 weeks after that i intend to make teh 8.0 release in the following 1-2 weeks
If theres something you want in it make sure its pushed before the branch is made.
I would like to mention https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/20026 as well.
I intend to make the release in the nest 24-48h so if nothing delays this, then thats as long as theres left to make any changes to 8.0
Hi Michael, Not sure if it's too late, but could you also backport 5ff2500514a0224b7c2822d3b4e950b473f5bcff before release. I could do it too, but I'm not sure I'm not late. Thanks, Kacper
On Wed, 23 Jul 2025 13:43:43 +0200 Michael Niedermayer <michael@niedermayer.cc> wrote:
Hi everyone
I intend to create the release/8.0 branch in the next 1-2 weeks after that i intend to make teh 8.0 release in the following 1-2 weeks
If theres something you want in it make sure its pushed before the branch is made.
I would like to merge the AVFrame.alpha_mode series as well. I am currently working on a v3 that also adds some more use cases for it. (Specifically, to the vf_overlay filter), but I will push it before the end of the day; or else tomorrow.
And if theres a bugfix that you want included make sure it either hits master before the branch point or cherry pick it into release/8.0 before the release
Also name ideas as always are welcome, will choose teh one with most votes. If theres a tie, i plan to vote last so i can break ties
thx
-- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
The real ebay dictionary, page 1 "Used only once" - "Some unspecified defect prevented a second use" "In good condition" - "Can be repaird by experienced expert" "As is" - "You wouldnt want it even if you were payed for it, if you knew ..." _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".
Niklas Haas (HE12025-08-02):
I would like to merge the AVFrame.alpha_mode series as well.
Bad idea. This kind of feature affecting the whole code should stay in the master branch for a while before being enshrined in a release. Regards, -- Nicolas George
It would be nice if pull request https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/20059 could be discussed, and either rejected or approved before a 8.0 release is made. That PR proposes to change the default value for "apply_cropping" (which was introduced in 7.1). Regards, Tobias
Tobias Rapp (HE12025-08-04):
It would be nice if pull request https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/20059 could be discussed, and either rejected or approved before a 8.0 release is made.
That PR proposes to change the default value for "apply_cropping" (which was introduced in 7.1).
Dissenting opinion: non-trivial things that were just applied should not go into the release. They will go into the next, unless they get changed again. Regards, -- Nicolas George
Hi, There is an ongoing FATE failure on RISC-V. I can try to address it by the end of *next* week but not right now.
On Wed, Aug 06, 2025 at 12:47:04PM +0700, Rémi Denis-Courmont wrote:
Hi,
There is an ongoing FATE failure on RISC-V. I can try to address it by the end of *next* week but not right now.
risc-v looks mostly green on fate, am i missing something ? [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Many things microsoft did are stupid, but not doing something just because microsoft did it is even more stupid. If everything ms did were stupid they would be bankrupt already.
Le perjantaina 8. elokuuta 2025, 19.45.35 Itä-Euroopan kesäaika Michael Niedermayer a écrit :
On Wed, Aug 06, 2025 at 12:47:04PM +0700, Rémi Denis-Courmont wrote:
Hi,
There is an ongoing FATE failure on RISC-V. I can try to address it by the end of *next* week but not right now. risc-v looks mostly green on fate, am i missing something ?
The RVA20 lines are green, but the V line is yellow. -- ヅニ-クーモン・レミ Tapio's place new town, former Finnish Republic of Uusimaa
On Wed, Jul 23, 2025 at 01:43:43PM +0200, Michael Niedermayer wrote:
Hi everyone
I intend to create the release/8.0 branch in the next 1-2 weeks
I intend to make the branch later today (EU time) or tomorrow Fixes can then still be backported for the next 1-2 weeks before release [...] -- 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
Hi Michael Le ven. 8 août 2025 à 11:43, Michael Niedermayer <michael@niedermayer.cc> a écrit :
On Wed, Jul 23, 2025 at 01:43:43PM +0200, Michael Niedermayer wrote:
Hi everyone
I intend to create the release/8.0 branch in the next 1-2 weeks
I intend to make the branch later today (EU time) or tomorrow Fixes can then still be backported for the next 1-2 weeks before release
Friendly reminder that your review uncovered a missing API bump due to libavf changing its bitstream on ogg/opus and ogg/flac streams. I have incorporated the API bump in the PR you reviewed: https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/20026/files Thanks, -- Romain
[...]
-- 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 _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".
participants (14)
-
Andrew Randrianasulu -
Derek Buitenhuis -
Dimitry Andric -
Jacob Lifshay -
James Almer -
Kacper Michajlow -
Lynne -
Michael Niedermayer -
Nicolas George -
Niklas Haas -
Romain Beauxis -
Rémi Denis-Courmont -
Timo Rothenpieler -
Tobias Rapp