Can you get some additional keystrokes added? Namely, the space bar and backspace.
I'm curious about this, too. @Fofer, @Absenm, @KompilerDJ, do you have any insights on comparison of performance, image/sound quality, etc...?
I moved this over to my M1 Mac, and it runs well compared to the buffering I was getting on the old MacBook Air. I'm guessing that Chrome transcoding engine isn't as efficient as Plex?
I know these are early days (and I'm not a programmer, so don't know if either of these are even possible), but a couple random thoughts for down the road:
-
It would be nice if a source has all YouTube TV or other streaming channels, if the Chrome window could somehow stay on "standby" on a low-bandwidth YouTube TV page for faster loading (maybe a settings page, or with the player paused?). The biggest drawback of this right now is that it is even slower to load than the HDMI Encoder method.
-
It would be nice to be able to have a channel under multiple sources, but only show up once in the guide, and, in the background, be able to prioritize those sources. For example, tell Channels to first use any HDMI Encoders to tune a channel, and if they're tied up, then use the Chrome Capture. And even specify it in reverse priority for recording, since load time is less important.
Just spitballing ideas, which may or may not be doable.
I spoke too soon. As I use this more, the initial load time is very slow, but then it tunes into subsequent YouTube TV channels very quickly compared to the HDMI Encoder method — about 5 seconds. Very nice!
I'm only in the preliminary stages, but this method has me more optimistic than the HDMI Encoder method:
- for one, it loads much faster, after the initial load, for YouTube TV. I'm seeing channels loading in about 5 seconds, as opposed to 13 seconds with my HDMI Encoder setup using Onn streaming devices.
- I just tested loading 3 channels on 3 different clients (iPhone and 2 iPads), and my M1 Mac Mini handled it well. The only glitch is that when a new channel loads, any channel already playing on another device will stutter and glitch for a few seconds while that channel loads. Perhaps this will go away if I turn this Mac into a dedicated server machine.
- The cost might be about the same as the HDMI Encoder method, when you compare the cost of a decent Mac or Windows machine, vs. all the encoder and streaming stick hardware you need to buy with the HDMI Encoder method.
1 Like
@tmm1, @maddox, can this change be extended into .strm links? I have an idea...
Or...
FYI, I can already get this to work in VLC:
In Channels Web UX it doesn't launch the video tab in Chrome. With a client, it it gives me a generic error of "Connection Lost" and doesn't even launch Chrome.
2 Likes
I was noticing yesterday the same things:
The video viewport size was small (something like 500x500) (on mac, Linux was a bit better)
The encoding bitrate from chrome never really went above 1000 after manual resize / full screen intervention
Sometimes the video doesn't auto start
Sometimes I get prompted to select my provider (even though I had previously been prompted) (NBC)
Hulu gets angry pretty much every attempt and demands a code that they email
Windowboxing / black space around video as turtletank mentioned
Was letting some of the dust settle and will do some more tests.
PS: not trying to be critical this does show promise!
I've used HDMI for Channels extensively (and contributed to that thread quite a bit).
I think it's too soon to make a fair comparison.
Right now the HDMI solution is far more refined and reliable.
In my experience, the Chrome Capture feature has relatively poor picture quality, the video often doesn't fill the screen (it's windowboxed with borders around all sizes, this is most noticeable on a television), the app often crashes, and a good solution for authentication is not yet in place. It looks very promising going forward, but one Chrome update could permanently break this option entirely. Something to keep in mind.
As a long-term solution, the HDMI encoder setup consumes less energy (compared to a running PC encoding video) and should be way more resistant to changes in DRM (will work until HDCP is replaced). But it's a pile of hardware you have to setup, which is a big negative.
I'm interested in seeing how all of these things evolve over time. It's good to have both options.
4 Likes
Running the “dev” steps, instead of just firing the executable, works.
1 Like
Yeah I'm also running the HDMI setup and it works very well so far, with very low resource usage since it's all done offboard.
I ditched the Docker container and downloaded latest .exe, but when I run it with either Weatherscan or something like NBC News Now it will initially run chrome fullscreen but then revert it back to a window, which means it's postage-stamped on the TV. It does this randomly, if you try it again it runs 'almost' fullscreen (regular video window with small black borders around, it's not fullscreen Chrome). It also spawns a separate chrome-extensions video capture options tab in Chrome for some reason. Chrome is also not minimized, it runs in foreground on server, and the extra tab is not closed out on exit.
The video quality is decent but not comparable to HDMI for NBC News, half the FPS (1920x1080@30 so not as good for motion). The CPU usage with Chrome doing transcode via the EXE is about half of what it was in Docker. Could easily run a couple of these tabs at a time on my old Intel i5 server, but don't think it would handle more.
1 Like
@babsonnexus, I am going to concur with @turtletank that currently I am finding the HDMI to be a more satisfying method. Performance, quality and reliability are considerably better with the HDMI. But again, this current Chrome-Capture method is only a couple of days old of experimental testing and shows so much promise. I think that continue testing by all and more of us here can really refine this method into something very nice. At this time I really do not think there is an honest way of comparing the two methods until the Chrome-Capture has a lot more testing and refinement. I would definitely say I expect this to become a much better asset in the coming weeks and months.
1 Like
Why run that .exe from a command window, is that required??
Why not just "run" the .exe from the Download folder??
That's just for testing purposes, you can run it anywhere and how you want. In a PS or CMD window you can see the program logging output for the run.
Thanks
1 Like
I concur with the video quality. My early comments were based on testing the output on iPhone/iPad, and I’ve since tried it on a television, where some artifacts and degradation are noticeable. I’m waiting for the future where our televisions can scan our eyeballs to determine the quality of our vision (like Apple’s new Vision Pro?) and adjust the quality up and down as needed, as I thought it looked fine on the iPhone. 
Hmm, mine is showing as 1920x1080 @ 60 FPS with Chrome Capture. Using the macOS executable on an M1 Mac Mini, I didn't do anything special. The PQ looks great to me.
So far this is working amazingly well for a day 1 experiment. It tunes in faster than HDMI, and seems a touch more consistent than my dual-encoder HDMI setup as well, because that method still shows "Connection Lost: The connection to the tuner was lost. Press play to try again" about 25% of the time I'm channel surfing. I'm sure everyone's experience is a little different based on whatever ingredients they are using. And our collective fine-tuning and comparing notes will continue!
It also doesn't have that grating/scraping YouTube TV launch sound on every channel change, though. A big win. 
On the other hand, the executable for Chrome Capture crashes occasionally, which isn't as easy to recover from. In that case I have to relaunch the app on the CDVR server.
I'll keep tweaking both methods and see what lasts the longest...
I am also experimenting with different sites to stream from with Chrome Capture. Channels from YouTube TV seems to work better than ones tuned into via NBC.com, for example, and fill the whole TV screen more consistently.
#EXTINF:-1 channel-id="MSNBC",MSNBC
chrome://localhost:5589/stream/msnbc
vs.
#EXTINF:-1 channel-id="MSNBC",MSNBC
chrome://localhost:5589/stream?url=https://tv.youtube.com/watch/ecmqotbt12s
2 Likes
why not just a script, I know it exist because I have one for YTTV. Why couldn't it work for other providers?
1 Like
From what I understand, not all providers allow you to "deep link" in the same way YTTV and NBC. com do, i.e. with a distinct URL for each target channel. At least that is the case with apps and the HDMI for Channels method. So my assumption is that a similar issue exists with some providers and Chrome Capture method?
How do you get that text after …/watch/
Maybe that would work for kox as well for individual channels.
I got it directly from tv.youtube.com. I clicked on the MSNBC live channel, which brought me to this URL:
https://tv.youtube.com/watch/ecmqotbt12s?vp=1gEBEgIwAQ%3D%3D
I then shortened that URL by removing the characters that begin with ?
...leaving me with just the target URL, that works for this. At least for now.
https://tv.youtube.com/watch/ecmqotbt12s
2 Likes