rust-gamedev / rust-gamedev.github.io

The repository for https://gamedev.rs
https://gamedev.rs
Apache License 2.0
388 stars 344 forks source link

Officially allow small videos (e.g. mp4) #1518

Open caspark opened 1 month ago

caspark commented 1 month ago

I saw this was touched on over at #1500, but I figured I'd make a dedicated issue for it:

Any chance of officially blessing mp4 videos for inclusion, either in addition to or in place of gifs?

Could be with the same <2.5MB size guidance, or a stricter (say <1MB) requirement.

I am asking because mp4 files tend to be significantly more size-efficient than gifs; I happen to generate both for my weekly Slow Rush newsletter so I did a quick size comparison using the videos from 5 of my recent newsletter updates:

image (source: gif-vs-mp4.ods)

This is not a fair comparison because the gifs are generated at half the size and less than half the framerate of the mp4, but mp4 still gives an 80% size reduction on average. Such a large saving may not universally be the case for all footage (my game is pixel art oriented and, well, kinda ugly and monotonous-looking right now), but from a bit of poking around, to me it seems that to have mp4 do worse than gifs you'd have to actually put in effort to pick bad encoding settings.

FYI, here are the ffmpeg invocations I used (extracted from my png frames -> video conversion script):

# create a 60fps h264-encoded mp4
ffmpeg -nostdin -y -framerate 60 -i $frames_dir/%d.png -c:v libx264 -pix_fmt yuv420p $output_dir/$dest_name.mp4

# create a 24fps gif at _half_ the source resolution
ffmpeg -nostdin -y -framerate 60 -i $frames_dir/%d.png -vf fps=24,scale=iw/2:-1:flags=lanczos", $output_dir/$dest_name.gif

# (in no way am I claiming to be an expert in video codecs.. those invocations may not be optimal!)

It would make sense to require gifs if the newsletter was sent out via email (that's why I generate both gif and mp4 files), but that doesn't seem to be the case here?

Lastly, I get that mp4 is just a container format, and so there's the question of what codec, is h264 legally okay to use, is it morally okay to encourage use of a patented codec, etc. As far as I understand, it is at least royalty-free to distribute free h264-encoded videos.

And if the moral angle is a concern, I'd also be totally fine with allowing webm videos (or animated webp images!), but as of earlier this year, (at least some) iOS web browsers couldn't play the webm movies I was encoding.

janhohenheim commented 1 month ago

TIL, thanks! The newsletter is planned to be sent via email (#24), so that is certainly something to consider.

Other than that I don't have a problem with including mp4 right now if the file size is alright. In fact, I wouldn't even have touched the video in the linked PR if it didn't happen to be 10 MiB big. I didn't know mp4 was that much more efficient, so next time I'll try to convert media to a smaller mp4 instead of a gif.

Anecdotally, I can also confirm that my iOS Safari is still experiencing bugs when encountering webms.

@Vrixyz do you have any thoughts on this?

caspark commented 1 month ago

Ah, I totally overlooked #24! In that case, AFAIK you can't really get away from including gifs in the emailed version, unless you do something like static image previews of videos that link to the real video.

Or have a build step that transcodes the videos to gifs, stores them elsewhere, and thereby keep the repo size a little more under control. Depends on how much complexity you are willing to deal with.

Since I am already generating gifs, it is not a problem for me to keep submitting them - I was just surprised at how long it took to clone this repo and that mp4s were preferred over videos in the contributing guidelines.

janhohenheim commented 1 month ago

Yep, the repo size is definitely a problem. See https://github.com/rust-gamedev/rust-gamedev.github.io/issues/636.

janhohenheim commented 3 days ago

Update: https://github.com/rust-gamedev/rust-gamedev.github.io/pull/1529 added an embed_video shortcode (thanks @caspark!). I'll close this issue once we've documented that somewhere.