Hacker News Reader

Comment by black3r | Hacker News Reader

Can we please stop with the 17MB GIF images used as demos? They use up lots of data immediately as you open the page, and are impractical, you don't know how long the animation is, can't forward/rewind, and you can't press fullscreen on a mobile.

And GitHub supports embedded videos in README.md files, videos are generally smaller than GIF files and their disabled autoplay is a feature = you save your data until you press play.

View on HN

> GitHub supports embedded videos in README.md files

True since May 2021 so I think a lot of people are still finding this out...

In my experience GIF is still the most set-it-and-forget-it way to know a video will play, to get cross-platform support out of mp4 you may have to provide two different codecs. Anyway, not disagreeing with you and most gifs could drop 90% of their size with better choice of resolution and framerate. This readme is particularly egregious doing a screen capture with scrolling.

As for saving bandwidth until you want to play, I haven't tried this yet but it seems adequately clever to wrap a loading=lazy gif inside a details/summary tag: https://css-tricks.com/pause-gif-details-summary/

Not to mention that H264 can take quite a bit of horsepower to decode and play as well (assuming your machine doesnt have a hardware chip specifically for doing just that)

Which machine doesn't? Anything in the last 10 or so years will decode H264 with much less power than GIF because of it. Even a Pi supports it.

My 2014 Thinkpad X1 Carbon (gen 3) doesn't have hardware transcoding as far as I can tell made Zoom and Discord impossible to use for class, especially because there was no way (that I knew of) to disable all video except the presenter. Even playing a YouTube video on it makes it ramp up.

I'm not sure which CPU you have specifically but the lowest-end model of the X1 Carbon Gen3 has an i5-5200U [1] that lists Intel Quick Sync Video support.

From the wiki page for Quick Sync [2]:

> Intel Quick Sync Video is Intel's brand for its dedicated video encoding and decoding hardware core. Quick Sync was introduced with the Sandy Bridge CPU microarchitecture on 9 January 2011 and has been found on the die of Intel CPUs ever since.

I can't confirm but I'd guess your performance issues lie elsewhere than in the h264 decoding specifically.

[1] - https://ark.intel.com/content/www/us/en/ark/products/85212/i...

[2] - https://en.wikipedia.org/wiki/Intel_Quick_Sync_Video

If you check out the generation-codec table in that wikipedia article [1], under Broadwell (I believe that's the 5200U's generation name), it says there is support for AVC (which I believe is H264, I'm not a codec wiz), so that's a really good point. I'm not sure why I've consistently had issues with this on my machine then. I wonder if this is something with a configuration on Linux then?

Thanks for pointing that out. I've looked at this table before and payed attention to HEVC, not AVC, so I believe that's where my mistake came from.

[1] https://en.wikipedia.org/wiki/Intel_Quick_Sync_Video#Hardwar...

AVC is H.264, yes.

Accelerated video decode is often disabled by default on Linux versions of browsers and can be quite dependent on versions of drivers/mesa/X-vs-Wayland/etc.

YouTube by default prefers newer, bitrate saving codecs over old ones if it thinks your CPU can handle software decoding them. On my 2017 Dell XPS 1080p and lower resolutions on YouTube play in software decoded AV1, only 1440p and higher play in hardware decoded VP9, so playing 4K video on YouTube is less taxing for my CPU than playing a 1080p video....

You can use h264ify extension to fix it.

The problem is Zoom and Discord are doing multiple streams. But it really shouldn't be a problem.

H.264, even on the high profile is not CPU intensive on a 2014 machine. Unless you are watching 1080P with 5-10Mbps, which is not the norm for internet video.

Is this really still an issue in 2022? How many people are browsing the internet on a device that can't do hardware H264 decoding?

Some browsers have poor hw decoding support on Linux (their problem, not drivers) but its gotten a lot better recently.

> to get cross-platform support out of mp4 you may have to provide two different codecs

Video codecs are not my area of expertise. Which codecs are these and what tool(s) would you typically use to ensure you provide them?

See this gist and the code comments [0] - basically you just need to know the magic flags to pass to ffmpeg, transcoding the file with all the right settings.

[0] https://gist.github.com/ingramchen/e2af352bf8b40bb88890fba4f...

Author here, sorry for the GIF file. I created it because people were not happy with the video hosted on Youtube. AFAIK, video files did not work when I did this demo. I'll try to improve this in the future.

I wanted to comment on how useful that demo was to me. It did a great job at demonstrating why this is useful and how well it works compared to the native browser implementation. Thank you both for the demo and for the project!

Thanks :)

Would you mind sharing which tools you used to create that demo? It is really well done.

Sure! See here https://news.ycombinator.com/item?id=30530438

Note that you can trim about 1/3 of that video by using an online GIF compressor such as https://www.freeconvert.com/gif-compressor (no affiliation).

GitHub only recently expanded video support from gif to decent video formats, and many github enterprise installs don't have those new features yet. So, keep spreading the word.

I think there is some nuance here.

If the demo sequence is <5 seconds, I have never found myself becoming impatient. Gif is perfect for very brief demos. Anything longer than that and I'd like to have some idea where I am at in the video stream (and other controls as indicated)

Just the "intro" splash takes more than 5 seconds, and it's totally unnecessary

Yes, the gif bothered me too :D

It would seem that this subject is very subjective. However, I admit that I let myself go a bit on the intro and I can understand your point of view.

I wish browsers came standard, preconfigured with warning dialogs that triggered if assets attempting to load were beyond some threshold. That threshold could be decided by the browser vendors group based on some collection of network statistics and be adjusted on an annual basis or so.

> And GitHub supports embedded videos in README.md files

Any documentation on this? Because I have tried to embed video in issues and PRs before, and did not manage. I'm hoping such documentation will explain how this extends to issues and PRs.

In issues its just drag-n-drop.

Giving a massive upvote for this, disappointed and confused to see you've been downvoted here. There's literally no reason to use GIFs like this, and - as you stated, it's massively disrespectful to those not fortunate enough to have broadband connections, but would like access to the information.

Using data so wastefully like this always reeks of privilege to me - especially on something like GitHub. Wikipedia, for instance, never allows things like this.

> disappointed and confused to see you've been downvoted here

Because it's a relatively new feature, and probably, a lot of devs don't know about it (I didn't).

I did this [animated gif] once actually, before the feature was introduced, and I definitely hated it, but I had no choice.

Thanks for bringing this to the general attention, though :)

Sharing a project with the world and taking time to document it reeks of privilege? I really can't understand your reasoning.

https://old.reddit.com/r/firefox/comments/aaek23/how_to_stop...

The issue is mainly with mobile browsers, as mobile data is expensive..., Firefox on iPhone doesn't have about:config.

FYI, I updated the README page. Now, it includes a mp4 video weighting ~9MB.

Reply on news.ycombinator.com