Jonathan Blow

WebM is free, so you could use a combination of libwebm, libvpx, libogg, and libvorbis.

I just don't want a mess that big, though...

One of the main reasons Bink is still in business is because there never seems to be an answer to this question.

It is kind of crazy given how many people in the world want to watch videos.

Like, can someone just make a video format that is a regular file format like any other file format? That isn't broken into separate transport file streaming chunk opaque flibflobber formats? We all know what a video is, we all know how it behaves, just make one god damn thing.

Maybe this is what I have to do after releasing the initial programming language beta. It wouldn't even have to have good compression to be valuable ... it just has to be one simple f'ing thing.

compression is the main reason video formats are so complicated

That is false.

Do you want them to be user-supplied or are you going to encode them? I was considering HAP as a codec lately (bsd2). Not sure about transport/metadata/audio interleave. Maybe you could just Ogg as a container format but I guess there is no out-of-the-box solution

It would be me encoding them, so I can pick any format that works well at runtime.

I used HAP recently. It's super simple, a series of compressed textures. Ref. impl is .h + .c file ~1300 loc. You still need a container, common are AVI/MOV, but if you want to avoid the complexity of a classic demuxer, you'd have to roll your own container to store the frames.

“You still need a container” is an instant no.

I’m curious: when you say no container - what is the issue with a container? And how would you like to (for lack of a better word) contain the video?

The issue is I don't as a user of the library care what the container is, so why are you making me care, and why are you making me wrangle more dependencies for something that is trivial? And why are you requiring the playback system to not know what it is playing back?

I don't think I would ship anything that is GPL or LGPL ... the goal of this system is to eliminate complexity, and legal constraints are complexity. Much nicer if you can easily assume "all code distributed with this compiler is under an MIT-like license".

If you only distribute the API client.h and have people provide their own DLL (or provide a pre-compiled one for them), that's still an option. Redistributing an entire video playback library's source (plus any dependencies) is talking about a lot of code anyway.

No, it's too much complexity. This should be simple. If it's not simple we won't ship it.

Fair enough.

Also, why should "entire video playback library" be big? In principle it's small.

It doesn't need to be, but most open source video stuff just ends up outsourcing the heavy lifting to something like ffmpeg or libav, and those are massive projects meant to handle a variety of formats/features. I don't know of any single-format A/V libs that aren't commercial.