[FFmpeg-devel] Re: [RFC] C++

[FFmpeg-devel] Re: [RFC] C++

[Zhao Zhili via ffmpeg-devel]


> 在 2025年10月21日，上午1:50，Tomas Härdin via ffmpeg-devel <ffmpeg-devel@ffmpeg.org> 写道：
> 
> Hi
> 
> I'm writing this email to get a feel for how everyone feels about
> making more use of C++ in the codebase. I am only proposing using C++
> *internally*, and only where it makes sense. I am not suggesting a
> "move" to C++, merely using features already present in the compilers
> we target: gcc, clang and cl. The impedance mismatch should therefore
> be small, and any missing compiler features should be caught by FATE.
> 
> Currently C++ use is quite limited in this project, but I see no reason
> why this should be the case. doc/faq.texi makes mention of Linux'
> reasons for avoiding C++, but FFmpeg is not Linux. For us ABI stability
> and performance are the biggest issues. Stability can be ensured by
> sticking with C for the API and disabling exceptions (or marking
> relevant functions as noexcept). Performance may benefit in some cases.
> This would have to be tested. Again, the most performance critical
> parts can be kept as C (and asm).
> 
> My main motivation is to be able to use STL, which would simplify
> string handling and memory management, and give us access to its data
> structures. Manual memory management has its place, especially in lavc.
> In lavf less so. RAII would do wonders in de-gotofying error handling.
> Features like std::filesystem, std::chrono, std::thread etc abstract
> away many OS particularities. Thorough STL-ification would render parts
> of lavu obsolete. avstring.*, bprintf.* and tree.* come to mind. This
> would have security benefits. Another reason is stronger typing, which
> tends to reveal bugs.
> 
> I've targeted mxfdec.c as a proof-of-concept. See attached patch, which
> compiles and passes fate-mxf. It is partly inspired by our decklink
> binding. Particularly notable is the ability to resolve MXF structs
> into MXFMetadataSetType at compile time, as well as resolving strong
> references in a more type safe manner. This revealed an issue in
> mxf_parse_structural_metadata() where MXFStructuralComponent* was
> blindly cast to MXFTimecodeComponent*, which could cause code further
> down to interpret the latter as the former, which is a not so obvious
> bug that wouldn't be caught without this stronger typing.
> 
> I've not made use of STL in the attached patch because that requires
> linking with libstdc++, which I couldn't be arsed to do. One practical
> example where STL would come in handy is for my work on segmented
> indexes. Specifically std::map and std::lower_bound. Various tables in
> mxfdec.c could also be targets for turning into std::map or even
> std::unordered_map. A quick experiment with callgrind suggests
> mxf_read_header() might be speed up slightly with such a change.
> 
> Details like which version of C++ to use could be agreed on later if
> people feel this is a good idea. Personally I favor using the most
> recent version that our compiler suite supports. Lately I've been using
> C++20 with icx (Intel's compiler) which has been quite pleasant.

I noticed that the FFmpeg Twitter account posted about this discussion. I believe the discussion should remain within the mailing list.
Please keep in mind that C AND C++ developers make up the largest portion of our user base, although we choose to minimize the use of C++ inside FFmpeg itself.
_______________________________________________
ffmpeg-devel mailing list -- ffmpeg-devel@ffmpeg.org
To unsubscribe send an email to ffmpeg-devel-leave@ffmpeg.org

[FFmpeg-devel] Re: [RFC] C++

[Nicolas George via ffmpeg-devel]

Zhao Zhili via ffmpeg-devel (HE12025-10-21):
> I noticed that the FFmpeg Twitter account posted about this
> discussion. I believe the discussion should remain within the mailing
> list.

Why?

> Please keep in mind that C AND C++ developers make up the largest
> portion of our user base, although we choose to minimize the use of
> C++ inside FFmpeg itself.

Do you have evidence for that surprising statement? Intuitively, I would
say that the ultra-majority of our users do not any programming
language, or maybe some python on high school.

Regards,

-- 
  Nicolas George
_______________________________________________
ffmpeg-devel mailing list -- ffmpeg-devel@ffmpeg.org
To unsubscribe send an email to ffmpeg-devel-leave@ffmpeg.org

[FFmpeg-devel] Re: [RFC] C++

[Zhao Zhili via ffmpeg-devel]

> On Oct 21, 2025, at 22:58, Nicolas George via ffmpeg-devel <ffmpeg-devel@ffmpeg.org> wrote:
> 
> Zhao Zhili via ffmpeg-devel (HE12025-10-21):
>> I noticed that the FFmpeg Twitter account posted about this
>> discussion. I believe the discussion should remain within the mailing
>> list.
> 
> Why?

Using an official account to make fun of a technical discussion makes me
uncomfortable, even if it's not a RFC proposed by me.

> 
>> Please keep in mind that C AND C++ developers make up the largest
>> portion of our user base, although we choose to minimize the use of
>> C++ inside FFmpeg itself.
> 
> Do you have evidence for that surprising statement? Intuitively, I would
> say that the ultra-majority of our users do not any programming
> language, or maybe some python on high school.

You know I'm talking about FFmpeg libs use base.

> 
> Regards,
> 
> -- 
>  Nicolas George
> _______________________________________________
> ffmpeg-devel mailing list -- ffmpeg-devel@ffmpeg.org
> To unsubscribe send an email to ffmpeg-devel-leave@ffmpeg.org

_______________________________________________
ffmpeg-devel mailing list -- ffmpeg-devel@ffmpeg.org
To unsubscribe send an email to ffmpeg-devel-leave@ffmpeg.org

[FFmpeg-devel] Re: [RFC] C++

[Michael Niedermayer via ffmpeg-devel]

[-- Attachment #1.1: Type: text/plain, Size: 929 bytes --]

Hi Zhao Zhili

On Tue, Oct 21, 2025 at 11:31:02PM +0800, Zhao Zhili via ffmpeg-devel wrote:
> 
> 
> > On Oct 21, 2025, at 22:58, Nicolas George via ffmpeg-devel <ffmpeg-devel@ffmpeg.org> wrote:
> > 
> > Zhao Zhili via ffmpeg-devel (HE12025-10-21):
> >> I noticed that the FFmpeg Twitter account posted about this
> >> discussion. I believe the discussion should remain within the mailing
> >> list.
> > 
> > Why?
> 
> Using an official account to make fun of a technical discussion makes me
> uncomfortable, even if it's not a RFC proposed by me.

i agree
I think neutrally/professionally pointing to the RFC, would have been fine

If this sort of stuff happens again, please keep me updated / point me to it

thx

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

It is dangerous to be right in matters on which the established authorities
are wrong. -- Voltaire

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

[-- Attachment #2: Type: text/plain, Size: 163 bytes --]

_______________________________________________
ffmpeg-devel mailing list -- ffmpeg-devel@ffmpeg.org
To unsubscribe send an email to ffmpeg-devel-leave@ffmpeg.org

[FFmpeg-devel] Re: [RFC] C++

[Nicolas George via ffmpeg-devel]

Zhao Zhili via ffmpeg-devel (HE12025-10-21):
> >> I noticed that the FFmpeg Twitter account posted about this
> >> discussion. I believe the discussion should remain within the mailing
> >> list.
> > Why?
> Using an official account to make fun of a technical discussion makes me
> uncomfortable, even if it's not a RFC proposed by me.

That is an argument against using an official account to express
personal opinions. Which I would agree to if we were in a professional
setting, but we are not.

It is not an argument for “remain within the mailing list” altogether.

> > Do you have evidence for that surprising statement? Intuitively, I would
> > say that the ultra-majority of our users do not any programming
> > language, or maybe some python on high school.
> You know I'm talking about FFmpeg libs use base.

No, I do not know that. But if you limit “users” to people who use the
library directly, then obviously the majority will be from the languages
where it is possible to use the library directly. So what?

Regards,

-- 
  Nicolas George
_______________________________________________
ffmpeg-devel mailing list -- ffmpeg-devel@ffmpeg.org
To unsubscribe send an email to ffmpeg-devel-leave@ffmpeg.org

[FFmpeg-devel] Re: [RFC] C++

[Zhao Zhili via ffmpeg-devel]

> On Oct 22, 2025, at 16:11, Nicolas George <george@nsup.org> wrote:
> 
> Zhao Zhili via ffmpeg-devel (HE12025-10-21):
>>>> I noticed that the FFmpeg Twitter account posted about this
>>>> discussion. I believe the discussion should remain within the mailing
>>>> list.
>>> Why?
>> Using an official account to make fun of a technical discussion makes me
>> uncomfortable, even if it's not a RFC proposed by me.
> 
> That is an argument against using an official account to express
> personal opinions. Which I would agree to if we were in a professional
> setting, but we are not.
> 
> 
> It is not an argument for “remain within the mailing list” altogether.
> 
>>> Do you have evidence for that surprising statement? Intuitively, I would
>>> say that the ultra-majority of our users do not any programming
>>> language, or maybe some python on high school.
>> You know I'm talking about FFmpeg libs use base.
> 
> No, I do not know that. But if you limit “users” to people who use the
> library directly, then obviously the majority will be from the languages
> where it is possible to use the library directly. So what?

Everyone has their preferences, and each project makes its own choices, but
we should respect what downstream users’ choice, C, C++, C#, Java, or Javascript.
Mocking a language that is heavily used by downstream users doesn’t make us look
any wiser.

> 
> Regards,
> 
> -- 
>  Nicolas George

_______________________________________________
ffmpeg-devel mailing list -- ffmpeg-devel@ffmpeg.org
To unsubscribe send an email to ffmpeg-devel-leave@ffmpeg.org

[FFmpeg-devel] Re: [RFC] C++

[Michael Niedermayer via ffmpeg-devel]

[-- Attachment #1.1: Type: text/plain, Size: 1340 bytes --]

Hi Tomas

On Thu, Oct 23, 2025 at 11:49:31PM +0200, Tomas Härdin via ffmpeg-devel wrote:
> ons 2025-10-22 klockan 15:05 +0200 skrev Michael Niedermayer via
> ffmpeg-devel:
> > One difference that favors lower level languages is that with
> > high level languages one looses sight of the cost of operations
> > 
> > Teh closer you are to the implementation of a data structure, like
> > if you are on the team of people who developed or maintains it.
> > The more likely you are also aware of its cost or one of the reviewer
> > would spot you doing a O(n^2) operation as if its O(1)
> 
> I'd argue the exact opposite. There are O(N²) spots in the code that
> are entirely the result of using C'isms where STL would have given you
> O(NlogN) basically for free. And where that still isn't enough there's
> std::unordered_met and the like. Complexity guarantees are part of the
> documentation for these types.

First, there are places where O(N²) is faster than O(NlogN)
And there are places where it doesnt matter.

For what remains, please open a issue and put be in the CC, not
saying ill fix em, but iam interrested

thx

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

It is dangerous to be right in matters on which the established authorities
are wrong. -- Voltaire

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

[-- Attachment #2: Type: text/plain, Size: 163 bytes --]

_______________________________________________
ffmpeg-devel mailing list -- ffmpeg-devel@ffmpeg.org
To unsubscribe send an email to ffmpeg-devel-leave@ffmpeg.org

[FFmpeg-devel] Re: [RFC] C++

[Tomas Härdin via ffmpeg-devel]

ons 2025-10-22 klockan 15:05 +0200 skrev Michael Niedermayer via
ffmpeg-devel:
> One difference that favors lower level languages is that with
> high level languages one looses sight of the cost of operations
> 
> Teh closer you are to the implementation of a data structure, like
> if you are on the team of people who developed or maintains it.
> The more likely you are also aware of its cost or one of the reviewer
> would spot you doing a O(n^2) operation as if its O(1)

I'd argue the exact opposite. There are O(N²) spots in the code that
are entirely the result of using C'isms where STL would have given you
O(NlogN) basically for free. And where that still isn't enough there's
std::unordered_met and the like. Complexity guarantees are part of the
documentation for these types.

/Tomas
_______________________________________________
ffmpeg-devel mailing list -- ffmpeg-devel@ffmpeg.org
To unsubscribe send an email to ffmpeg-devel-leave@ffmpeg.org

[FFmpeg-devel] Re: [RFC] C++

[Tomas Härdin via ffmpeg-devel]

ons 2025-10-22 klockan 14:09 +0200 skrev Gregor Riepl via ffmpeg-devel:
> > My main motivation is to be able to use STL, which would simplify
> > string handling and memory management, and give us access to its
> > data
> > structures. Manual memory management has its place, especially in
> > lavc.
> > In lavf less so. RAII would do wonders in de-gotofying error
> > handling.
> > Features like std::filesystem, std::chrono, std::thread etc
> > abstract
> > away many OS particularities. Thorough STL-ification would render
> > parts
> > of lavu obsolete. avstring.*, bprintf.* and tree.* come to mind.
> > This
> > would have security benefits. Another reason is stronger typing,
> > which
> > tends to reveal bugs.
> 
> Just for the sake of the argument: Wouldn't it be better to opt for
> an even safer language than C++, like Rust?

There was a discussion about Rust a while back. I'm not really against
it, but the impedance mismatch is much greater. Plus there's the need
for an entirely different set of compilers. Most of our users know C++
already.

That said, gccrs is making progress so perhaps at some point this might
happen. C++ is still an improvement over the present state of things.
Plus, Katamari-C++ is likely to grow the same kind of features Rust has
anyway.

I've continued to hack at mxfdec.cpp and I'm now seeing substantial
performance improvements thanks to using STL. 182% faster
mxf_read_header for a 10,000 second file generated by mxfenc.c. This is
likely to shoot up even more as I rework the MXFIndexTableSegment code.
Greater still would be the effect of lazy reading of partitions, which
is my overall goal. I'll probably push something to forgejo once it's
firmed up a bit. Especially for Baptiste to take a look at.

I feel I should reiterate the point that whatever we choose to do we
should keep the C API, because C's ABI is stable. C++'s isn't, and
based on what Rémi is saying Rust's isn't either.

/Tomas
_______________________________________________
ffmpeg-devel mailing list -- ffmpeg-devel@ffmpeg.org
To unsubscribe send an email to ffmpeg-devel-leave@ffmpeg.org

[FFmpeg-devel] Re: [RFC] C++

[Rémi Denis-Courmont via ffmpeg-devel]

Le keskiviikkona 22. lokakuuta 2025, 21.12.47 Itä-Euroopan kesäaika Timo 
Rothenpieler via ffmpeg-devel a écrit :
> They allow a distributor to do it centrally, and don't burden it onto 
> every single developer.

And? Neither does Cargo? It does not force developers to pin anything. It's 
*recommended* to pin if (and only if) shipping a final application or OS, 
rather than libraries, i.e. unless you're the distributor.

Obviously someone is going to have to be burdened with checking versions and 
bugs at some point in the supply chain, with the user as the last resort - 
that's true for any programming language.

> > Cargo gives you the *choice* of pinning or not pinning the versions
> > through the lock. FFmpeg should *probably* not pin anything and just
> > specify minimum version requirements. And it'll be the exact same
> > dependency hell that we already have (or don't have - that's subjective)
> > with C. Nothing to see here.
> 
> Given that API stability is far from a given in that world,

It's no more or less stable than C. It is far better than C++ where you need 
to be super careful and bend over backward not to leak object type layouts 
through public headers.

> not pinning  anything does not sound like a good idea.

And yet FFmpeg is not currently pinning any existing dependencies. This has 
nothing to do with using C++ or Rust really.

> I'd rather just not enter that dependency hell at all.

Sure, you do that by not having dependencies. That's an argument against 
external dependencies (which I can get behind), and it is also an argument 
against C++ which requires a runtime even if you don't touch the STL.

By design, you can do C, Rust or a mix of both, without dependencies  - as 
exemplified by the Linux kernel. It's just a matter of project policy. FWIW, 
Rust is actually handling this more consistently and flexibily than C, since it 
provides an intermediate point between freestanding and hosted environment - 
not that FFmpeg supports anything less than a hosted environment.

-- 
ヅニ-クーモン・レミ
Hagalund ny stad, f.d. Finska republik Nylands



_______________________________________________
ffmpeg-devel mailing list -- ffmpeg-devel@ffmpeg.org
To unsubscribe send an email to ffmpeg-devel-leave@ffmpeg.org

[FFmpeg-devel] Re: [RFC] C++

[Timo Rothenpieler via ffmpeg-devel]

[-- Attachment #1.1.1.1: Type: text/plain, Size: 2468 bytes --]

On 22.10.2025 19:07, Rémi Denis-Courmont via ffmpeg-devel wrote:
> Le keskiviikkona 22. lokakuuta 2025, 16.07.36 Itä-Euroopan kesäaika Timo
> Rothenpieler via ffmpeg-devel a écrit :
>> C++ can be used as-is, since it can read all our headers just fine.
> 
> FFmpeg public headers are C++-compatible and, frankly as a C developer, I find
> that annoying. Not sure about Zig, but Rust does not care about your C headers
> and won't require C programmers to muck with their header files to appease
> rustc.
> 
> Or more accurately, it gives you the choice to use or not to use bindgen to
> parse the C headers. And frankly, you are more often than not better off not
> using it.
> 
>> Using anything else needs extensive and constant porting work, that then
>> will also make future iterations of internal APIs much harder if not
>> impossible, forcing people who have zero experience with the other
>> language to learn it, just to enhance the C side of things.
> 
>> Plus, most of these fancy modern languages are not just a programming
>> language, but they also want to play package-manager, which then forces
>> all of its downstream users to babysit a ton of package version, which
>> largely don't give a damn about stable APIs.
> 
> C++ sucks just as badly as Rust to make stable APIs/ABIs. In the end, you end
> up having to expose a C interface, whether you're using C, C++, Zig, Rust or
> anything else. And you'll have to do that forever, since C is the lingua
> franca of system-level programming interfaces.
> 
>> So we then need to constantly monitor all those dependencies for bugs
>> and issues, and potentially a fix for one pulls in breaking API changes,
>> which then need to be addressed and backported.
> 
> FUD much? How exactly do any other language relieve you from the problem of
> tracking bugs in dependencies?

They allow a distributor to do it centrally, and don't burden it onto 
every single developer.

> Cargo gives you the *choice* of pinning or not pinning the versions through
> the lock. FFmpeg should *probably* not pin anything and just specify minimum
> version requirements. And it'll be the exact same dependency hell that we
> already have (or don't have - that's subjective) with C. Nothing to see here.

Given that API stability is far from a given in that world, not pinning 
anything does not sound like a good idea.
I'd rather just not enter that dependency hell at all.

[-- Attachment #1.1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 3203 bytes --]

[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]

[-- Attachment #2: Type: text/plain, Size: 163 bytes --]

_______________________________________________
ffmpeg-devel mailing list -- ffmpeg-devel@ffmpeg.org
To unsubscribe send an email to ffmpeg-devel-leave@ffmpeg.org

[FFmpeg-devel] Re: [RFC] C++

[Rémi Denis-Courmont via ffmpeg-devel]

Le keskiviikkona 22. lokakuuta 2025, 15.09.32 Itä-Euroopan kesäaika Gregor 
Riepl via ffmpeg-devel a écrit :
> > My main motivation is to be able to use STL, which would simplify
> > string handling and memory management, and give us access to its data
> > structures. Manual memory management has its place, especially in lavc.
> > In lavf less so. RAII would do wonders in de-gotofying error handling.
> > Features like std::filesystem, std::chrono, std::thread etc abstract
> > away many OS particularities. Thorough STL-ification would render parts
> > of lavu obsolete. avstring.*, bprintf.* and tree.* come to mind. This
> > would have security benefits. Another reason is stronger typing, which
> > tends to reveal bugs.
> 
> Just for the sake of the argument: Wouldn't it be better to opt for an even
> safer language than C++, like Rust?

Yes. If the goal is to use better abstraction, notably for data structures and 
memory handling, than are possible with C, then Rust provides zero-cost 
abstractions. In C++, you can't do that; for instance, your virtual methods 
may or may not be specialised, and you have no control over it. Also C++ 
provides a lot of abstractions that are nowadays widely considered just *bad*, 
even by C++ advocates, such as multiple inheritance.

Rust also doesn't need its own runtime library, so it would be essentially 
transparent for (binary) downstreams, whether statically or dynamically 
linked. And it's actually easy for experienced C programmers to learn (been 
there, done that).

The static memory safety features are just icing on the cake.

The big difficult is integrating dependency tracking from rustc, compilation 
(rustc or cargo) and linking into an existing build system. But that's a one-
time cost for one motivated person to deal with. Sure, C++ would be much 
easier with respect to that one specific aspect, but so what?

> C++ has received a lot of criticism in being just as memory unsafe as C, and
> I personally think that it adds an epic amount of complexity to writing
> correct code. Although - that may or may not be the case depending on where
> and how it's used in the code base.

+1

-- 
德尼-库尔蒙‧雷米
Tapiolan uusi kaupunki, Uudenmaan entinen Suomen tasavalta



_______________________________________________
ffmpeg-devel mailing list -- ffmpeg-devel@ffmpeg.org
To unsubscribe send an email to ffmpeg-devel-leave@ffmpeg.org

[FFmpeg-devel] Re: [RFC] C++

[Rémi Denis-Courmont via ffmpeg-devel]

Le keskiviikkona 22. lokakuuta 2025, 16.07.36 Itä-Euroopan kesäaika Timo 
Rothenpieler via ffmpeg-devel a écrit :
> C++ can be used as-is, since it can read all our headers just fine.

FFmpeg public headers are C++-compatible and, frankly as a C developer, I find 
that annoying. Not sure about Zig, but Rust does not care about your C headers 
and won't require C programmers to muck with their header files to appease 
rustc.

Or more accurately, it gives you the choice to use or not to use bindgen to 
parse the C headers. And frankly, you are more often than not better off not 
using it.

> Using anything else needs extensive and constant porting work, that then 
> will also make future iterations of internal APIs much harder if not 
> impossible, forcing people who have zero experience with the other 
> language to learn it, just to enhance the C side of things.

> Plus, most of these fancy modern languages are not just a programming 
> language, but they also want to play package-manager, which then forces 
> all of its downstream users to babysit a ton of package version, which 
> largely don't give a damn about stable APIs.

C++ sucks just as badly as Rust to make stable APIs/ABIs. In the end, you end 
up having to expose a C interface, whether you're using C, C++, Zig, Rust or 
anything else. And you'll have to do that forever, since C is the lingua 
franca of system-level programming interfaces.

> So we then need to constantly monitor all those dependencies for bugs 
> and issues, and potentially a fix for one pulls in breaking API changes, 
> which then need to be addressed and backported.

FUD much? How exactly do any other language relieve you from the problem of 
tracking bugs in dependencies?

Cargo gives you the *choice* of pinning or not pinning the versions through 
the lock. FFmpeg should *probably* not pin anything and just specify minimum 
version requirements. And it'll be the exact same dependency hell that we 
already have (or don't have - that's subjective) with C. Nothing to see here.

-- 
ヅニ-クーモン・レミ
Villeneuve de Tapiola, ex-République finlandaise d´Uusimaa



_______________________________________________
ffmpeg-devel mailing list -- ffmpeg-devel@ffmpeg.org
To unsubscribe send an email to ffmpeg-devel-leave@ffmpeg.org

[FFmpeg-devel] Re: [RFC] C++

[Leo Izen via ffmpeg-devel]

On 10/20/25 13:50, Tomas Härdin via ffmpeg-devel wrote:
> Hi
> 
> I'm writing this email to get a feel for how everyone feels about
> making more use of C++ in the codebase. I am only proposing using C++
> *internally*, and only where it makes sense. I am not suggesting a
> "move" to C++, merely using features already present in the compilers
> we target: gcc, clang and cl. The impedance mismatch should therefore
> be small, and any missing compiler features should be caught by FATE.
> 
> Currently C++ use is quite limited in this project, but I see no reason
> why this should be the case. doc/faq.texi makes mention of Linux'
> reasons for avoiding C++, but FFmpeg is not Linux. For us ABI stability
> and performance are the biggest issues. Stability can be ensured by
> sticking with C for the API and disabling exceptions (or marking
> relevant functions as noexcept). Performance may benefit in some cases.
> This would have to be tested. Again, the most performance critical
> parts can be kept as C (and asm).
> 
> My main motivation is to be able to use STL...

I'm not thrilled about including the STL with C++. I've noticed from 
working with C++ codebases that compile time is a lot slower because of 
STL usage in header files.

- Leo Izen

_______________________________________________
ffmpeg-devel mailing list -- ffmpeg-devel@ffmpeg.org
To unsubscribe send an email to ffmpeg-devel-leave@ffmpeg.org

[FFmpeg-devel] Re: [RFC] C++

[Timo Rothenpieler via ffmpeg-devel]

[-- Attachment #1.1.1.1: Type: text/plain, Size: 2632 bytes --]

On 22.10.2025 14:09, Gregor Riepl via ffmpeg-devel wrote:
>> My main motivation is to be able to use STL, which would simplify
>> string handling and memory management, and give us access to its data
>> structures. Manual memory management has its place, especially in lavc.
>> In lavf less so. RAII would do wonders in de-gotofying error handling.
>> Features like std::filesystem, std::chrono, std::thread etc abstract
>> away many OS particularities. Thorough STL-ification would render parts
>> of lavu obsolete. avstring.*, bprintf.* and tree.* come to mind. This
>> would have security benefits. Another reason is stronger typing, which
>> tends to reveal bugs.
> 
> Just for the sake of the argument: Wouldn't it be better to opt for an 
> even safer language than C++, like Rust?

C++ can be used as-is, since it can read all our headers just fine.
Using anything else needs extensive and constant porting work, that then 
will also make future iterations of internal APIs much harder if not 
impossible, forcing people who have zero experience with the other 
language to learn it, just to enhance the C side of things.

Plus, most of these fancy modern languages are not just a programming 
language, but they also want to play package-manager, which then forces 
all of its downstream users to babysit a ton of package version, which 
largely don't give a damn about stable APIs.
So we then need to constantly monitor all those dependencies for bugs 
and issues, and potentially a fix for one pulls in breaking API changes, 
which then need to be addressed and backported.

So stuff like Rust, and anything with similar insane package ecosystems, 
is a huge no from me.

Zig kinda seems interesting under those aspects, but seems a bit too 
immature still, and also kinda seems weird to me with its approach of 
taking over the entire build system, and not just being a compiler to 
integrate like any other.

> C++ has received a lot of criticism in being just as memory unsafe as C, 
> and I personally think that it adds an epic amount of complexity to 
> writing correct code. Although - that may or may not be the case 
> depending on where and how it's used in the code base.
> 
> I don't have any preference either way, but it seems to me that 
> investing effort to make the internals of FFmpeg safer and easier to use 
> would be better spent on a more modern and robust language than C++.
> 
> _______________________________________________
> ffmpeg-devel mailing list -- ffmpeg-devel@ffmpeg.org
> To unsubscribe send an email to ffmpeg-devel-leave@ffmpeg.org


[-- Attachment #1.1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 3203 bytes --]

[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]

[-- Attachment #2: Type: text/plain, Size: 163 bytes --]

_______________________________________________
ffmpeg-devel mailing list -- ffmpeg-devel@ffmpeg.org
To unsubscribe send an email to ffmpeg-devel-leave@ffmpeg.org

[FFmpeg-devel] Re: [RFC] C++

[Michael Niedermayer via ffmpeg-devel]

[-- Attachment #1.1: Type: text/plain, Size: 3737 bytes --]

On Mon, Oct 20, 2025 at 07:50:33PM +0200, Tomas Härdin via ffmpeg-devel wrote:
> Hi
> 
> I'm writing this email to get a feel for how everyone feels about
> making more use of C++ in the codebase. I am only proposing using C++
> *internally*, and only where it makes sense. I am not suggesting a
> "move" to C++, merely using features already present in the compilers
> we target: gcc, clang and cl. The impedance mismatch should therefore
> be small, and any missing compiler features should be caught by FATE.
> 
> Currently C++ use is quite limited in this project, but I see no reason
> why this should be the case. doc/faq.texi makes mention of Linux'
> reasons for avoiding C++, but FFmpeg is not Linux. For us ABI stability
> and performance are the biggest issues. Stability can be ensured by
> sticking with C for the API and disabling exceptions (or marking
> relevant functions as noexcept). Performance may benefit in some cases.
> This would have to be tested. Again, the most performance critical
> parts can be kept as C (and asm).
> 
> My main motivation is to be able to use STL, which would simplify
> string handling and memory management, and give us access to its data
> structures. Manual memory management has its place, especially in lavc.
> In lavf less so. RAII would do wonders in de-gotofying error handling.
> Features like std::filesystem, std::chrono, std::thread etc abstract
> away many OS particularities. Thorough STL-ification would render parts
> of lavu obsolete. avstring.*, bprintf.* and tree.* come to mind. This
> would have security benefits. Another reason is stronger typing, which
> tends to reveal bugs.
> 
> I've targeted mxfdec.c as a proof-of-concept. See attached patch, which
> compiles and passes fate-mxf. It is partly inspired by our decklink
> binding. Particularly notable is the ability to resolve MXF structs
> into MXFMetadataSetType at compile time, as well as resolving strong
> references in a more type safe manner. This revealed an issue in
> mxf_parse_structural_metadata() where MXFStructuralComponent* was
> blindly cast to MXFTimecodeComponent*, which could cause code further
> down to interpret the latter as the former, which is a not so obvious
> bug that wouldn't be caught without this stronger typing.
> 
> I've not made use of STL in the attached patch because that requires
> linking with libstdc++, which I couldn't be arsed to do. One practical
> example where STL would come in handy is for my work on segmented
> indexes. Specifically std::map and std::lower_bound. Various tables in
> mxfdec.c could also be targets for turning into std::map or even
> std::unordered_map. A quick experiment with callgrind suggests
> mxf_read_header() might be speed up slightly with such a change.
> 
> Details like which version of C++ to use could be agreed on later if
> people feel this is a good idea. Personally I favor using the most
> recent version that our compiler suite supports. Lately I've been using
> C++20 with icx (Intel's compiler) which has been quite pleasant.

One difference that favors lower level languages is that with
high level languages one looses sight of the cost of operations

Teh closer you are to the implementation of a data structure, like
if you are on the team of people who developed or maintains it.
The more likely you are also aware of its cost or one of the reviewer
would spot you doing a O(n^2) operation as if its O(1)

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.

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

[-- Attachment #2: Type: text/plain, Size: 163 bytes --]

_______________________________________________
ffmpeg-devel mailing list -- ffmpeg-devel@ffmpeg.org
To unsubscribe send an email to ffmpeg-devel-leave@ffmpeg.org

[FFmpeg-devel] Re: [RFC] C++

[Michael Niedermayer via ffmpeg-devel]

[-- Attachment #1.1: Type: text/plain, Size: 1190 bytes --]

Hi

On Wed, Oct 22, 2025 at 02:09:32PM +0200, Gregor Riepl via ffmpeg-devel wrote:
> > My main motivation is to be able to use STL, which would simplify
> > string handling and memory management, and give us access to its data
> > structures. Manual memory management has its place, especially in lavc.
> > In lavf less so. RAII would do wonders in de-gotofying error handling.
> > Features like std::filesystem, std::chrono, std::thread etc abstract
> > away many OS particularities. Thorough STL-ification would render parts
> > of lavu obsolete. avstring.*, bprintf.* and tree.* come to mind. This
> > would have security benefits. Another reason is stronger typing, which
> > tends to reveal bugs.
> 

> Just for the sake of the argument: Wouldn't it be better to opt for an even safer language than C++, like Rust?

+1

i think the main question in choosing a language is the size of
the pool of developers potentially able/willing to contribute to FFmpeg using that
language

thx


[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Nations do behave wisely once they have exhausted all other alternatives. 
-- Abba Eban

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

[-- Attachment #2: Type: text/plain, Size: 163 bytes --]

_______________________________________________
ffmpeg-devel mailing list -- ffmpeg-devel@ffmpeg.org
To unsubscribe send an email to ffmpeg-devel-leave@ffmpeg.org

[FFmpeg-devel] Re: [RFC] C++

[Gregor Riepl via ffmpeg-devel]

> My main motivation is to be able to use STL, which would simplify
> string handling and memory management, and give us access to its data
> structures. Manual memory management has its place, especially in lavc.
> In lavf less so. RAII would do wonders in de-gotofying error handling.
> Features like std::filesystem, std::chrono, std::thread etc abstract
> away many OS particularities. Thorough STL-ification would render parts
> of lavu obsolete. avstring.*, bprintf.* and tree.* come to mind. This
> would have security benefits. Another reason is stronger typing, which
> tends to reveal bugs.

Just for the sake of the argument: Wouldn't it be better to opt for an even safer language than C++, like Rust?

C++ has received a lot of criticism in being just as memory unsafe as C, and I personally think that it adds an epic amount of complexity to writing correct code. Although - that may or may not be the case depending on where and how it's used in the code base.

I don't have any preference either way, but it seems to me that investing effort to make the internals of FFmpeg safer and easier to use would be better spent on a more modern and robust language than C++.

_______________________________________________
ffmpeg-devel mailing list -- ffmpeg-devel@ffmpeg.org
To unsubscribe send an email to ffmpeg-devel-leave@ffmpeg.org

[FFmpeg-devel] Re: [RFC] C++

[Tomas Härdin via ffmpeg-devel]

tis 2025-10-21 klockan 22:15 -0500 skrev Romain Beauxis via ffmpeg-
devel:
> I understand the benefit of using higher order APIs borrowed from C++
> but,
> to fully make your case I think it'd be important to know: is it
> possible
> to use STL and avoid linking with libstc++?

It's technically possible, but I don't see why you'd want to. It'd be
like us writing our own libc. It's already required for decklink.

/Tomas
_______________________________________________
ffmpeg-devel mailing list -- ffmpeg-devel@ffmpeg.org
To unsubscribe send an email to ffmpeg-devel-leave@ffmpeg.org

[FFmpeg-devel] Re: [RFC] C++

[Tomas Härdin via ffmpeg-devel]

[-- Attachment #1: Type: text/plain, Size: 1629 bytes --]

tis 2025-10-21 klockan 04:24 +0200 skrev Lynne via ffmpeg-devel:
> On 20/10/2025 19:50, Tomas Härdin via ffmpeg-devel wrote:
> > Hi
> > 
> > I'm writing this email to get a feel for how everyone feels about
> > making more use of C++ in the codebase. I am only proposing using
> > C++
> > *internally*, and only where it makes sense. I am not suggesting a
> > "move" to C++, merely using features already present in the
> > compilers
> > we target: gcc, clang and cl. The impedance mismatch should
> > therefore
> > be small, and any missing compiler features should be caught by
> > FATE.
> 
> Definitely not.
> The patch you posted hardly changes anything.

Here's a more illustrative example. What it means for a given offset to
be contained "within" a partition is made explicit. This also allows us
to reject files where partitions are overlapping, which wasn't obvious
with the previous code

The codebase is actually littered with binary searches like the one the
attached patchset removes. That's a major code stink imo

KLV keys could be given a similar treatment. Most importantly, the
entire index code could be made far more readable and robust. That's a
rather large task however, which I'm not going to undertake unless I
know I won't face major opposition

A continuation of the partition stuff attached is to remove
MXFContext::partitions and instead use an std::map in MXFCppContext for
the partitions themselves, not just their offsets. This would address
some performance issues with the present code for files with a large
number of partitions, such as mxfenc.c

/Tomas

[-- Attachment #2: 0001-lavf-mxfdec-Add-C-context.patch --]
[-- Type: text/x-patch, Size: 1880 bytes --]

From bda56e7d1259047e65c02cc40ab53728eedbfc6f Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Tomas=20H=C3=A4rdin?= <git@haerdin.se>
Date: Wed, 22 Oct 2025 11:01:21 +0200
Subject: [PATCH 1/2] lavf/mxfdec: Add C++ context

---
 libavformat/mxfdec.cpp | 5 +++++
 libavformat/mxfdec.h   | 2 ++
 2 files changed, 7 insertions(+)

diff --git a/libavformat/mxfdec.cpp b/libavformat/mxfdec.cpp
index 1b3c00c07c..522d870981 100644
--- a/libavformat/mxfdec.cpp
+++ b/libavformat/mxfdec.cpp
@@ -333,6 +333,9 @@ typedef struct MXFIndexTable {
     int8_t *offsets;            /* temporal offsets for display order to stored order conversion */
 } MXFIndexTable;
 
+struct MXFCppContext {
+};
+
 /* NOTE: klv_offset is not set (-1) for local keys */
 typedef int MXFMetadataReadFunc(void *arg, AVIOContext *pb, int tag, int size, UID uid, int64_t klv_offset);
 
@@ -3786,6 +3789,7 @@ int mxf_read_header(AVFormatContext *s)
     int ret;
     int64_t run_in;
 
+    mxf->cpp_context = new MXFCppContext();
     mxf->last_forward_tell = INT64_MAX;
 
     if (!mxf_read_sync(s->pb, mxf_header_partition_pack_key, 14)) {
@@ -4206,6 +4210,7 @@ int mxf_read_close(AVFormatContext *s)
         }
     }
     av_freep(&mxf->index_tables);
+    delete mxf->cpp_context;
 
     return 0;
 }
diff --git a/libavformat/mxfdec.h b/libavformat/mxfdec.h
index 3680e0a8ac..f4ad85fb46 100644
--- a/libavformat/mxfdec.h
+++ b/libavformat/mxfdec.h
@@ -41,6 +41,7 @@ typedef enum {
 struct MXFIndexTable;
 struct MXFMetadataSet;
 struct MXFPartition;
+struct MXFCppContext;
 
 typedef struct MXFMetadataSetGroup {
     struct MXFMetadataSet **metadata_sets;
@@ -71,6 +72,7 @@ typedef struct MXFContext {
     int nb_index_tables;
     struct MXFIndexTable *index_tables;
     int eia608_extract;
+    struct MXFCppContext *cpp_context; //< C++ context
 } MXFContext;
 
 int mxf_probe(const AVProbeData *p);
-- 
2.47.2


[-- Attachment #3: 0002-lavf-mxfdec-Switch-mxf_absolute_bodysid_offset-to-st.patch --]
[-- Type: text/x-patch, Size: 5104 bytes --]

From 682a647df0af169a673175eab13f99c7b58fffbd Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Tomas=20H=C3=A4rdin?= <git@haerdin.se>
Date: Wed, 22 Oct 2025 12:28:32 +0200
Subject: [PATCH 2/2] lavf/mxfdec: Switch mxf_absolute_bodysid_offset() to
 std::map

This allows us to detect and reject evil files which have been constructed to have overlapping partitions
---
 libavformat/mxfdec.cpp | 90 +++++++++++++++++++++++++++++-------------
 1 file changed, 62 insertions(+), 28 deletions(-)

diff --git a/libavformat/mxfdec.cpp b/libavformat/mxfdec.cpp
index 522d870981..7a7b824e26 100644
--- a/libavformat/mxfdec.cpp
+++ b/libavformat/mxfdec.cpp
@@ -47,6 +47,9 @@
 #include <inttypes.h>
 #include <time.h>
 
+#include <algorithm>
+#include <map>
+
 extern "C" {
 #include "libavutil/aes.h"
 #include "libavutil/avstring.h"
@@ -334,6 +337,26 @@ typedef struct MXFIndexTable {
 } MXFIndexTable;
 
 struct MXFCppContext {
+    typedef std::map<int64_t, MXFPartition*> OffsetMap;      //< maps BodyOffset -> MXFPartition*
+    std::map<int, OffsetMap> bodysid_offset_partition_map;   //< maps (BodySID, BodyOffset) -> MXFPartition*
+
+    // comparator for whether a given offset is contained within [body_offset, body_offset + essence_length)
+    struct OffsetInPartitionComp {
+        bool operator() (const std::pair<int64_t, MXFPartition*> &a, int64_t b) const {
+            if (a.second->essence_length) {
+                // <= because the end of the range is exclusive
+                return a.second->body_offset + a.second->essence_length <= b;
+            } else {
+                // if essence_length == 0 then this partition spans the rest of the file
+                // this should only happen for the last partition
+                return false; // we can never be "less than" any given offset
+            }
+        }
+
+        bool operator() (int64_t a, const std::pair<int64_t, MXFPartition*> &b) const {
+            return a < b.second->body_offset;
+        }
+    };
 };
 
 /* NOTE: klv_offset is not set (-1) for local keys */
@@ -1880,35 +1903,40 @@ static int mxf_get_sorted_table_segments(MXFContext *mxf, int *nb_sorted_segment
  */
 static int mxf_absolute_bodysid_offset(MXFContext *mxf, int body_sid, int64_t offset, int64_t *offset_out, MXFPartition **partition_out)
 {
-    MXFPartition *last_p = NULL;
-    int a, b, m, m0;
-
-    if (offset < 0)
-        return AVERROR(EINVAL);
-
-    a = -1;
-    b = mxf->partitions_count;
-
-    while (b - a > 1) {
-        m0 = m = (a + b) >> 1;
-
-        while (m < b && mxf->partitions[m].body_sid != body_sid)
-            m++;
-
-        if (m < b && mxf->partitions[m].body_offset <= offset)
-            a = m;
-        else
-            b = m0;
-    }
-
-    if (a >= 0)
-        last_p = &mxf->partitions[a];
+    auto &partition_map = mxf->cpp_context->bodysid_offset_partition_map;
+    auto it = partition_map.find(body_sid);
+
+    if (it != partition_map.end()) {
+        // find range of partitions within which offset is contained
+        // there should be exactly one
+        auto [start, end] = std::equal_range(
+            it->second.begin(),
+            it->second.end(),
+            offset,
+            MXFCppContext::OffsetInPartitionComp()
+        );
+        auto d = std::distance(start, end);
+
+        if (d > 1) {
+            // this could happen for evil files - reject them
+            av_log(mxf->fc, AV_LOG_ERROR, "absolute offset %" PRIX64 " contained in more than one partition\n", offset);
+
+            // log offending partitions
+            for (; start != end; start++) {
+                MXFPartition *p = start->second;
+                av_log(mxf->fc, AV_LOG_ERROR, "BodyOffset %" PRIX64 " BodyOffset+essence_length %" PRIX64 "\n", p->body_offset, p->body_offset + p->essence_length);
+            }
 
-    if (last_p && (!last_p->essence_length || last_p->essence_length > (offset - last_p->body_offset))) {
-        *offset_out = last_p->essence_offset + (offset - last_p->body_offset);
-        if (partition_out)
-            *partition_out = last_p;
-        return 0;
+            return AVERROR_INVALIDDATA;
+        } else if (d == 1) {
+            MXFPartition *last_p = start->second;
+            if ((!last_p->essence_length || last_p->essence_length > (offset - last_p->body_offset))) {
+                *offset_out = last_p->essence_offset + (offset - last_p->body_offset);
+                if (partition_out)
+                    *partition_out = last_p;
+                return 0;
+            }
+        }
     }
 
     av_log(mxf->fc, AV_LOG_ERROR,
@@ -3899,6 +3927,12 @@ int mxf_read_header(AVFormatContext *s)
 
     mxf_compute_essence_containers(s);
 
+    // set up bodysid_offset_partition_map
+    for (int x = 0; x < mxf->partitions_count; x++) {
+        MXFPartition *partition = &mxf->partitions[x];
+        mxf->cpp_context->bodysid_offset_partition_map[partition->body_sid][partition->body_offset] = partition;
+    }
+
     for (int i = 0; i < s->nb_streams; i++)
         mxf_compute_edit_units_per_packet(mxf, s->streams[i]);
 
-- 
2.47.2


[-- Attachment #4: Type: text/plain, Size: 163 bytes --]

_______________________________________________
ffmpeg-devel mailing list -- ffmpeg-devel@ffmpeg.org
To unsubscribe send an email to ffmpeg-devel-leave@ffmpeg.org

[FFmpeg-devel] Re: [RFC] C++

[Tomas Härdin via ffmpeg-devel]

tis 2025-10-21 klockan 04:24 +0200 skrev Lynne via ffmpeg-devel:
> On 20/10/2025 19:50, Tomas Härdin via ffmpeg-devel wrote:
> > Hi
> > 
> > I'm writing this email to get a feel for how everyone feels about
> > making more use of C++ in the codebase. I am only proposing using
> > C++
> > *internally*, and only where it makes sense. I am not suggesting a
> > "move" to C++, merely using features already present in the
> > compilers
> > we target: gcc, clang and cl. The impedance mismatch should
> > therefore
> > be small, and any missing compiler features should be caught by
> > FATE.
> 
> Definitely not.
> The patch you posted hardly changes anything.

That's on purpose. If you want I can make more thoroughgoing changes
like turning all tables into std::map, lambdafying things etc etc. For
example parts of mxf_read_packet() could be turned into map<UID,λ>. The
IndexTableSegment stuff also comes to mind

/Tomas
_______________________________________________
ffmpeg-devel mailing list -- ffmpeg-devel@ffmpeg.org
To unsubscribe send an email to ffmpeg-devel-leave@ffmpeg.org

[FFmpeg-devel] Re: [RFC] C++

[Nicolas George via ffmpeg-devel]

Romain Beauxis via ffmpeg-devel (HE12025-10-21):
>							     is it possible
> to use STL and avoid linking with libstc++?

It is possible to use the data structures and algorithms of the STL,
which are the key to the performance gains, by implementing them in
libavutil. We can even gain a little more performance by making them
more specifically suited to our needs and style.

Regards,

-- 
  Nicolas George
_______________________________________________
ffmpeg-devel mailing list -- ffmpeg-devel@ffmpeg.org
To unsubscribe send an email to ffmpeg-devel-leave@ffmpeg.org

[FFmpeg-devel] Re: [RFC] C++

[InnocentZero via ffmpeg-devel]

Romain Beauxis via ffmpeg-devel <ffmpeg-devel@ffmpeg.org> writes:

> I understand the benefit of using higher order APIs borrowed from C++ but,
> to fully make your case I think it'd be important to know: is it possible
> to use STL and avoid linking with libstc++?

I'm new to the list, so forgive me for asking if it's a mundane
question, but what exactly is the reason for avoiding linking with
libstc++?

Is it solely to avoid having a dependency on a library? Or some other
specific reason?
_______________________________________________
ffmpeg-devel mailing list -- ffmpeg-devel@ffmpeg.org
To unsubscribe send an email to ffmpeg-devel-leave@ffmpeg.org

[FFmpeg-devel] Re: [RFC] C++

[Romain Beauxis via ffmpeg-devel]

On Mon, Oct 20, 2025, 12:51 Tomas Härdin via ffmpeg-devel <
ffmpeg-devel@ffmpeg.org> wrote:

> Hi
>
> I'm writing this email to get a feel for how everyone feels about
> making more use of C++ in the codebase. I am only proposing using C++
> *internally*, and only where it makes sense. I am not suggesting a
> "move" to C++, merely using features already present in the compilers
> we target: gcc, clang and cl. The impedance mismatch should therefore
> be small, and any missing compiler features should be caught by FATE.
>
> Currently C++ use is quite limited in this project, but I see no reason
> why this should be the case. doc/faq.texi makes mention of Linux'
> reasons for avoiding C++, but FFmpeg is not Linux. For us ABI stability
> and performance are the biggest issues. Stability can be ensured by
> sticking with C for the API and disabling exceptions (or marking
> relevant functions as noexcept). Performance may benefit in some cases.
> This would have to be tested. Again, the most performance critical
> parts can be kept as C (and asm).
>
> My main motivation is to be able to use STL, which would simplify
> string handling and memory management, and give us access to its data
> structures. Manual memory management has its place, especially in lavc.
> In lavf less so. RAII would do wonders in de-gotofying error handling.
> Features like std::filesystem, std::chrono, std::thread etc abstract
> away many OS particularities. Thorough STL-ification would render parts
> of lavu obsolete. avstring.*, bprintf.* and tree.* come to mind. This
> would have security benefits. Another reason is stronger typing, which
> tends to reveal bugs.
>
> I've targeted mxfdec.c as a proof-of-concept. See attached patch, which
> compiles and passes fate-mxf. It is partly inspired by our decklink
> binding. Particularly notable is the ability to resolve MXF structs
> into MXFMetadataSetType at compile time, as well as resolving strong
> references in a more type safe manner. This revealed an issue in
> mxf_parse_structural_metadata() where MXFStructuralComponent* was
> blindly cast to MXFTimecodeComponent*, which could cause code further
> down to interpret the latter as the former, which is a not so obvious
> bug that wouldn't be caught without this stronger typing.
>
> I've not made use of STL in the attached patch because that requires
> linking with libstdc++, which I couldn't be arsed to do.


I understand the benefit of using higher order APIs borrowed from C++ but,
to fully make your case I think it'd be important to know: is it possible
to use STL and avoid linking with libstc++?

One practical
> example where STL would come in handy is for my work on segmented
> indexes. Specifically std::map and std::lower_bound. Various tables in
> mxfdec.c could also be targets for turning into std::map or even
> std::unordered_map. A quick experiment with callgrind suggests
> mxf_read_header() might be speed up slightly with such a change.
>
> Details like which version of C++ to use could be agreed on later if
> people feel this is a good idea. Personally I favor using the most
> recent version that our compiler suite supports. Lately I've been using
> C++20 with icx (Intel's compiler) which has been quite pleasant.
>
> /Tomas
> _______________________________________________
> ffmpeg-devel mailing list -- ffmpeg-devel@ffmpeg.org
> To unsubscribe send an email to ffmpeg-devel-leave@ffmpeg.org
>
_______________________________________________
ffmpeg-devel mailing list -- ffmpeg-devel@ffmpeg.org
To unsubscribe send an email to ffmpeg-devel-leave@ffmpeg.org

[FFmpeg-devel] Re: [RFC] C++

[Niklas Haas via ffmpeg-devel]

On Mon, 20 Oct 2025 19:50:33 +0200 Tomas Härdin via ffmpeg-devel <ffmpeg-devel@ffmpeg.org> wrote:
> Hi
>
> I'm writing this email to get a feel for how everyone feels about
> making more use of C++ in the codebase. I am only proposing using C++
> *internally*, and only where it makes sense. I am not suggesting a
> "move" to C++, merely using features already present in the compilers
> we target: gcc, clang and cl. The impedance mismatch should therefore
> be small, and any missing compiler features should be caught by FATE.
>
> Currently C++ use is quite limited in this project, but I see no reason
> why this should be the case. doc/faq.texi makes mention of Linux'
> reasons for avoiding C++, but FFmpeg is not Linux. For us ABI stability
> and performance are the biggest issues. Stability can be ensured by
> sticking with C for the API and disabling exceptions (or marking
> relevant functions as noexcept). Performance may benefit in some cases.
> This would have to be tested. Again, the most performance critical
> parts can be kept as C (and asm).

I personally have always felt like debugging C++ in gdb is a bit of a
sub-par experience compared to C; but maybe things have gotten better
these days?
_______________________________________________
ffmpeg-devel mailing list -- ffmpeg-devel@ffmpeg.org
To unsubscribe send an email to ffmpeg-devel-leave@ffmpeg.org

[FFmpeg-devel] Re: [RFC] C++

[Lynne via ffmpeg-devel]

On 20/10/2025 19:50, Tomas Härdin via ffmpeg-devel wrote:
> Hi
> 
> I'm writing this email to get a feel for how everyone feels about
> making more use of C++ in the codebase. I am only proposing using C++
> *internally*, and only where it makes sense. I am not suggesting a
> "move" to C++, merely using features already present in the compilers
> we target: gcc, clang and cl. The impedance mismatch should therefore
> be small, and any missing compiler features should be caught by FATE.

Definitely not.
The patch you posted hardly changes anything.
_______________________________________________
ffmpeg-devel mailing list -- ffmpeg-devel@ffmpeg.org
To unsubscribe send an email to ffmpeg-devel-leave@ffmpeg.org

[FFmpeg-devel] Re: [RFC] C++

[Neal Gompa via ffmpeg-devel]

On Mon, Oct 20, 2025 at 1:51 PM Tomas Härdin via ffmpeg-devel
<ffmpeg-devel@ffmpeg.org> wrote:
>
> Hi
>
> I'm writing this email to get a feel for how everyone feels about
> making more use of C++ in the codebase. I am only proposing using C++
> *internally*, and only where it makes sense. I am not suggesting a
> "move" to C++, merely using features already present in the compilers
> we target: gcc, clang and cl. The impedance mismatch should therefore
> be small, and any missing compiler features should be caught by FATE.
>
> Currently C++ use is quite limited in this project, but I see no reason
> why this should be the case. doc/faq.texi makes mention of Linux'
> reasons for avoiding C++, but FFmpeg is not Linux. For us ABI stability
> and performance are the biggest issues. Stability can be ensured by
> sticking with C for the API and disabling exceptions (or marking
> relevant functions as noexcept). Performance may benefit in some cases.
> This would have to be tested. Again, the most performance critical
> parts can be kept as C (and asm).
>
> My main motivation is to be able to use STL, which would simplify
> string handling and memory management, and give us access to its data
> structures. Manual memory management has its place, especially in lavc.
> In lavf less so. RAII would do wonders in de-gotofying error handling.
> Features like std::filesystem, std::chrono, std::thread etc abstract
> away many OS particularities. Thorough STL-ification would render parts
> of lavu obsolete. avstring.*, bprintf.* and tree.* come to mind. This
> would have security benefits. Another reason is stronger typing, which
> tends to reveal bugs.
>
> I've targeted mxfdec.c as a proof-of-concept. See attached patch, which
> compiles and passes fate-mxf. It is partly inspired by our decklink
> binding. Particularly notable is the ability to resolve MXF structs
> into MXFMetadataSetType at compile time, as well as resolving strong
> references in a more type safe manner. This revealed an issue in
> mxf_parse_structural_metadata() where MXFStructuralComponent* was
> blindly cast to MXFTimecodeComponent*, which could cause code further
> down to interpret the latter as the former, which is a not so obvious
> bug that wouldn't be caught without this stronger typing.
>
> I've not made use of STL in the attached patch because that requires
> linking with libstdc++, which I couldn't be arsed to do. One practical
> example where STL would come in handy is for my work on segmented
> indexes. Specifically std::map and std::lower_bound. Various tables in
> mxfdec.c could also be targets for turning into std::map or even
> std::unordered_map. A quick experiment with callgrind suggests
> mxf_read_header() might be speed up slightly with such a change.
>
> Details like which version of C++ to use could be agreed on later if
> people feel this is a good idea. Personally I favor using the most
> recent version that our compiler suite supports. Lately I've been using
> C++20 with icx (Intel's compiler) which has been quite pleasant.
>

I think it'd be great if this was done. Actually, RPM made a similar
move for RPM 6.0[1] for precisely the same reason.

From my point of view, it would make it easier for me to understand
the code as I'm more of a C++ guy than a C guy. And I feel like
there's a longer-term benefit to simplify code by not needing to
recreate data structures that are perfectly usable from the STL.

That said, from a C++ standard perspective, C++20 is a great place to
start from. RPM, KDE, and other major Free Software projects using C++
have moved to it and liked the improvements to C/C++ it offers.

[1]: https://rpm.org/releases/6.0.0



-- 
真実はいつも一つ！/ Always, there's only one truth!
_______________________________________________
ffmpeg-devel mailing list -- ffmpeg-devel@ffmpeg.org
To unsubscribe send an email to ffmpeg-devel-leave@ffmpeg.org