Save time&co2(billion views)1.clean YouTube-DOM 2.Auto-Codec *UpdatedNOV23*

[ImprovedTube]

1. Cleaning the DOM?

• [#Research] : SO: modify-dom-before-loading can we reduce the DOM?

  • https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/webRequest/filterResponseData

  • XMLHttpRequest ( Example (As Manifest 2 stays this year after all & unlimited maybe?)

  • the first script element on youtube ( document.body.getElementsByTagName("script")[0].innerHTML includes 400kb of uncessary JSON data "videoDetails": { "adPlacement":{ ~400kb } (next to meta data, translationLanguages)

Easy alternative/additionally

• [#Feature Request]: "popup player only" ( = Bypassing youtube-com/watch?= with youtube.com/embed ...)

  • And our own liteweight video page / tab / window?
    • some channels forbid players embedded beyond the Youtube.com URL (such as VEVO & SME) (can we notice in advance? & to make them default to a popout player)

• [#Feature Request] : Mobile Youtube Always on Desktops! (mobile DOM is less heavy & video is bigger. M.youtube already is xx% of youtube usage. Much cleaner. Mainly only misses the transcript buttion. Technically just requires a tablet/android user-agent (or cookie-flag?)

  • most of our page-layout&-style features (CSS) wont work there but could be ported.."
  • our own enhancements for desktops based on m.youtube: "lite-theme" / "compact-mode" for YouTube. - Based on the mobile m.youtube.com? (+2)new 'classic'/retro - maybe) #868

2. Auto-Codec

Nov2022: Hopefully somebody will enjoy finishing this soon, since the plan is complete & universally relevant...

• 0. ( We can improve the manual Codec setting: like https://github.com/alextrv/enhanced-h264ify ) Done

• 1. Now, mostly we can also auto-select the efficient codec/s depending the user's GPU or Device-name and what youtube offers per video (this feature should be or first one ON BY DEFAULT)

• NIVIDA https://en.wikipedia.org/wiki/Nvidia_NVDEC#GPU_support

• https://en.wikipedia.org/wiki/Unified_Video_Decoder#Format_support

• ( https://en.wikipedia.org/wiki/VP9#Hardware_implementations , ... )

  • Equally our manual setting can be disabled for newest GPUs, even if a user set it earlier, or is about to import old settings.)
  • the manual feature should be less relevant then and less prominent(=potentially confusing to people who don't know much about it)
  • We already always detect GPU (see "about") (while would be enough to detect/confirm the GPU rarely, at installation or when importing settings)

• Finally we can also contribute all of this to 'h264ify' (and ask them to exchange a link, increasing smart YouTube usage overall) @erkserkserks )

---

• 1.1 The automatic feature can show Feedback: intelHD6500 :: avoiding AV1
  or (rarely:) GeForceRTX3050 :: all codecs supported / avoiding none

• 1.2 Name: 'wasteful CPU Rendering: avoid when possible' (right now we call it "blocking" but it should accurately be avoiding only of course)

2. Manual options: we don't need a switch for each codec (as now), because these options are all that makes sense:
   at least we dont need to "block h264" (all GPUs support it.)

Afaik only 4 Options make sense:

1. "Prefer VP9, VP8, h264 = Avoid AV1 codec & newer"
   ( = common in 2023, good for almost everybody, while more GPUs with VP8 & VP9 are still increasing )
2. " Prefer VP8 & h264 = Avoid VP9 & AV1" ( still very common)
3. " avoid VP8 codec and newer(=VP9 & AV1)" ( same as h264ify) (=old now & getting rarer)

(while also blocking h.264 is unnecessary if not counterproductive/bad in "enhanced h264ify" - as it is the oldest Codec.)

---

so for typical resolutions, if Hardward rendering isn't available we should just fall back to another codec.
Except for 4k, which is only available in VP9 or AV1:
4k needs to be blocked by default, if:

• neither AV1 nor VP9 GPU rendering are available. (then ~99.8%+ of CPUs² cant render it either)
  ²:CPUs that could already playback 4k fluently, also have newer graphics integrated....
  The only (very) rare case where an old GPU's user could playback 4k+ fluently is combined with a strong/new: Intel Xeon E5 E7; AMD EPYC; Opteron X**** A**** (Server CPUs without integrated GPU - or multi-CPU systems with 2-4 CPU's)

• viewport is < 1440p ( then loading 4k is a waste. 8k and 4k screens are rare)

  • [ ] then we could also hide the 4k item from our player quality setting and from Youtube's player. Because it will only be a waste and heat up their computers

• equally we could allow to force 1080p when the view port is > 800p. - So if a user selected 1080p always, on a 1080p screen, where viewport is 720p, then video 720p is enough and more migth be useless. For these users we could only apply 1080p at full screen mode.
  Subject of debate: BrainStorming: making our quality/resolution feature more meaningful. #1580 @raszpl 👍

• "old GPU BUT 8K screen AND 4 * Xeon E7"

[mrangjunboon2019]

yay.

[raszpl]

2. I just pushed a patch fixing codec overrides forcing h264 doesnt work | fix included in the reply #1668 working CODEC/30FPS override for issues/1668 #1670.

Problem with detecting GPU and auto disabling codecs is Browser doesnt give you hard information about what is hardware accelerated and what isnt. Same GPU can accelerate with one driver and not with another (case of HD 3000 in my mediacenter Thinkpad x220). Thats why h264ify doesnt F around and just does whats promised on the tin. The best you can do is query browser for codecs and going off of "true" vs "maybe" from .isTypeSupported() .canPlayType(), maybe adding GPU/Platform to your heuristics. Imo sensible solution would be suggesting optimal combination of codecs to the user on first run or first time he opens settings with explanation to whats going on and how to verify yourself. Maybe optional rechecking GPU/platform once a day/week to catch situations where someone upgraded hardware - but this might be dicey with browsers allowing Syncing settings/extensions across multiple computers.

Blocking 4K just because someone has 1080p monitor is bad idea as I mentioned in #1580

[ImprovedTube]

hi, @raszpl TYSM! Which decoding can x220 do before & after?

Our GPU & CPU specs data can act flawlessly on confirmed hardware limitations only.
A GPU built before a codec was released can not hardware-accelerate that codec, so that codec can always be avoided by an eco-feature if the same resolution is provided in an older codec - or if the user's cpu alone can't possibly keep up with the higest resolution) (+ in some cases, like Thinkpad x220, additional limitations could optionally be considered, if the new driver isnt released for every OS or so)

(While 'collecting (some) data' doesnt sound like a programming job to some developers, it often is the only solution.
Assuming this feature isnt written elsewhere already, then it would surely help other applications too in budgeting user's GPU & CPU ressources and can include overall performance info.)

Yes, GPU can be checked every time
We are not yet syncing storage #1656 (but people import/export.)

[raszpl]

Which decoding can x220 do before & after?
depending on the driver can be

HD Graphics 3000 Video Acceleration Information
Decode h264 baseline 64x64 to 1920x1088 pixels
Decode h264 main 64x64 to 1920x1088 pixels
Decode h264 high 64x64 to 1920x1088 pixels

or

Video Decode: Unavailable

Never know which driver user uses. Hardware decoded h264 is better, but software decoded VP9 can be slightly faster.

Browsers are syncing whole configs. Vivaldi

Currently, Vivaldi supports synchronisation of the following items:
Extensions

so you cant blindly force Extension settings without expecting eventual trouble when user shares profile between multiple computers (maybe even a phone/tablet).

Imo the best that can be offered is a mild suggestion during install and when user is browsing Player Settings. Display tooltip with detected GPU and info about its hardware capabilities when hovering over "Codec h.264" and "Codecs", replace "Avoid CPU rendering when possible" submenu with something like "Auto Optimize Codec for low CPU usage" button. Maybe even make it display red when detected GPU is on a list with no hardware VP9/AV1 decoding etc, and green if settings already match GPU hardware capabilities. Ill think about ways of implementing that.

[raszpl]

#1671 implements preliminary mechanism for setting codecs according to detected GPU, plus finetuning codec selection portion of Settings menu.

[ImprovedTube]

hi @raszpl sorry, considering syncing like that / Vivaldi, the brainstorming "GPUs changes rarely" wasnt necessary/misleading (striked now)

• The extension can just re-read the GPU name every time a AV1 or VP9 video runs
  Yes, guessing can be modest. Yet 100%-true, helpful & harmless things can be applied without asking.
  Since they can be distinguised from those where we might not be able to guess. GPU by GPU. But even auto applying the feature for a single GPU Chip model would be motivating work.
  • in other words, of course any solutions with >1% false-positives is a debatable plan, yet if a particial situation has no false positives that will still be a perfect solution. Perfect for its scope.
  • For most setups, increasingly, there will only be one option, and all existing drivers making use of the hardware. Easiest in new machines, where only AV1 wont be hardware rendered, and both CPU and GPU stay cool, so its just about saving some, little electricty, only worth it on scale, million times per day.
    • While, of course sometimes, especially for old machines & HD Graphics 3000
      the best we can do is inform the user about drivers. Thats if the unclear situation has a significant proportion. I.e. was x220's old driver ignorant? is that common or 1 in 1000 HD graphics 3000 users only... (whats rare might be hard to decide, yet reasoned to ignore. - While HD Graphics 3000 keeps getting rarer, the savings in time & electricity are bigger, as is the shift of heat inside the Machine.

---

• more/auxiliary data:

  • hardware or software rendering might usually be identifyable / guessable by change in memory-usage
    performance.memory.totalJSHeapSize, performance.memory.usedJSHeapSize, performance.memory.jsHeapSizeLimit

  • JS sees number of cpu cores to guess CPU efficency by number of cores

  • old OS, old Browser, no memory upgrade: old driver is likely.
    The feature could run some mini benchmarks of 0.005 seconds each to guess if CPU load is >90% or <40% or so.

---

---

Misc, since i started (might just add this to satus.js at once) :

connectivity could also be considered 
resource.domainLookupEnd - resource.domainLookupStart
resource.connectEnd - resource.connectStart
resource.responseEnd - resource.startTime

& navigator.getBattery()

[ImprovedTube]

hi,

we cant :) because in order to be fast enough to patch YT we need to have block list prepared in advance

yes, might take 10ms to create canvas & see GPU name, so for example every time a video stops playing. (or just some proportional interval as we said.)
( While other hardward & software values, can make an near-unique Fingerprint, wont take a 1 millionth of a second, so mostly you can be sure nothing changed... )

0.1s benchmark ... consent,

sorry, *0.1ms? 😀 Could run a bunch of times randomly in the last 1 second of a video playback, and the first second beyond, to learn the difference.

battery

battery values could put estimated measurements in proportion since Battery correlates with decreased clockspeeds

afaik YT does that automatically

yes (just tending to be complete 😀 / wondering to call satus a separate project, shall we? Will satus make it to a hackernews post within X month/years from now?)

[ImprovedTube]

https://stackoverflow.com/questions/23666003/any-way-to-undelete-pull-request-comments 🙉 good night