jbk

> This reads to me as it being a PITA to maintain.

Not more than any other language: when it's well done, it's manageable. When it's spaghetti code, it's not manageable.

As all software decoders… So you compare software to hardware decoders?

H265 or VP9 in software are the same… Here, we managed to have a sw decoder for a format that is one order of magnitude more complex than those codecs and yet, consume less CPU.

All arch have the same level of optimizations, but AVX2 might have a couple functions more. AVX-512 is still behind…

Hand written with some macros, notably for the x86 mess (windows calling convention, ssse being 32 and 64b).

And those machine cannot decode H265 in software… Sorry but you cannot say dav1d software decoding is bad on phones because some hardware from 15 years ago who can barely decode H264 cannot decode it.

I really can't see how you read anything else that "it's very optimized" in my message, tbh.

Tbh, those results are a bit surprising. We have much better results with similar hardware...

How are you testing? Is that dav1d 1.0? 8bit or 10bit content?

If you tested before 1.0 and 10bit content, you should run it again, since we pushed new optimizations for this.

> older Core 2 Duo MacBook Pro

Core 2 Duo are processors from 16 years ago...

Mobile phones are more powerful than those machines...

(President of VideoLAN here)

What you should really look at on dav1d is the fact that the code has now around 186 kLoC of hand-written assembly in .S and .asm files…

I think this is quite a feat (this is more asm than the whole FFmpeg) and this is very rare those days to write so much asm.

Something like that: http://www.jbkempf.com/blog/post/2022/FFmpeg-5.0

And very few of those big companies contribute back…

See https://news.ycombinator.com/item?id=29524103

DirectX 12 API is a pretty small case to throw all the project to trash.

Notably since DirectX headers are always a different case compared to the rest of the Windows SDK

That’s the opposite of our experience on VLC and Firefox was sharing our opinion: mingw-w64 people are skilled, nice and very clever and think about all use cases.

This is how we are able to support configurations that even MS does not support…

Also, a contrario from what this threads seems to say, the Windows SDK headers are faaaar from being open source compatible

> What's the largest company that uses FFmpeg and has refused? What did they say?

I won't give names, but some very large cloud providers and some very large chips vendors.

> It essentially talks about a services and support business around open source.

Which is _exactly_ what we are doing...

> Would following an open core model work better, like it has for Hashicorp, Sidekiq, Tailwind, etc?

Yes, I think this might be a better model, indeed.

But I did not start either of those projects, I came on board later; and those models are difficult to back-fit into an existing project.

> You need a proper "asshole" in such organizations that will go and threaten complete lack of support if the bill isn't paid.

That's the point, they don't pay, and they don't get support. But they still complain when there is a major CVE.

> For comparison, $1M is the total yearly cost of ~3 average engineers at FAANGs.

I wish we got that...

> Given this situation, why will they pay for what they can get for free?

See the article...

> Now is the perfect time for Open Source maintainers to become legible to the big companies that depend on them—and that want to get more out of them—and send them five-to-six figure invoices.

Well, this is exactly what I've been doing around VideoLAN (VLC, x264) and FFmpeg for the last few years. In order to do that, I've created 2 official companies Videolabs and FFlabs (besides the non-profit orgs) and I've gone through all the hoops to get paid (PO, billing, invoices, registering to large companies is a lot of paperwork, tbh, but well..) and we try and bill small to large companies that depends on those projects.

And FFmpeg and x264 are the core of the online video.

So I did exactly what Filippo is saying we should do.

But the result is really not impressive. Seriously, asking for money for support from those companies feels like we're pulling the nails, even if their full business depends on it. Getting 30-50k$ from those companies for support for one year can be very challenging, long or leading to nowhere at all.

So, large SV companies and startup should also start agreeing to pay for open source, when it's the core of the tech.

Vlc supports original Winamp skins… I plan to improve this in the future btw :)

VLC on iOS

Even on the beta of the next Safari?

Yes, unfortunately, the blog is in French, but it's easy to understand/translate, with the video and the pictures...

> "Accessible" should be the default, not an option. The file menu being present should be the default, not an option.

This is your opinion. Weirdly, all the other programs are doing it differently. So maybe, your opinion is the minority, not the majority.

And as I said, this is an option.

No, but you have a compatibility mode.

And the 3.0 version still exist.

> Maybe perhaps with v4 these small QOL things could be implemented.

This is on our roadmap.

> But on topic, how far is VLC 4 from release?

Quite far, of course.

All of those are early issues that are going to be fixed. See my post above.

(President of VideoLAN here)

Sorry to say, but the article is quite useless, and a bit misleading.

It's talking about a work-in-progress work, which is very far from being finished. None of those big issues are wanted.

Of course, the video being split from the UI is not wanted, and is just that the work is not finished on all the platforms. But this is per platform integration, because of composition APIs.

For example, this is what the player looks like on Windows: https://i.imgur.com/q71PzJU.png and of course, this is integrated.

As for the rest, everything is optional and will be made optional:

- you can have the menu by default, if you want it, including the File menu,

- you can disable the medialibrary, and have 0 indexation, if you don't like it,

- the player will be possible to look very closely to the 3.0 version,

- the player can be integrated in the main UI, or split,

- the overlay can be above the video, like the imgur above, or the controls can be under the video, like in 3.0.

Seriously, some of those things are even doable today, in the nightly builds. I don't think the Author saw those options.

As to why, there is a media library, it is quite simple: some people use VLC to play a video file, and they will go to the player directly, and not see the medialibrary; or for the other use cases, you launch VLC, and it has indexed your home NAS and so on.

The goal is for the UI to be the less visible, as you can see in the imgur link above. Only visible on mouse over, if need be.

Dolby

> but isn’t it basically a GUI around FFMPEG

No, it isn't. VLC is doing a lot more than just wrapping libavcodec. Look at the source code of VLC.

To give you an idea, VLC is around 800 kLoC, the UI taking 60 kLoC, and the core 100 kLoC. There are tons of modules that are not based on FFmpeg.

Also, some VLC devs are also FFMpeg devs.