My Browser Builds (Part 4)

[Ben Markson]

On 12/3/2022 at 7:24 PM, PPeti66x said:

Issues with Youtube persists.

I'm just going to throw this out there with no warranties.

For YouTube I've been using a script that replaces the video with its embed version. I originally did this to combat the constantly changing way adverts seem to get delivered but I think it also provides a less resource intensive experience when viewing the video.

It's a little clunky. YouTube is extraordinarily aggressive with the way it starts a new video which led me to using the setInterval which waits for the video container to arrive properly before injecting the iframe with the embed.

// ==UserScript==
// @name         Replace Youtube Video
// @namespace    BenMarkason
// @version      1.0
// @description  Replaces youtube video with embed video
// @author       Ben Markson
// @include      https://www.youtube.com/*
// @grant        none
// @run-at       document-start
// ==/UserScript==

if (location.href.includes('/embed/') == false)
{
    document.addEventListener('DOMContentLoaded', function ()
    {
            console.log('Blocking Redirect');
            window.ytInitialData.onResponseReceivedEndpoints = null;
    });

    t = setInterval(function()
    {
        eli = document.getElementById("player-container-outer");
        if (eli == null)
        {
            console.log('Waiting...');
            elj = document.getElementById("movie_player");
            if (elj != null) {elj.remove();}
            return false;
        }

        console.log('Element is ready');
        clearInterval(t);
        if (eli.hasChildNodes()) {eli.removeChild(eli.children[0]);}
        YTiD = location.href.split(/(vi\/|v%3D|v=|\/v\/|youtu\.be\/|\/embed\/)/)[2].split(/[^0-9a-z_\-]/i)[0];
        height = getComputedStyle(document.querySelector('.ytd-watch-flexy')).getPropertyValue('--ytd-watch-flexy-min-player-height');

        iframe = document.createElement("iframe");
        iframe.type = "text/html";
        iframe.width = '100%';
        iframe.height = height;
        iframe.src = 'https://www.youtube.com/embed/' + YTiD;
        iframe.setAttribute("frameborder", "0");
        iframe.setAttribute("allowfullscreen", "true");
        eli.appendChild(iframe);

    }, 100);
}

It has a small annoyance. If you select a new video from the right-hand bar, the page will change but the embedded video will not. To update the embedded video you will need to refresh the page.

Someone more skilled at JavaScript may be able to do a better job.

Ben.
 

Edited January 22, 2023 by Ben Markson
added fullscreen support (allowfullscreen)

[NotHereToPlayGames]

32 minutes ago, Ben Markson said:

I'm just going to throw this out there with no warranties.

Sweet!  Looking forward to giving it a try.

I'm intrigued by the idea of a YouTube "front end".

But what I observed here on an Intel Core2 Quad Q6700 @ 2.66 GHz with 3.24 GB available RAM (XP x86 SP3) is that YouTube itself is "easier" on the CPU.

Forcing 480p h.264 on both --
Piped CPU ranged from 26% to 39%
YouTube desktop (with Enhancer for YouTube extension + Proxomitron) CPU ranged from 16% to 24%

Enough of a difference that my CPU fan would flip back and forth between low RPM and medium RPM on Piped but would stay at low RPM on YouTube desktop.
The CPU fan flipping back and forth on Piped made for a very unpleasant listening experience compared to YouTube desktop.

[RainyShadow]

You could try to replace www.youtube.com with music.youtube.com , but some videos won't start with this.

[PPeti66x]

@Ben Markson

Problem is, that this bug probably is not specific to youtube (but it is near always trigered by opening any youtube video, so easy to test). So killing it probably resolves many other unidentified crashes.

I am using useragent for youtube "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" - this may be important if someone needs to reproduce the behaviour.

[VistaLover]

16 hours ago, VistaLover said:

Main caveat being you can't move the player marker to the right (to skip parts of the video),
at least I haven't found a way to myself... Basically affects long videos, only ...

... Double-clicking rightwards on the player surface will advance the video 10s forward; double-clicking leftwards will rewind the video 10s - yep, not practical ...

[UCyborg]

9 hours ago, NotHereToPlayGames said:

But what I observed here on an Intel Core2 Quad Q6700 @ 2.66 GHz with 3.24 GB available RAM (XP x86 SP3) is that YouTube itself is "easier" on the CPU.

Forcing 480p h.264 on both --
Piped CPU ranged from 26% to 39%
YouTube desktop (with Enhancer for YouTube extension + Proxomitron) CPU ranged from 16% to 24%

You, sir, are defying laws of physics. My test was VP9, 1080p@60FPS, I'd say % are hovering between 28% and 37% for Piped and between 36% and 47% for YouTube. Got an old quad-core from AMD (Phenom II X4 920 with slightly bumped frequency - 3 GHz). Also our configs on YouTube differ. Interestingly, that older script you suggested some time ago - YouTube CPU Tamer, can't say it still reduces CPU usage, adds a bug with spinning circle if you switch away and video starts again and you come back to it.

[NotHereToPlayGames]

46 minutes ago, UCyborg said:

YouTube CPU Tamer, can't say it still reduces CPU usage

I do not use that anymore.  I think I used it for like half a day and ditched it.  Not sure if I tried VP9, will revisit.

[NotHereToPlayGames]

My "normal" YouTube listening relies on this -

I also intentionally force 480p unless I switch to full-screen then the video switches to 1080p.

I hide comments and chat for both YouTube desktop and for Piped.

[NotHereToPlayGames]

Testing with this setup for Piped (what I am attempting is an apples-to-apples comparison, h.264 480p compared directly with h.264 480p) -

[NotHereToPlayGames]

Hovers around 18% on YouTube desktop -

[NotHereToPlayGames]

Piped hovers around 31% -

[NotHereToPlayGames]

I get the same CPU pertentage range when I switch from h.264 to VP9 on Piped.

I cannot right-click in Piped and access YouTube's "stats for nerds" screen but my "normal" setup for YouTube runs circles around Piped.

RAM consumption is basically identical, but CPU has to work "twice as hard" on Piped versus YouTube desktop.

Granted, my frame of reference is my "normal" setup compared to the same exact video then played on Piped in Incognito.

[NotHereToPlayGames]

YouTube desktop in Incognito also runs the CPU less than Piped on my system.  21% average but did have one minor 54% surge as the sidebar was loading.

Could easily be Intel versus AMD as far as that goes.  (ran out of profile temp attachment storage so no pic for this one)

 

edit - and could also be Chrome vs Mozilla - I posted Chrome-variant YouTube/Piped comparisons in the Mozilla-variant thread, ooops  

 

Edited December 4, 2022 by NotHereToPlayGames

[NotHereToPlayGames]

Did find this as a good read on h.264 vs VP9  --  https://bitmovin.com/vp9-codec-status-quo/

I rarely (if ever) exceed 480p resolution on my computer so perhaps the better compare-contrast would be to test 1080p videos.

But I can say I would not be using my Core2 Quad Core computer for that, lol.

Edited December 5, 2022 by NotHereToPlayGames

[Mathwiz]

13 hours ago, Ben Markson said:

I'm just going to throw this out there with no warranties.

For YouTube I've been using a script that replaces the video with its embed version. I originally did this to combat the constantly changing way adverts seem to get delivered but I think it also provides a less resource intensive experience when viewing the video.

It's a little clunky. YouTube is extraordinarily aggressive with the way it starts a new video which led me to using the setInterval which waits for the video container to arrive properly before injecting the iframe with the embed.

[script removed for brevity - see post above for script source]

It has a small annoyance. If you select a new video from the right-hand bar, the page will change but the embedded video will not. To update the embedded video you will need to refresh the page.

Someone more skilled at JavaScript may be able to do a better job.

Ben.

Thanks, Ben; this gave me another chance to try out Violentmonkey - and I was surprised when Violentmonkey refused to open an editor to let me add a new script! Turned out I'd been automatically updated to v2.13.3, which claims to be compatible with FF 52+, but is no longer compatible even with St 55 (FF 53-based) and thus, I presume, no longer compatible with St 52 either. I'm guessing ViolentMonkey's author Googlized some of his JavaScript in v2.13.3 and, uh, forgot to update the MinVersion.

Had to go to AMO and download v2.13.2. This version still works with St 55. Not tested with St 52; try it and see. If it doesn't work, just try v2.13.1 and then v2.13.0 if that doesn't work either. Also remember to disable automatic updates of this extension.