-
-
Notifications
You must be signed in to change notification settings - Fork 543
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Save time&co2(billion views)1.clean YouTube-DOM 2.Auto-Codec *UpdatedNOV23* #1211
Comments
yay. |
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 |
hi, @raszpl TYSM! Which decoding can x220 do before & after? Our GPU & CPU specs data can act flawlessly on confirmed hardware limitations only. (While 'collecting (some) data' doesnt sound like a programming job to some developers, it often is the only solution. Yes, GPU can be checked every time |
or
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
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. |
#1671 implements preliminary mechanism for setting codecs according to detected GPU, plus finetuning codec selection portion of Settings menu. |
hi @raszpl sorry, considering syncing like that / Vivaldi, the brainstorming "GPUs changes rarely" wasnt necessary/misleading (striked now)
Misc, since i started (might just add this to satus.js at once) :
|
hi,
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.)
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 values could put estimated measurements in proportion since Battery correlates with decreased clockspeeds
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?) |
1. Cleaning 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 ...)
[#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?)2. Auto-Codec
Nov2022: Hopefully somebody will enjoy finishing this soon, since the plan is complete & universally relevant...
( We can improve the manual Codec setting: like https://github.com/alextrv/enhanced-h264ify )Done1. 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 , ... )
(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)
at least we dont need to "block h264" (all GPUs support it.)
Afaik only 4 Options make sense:
Prefer VP9, VP8, h264 = Avoid AV1 codec & newer
"( = common in 2023, good for almost everybody, while more GPUs with VP8 & VP9 are still increasing )
Prefer VP8 & h264 = Avoid VP9 & AV1
" ( still very common)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 computersequally 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"
The text was updated successfully, but these errors were encountered: