| ▲ | barosl 4 days ago |
| I tested the demo at https://moq.dev/publish/ and it's buttery as hell. Very impressive. Thanks for the great technology! Watching the Big Buck Bunny demo at https://moq.dev/watch/?name=bbb on my mobile phone leaves a lot of horizontal black lines. (Strangely, it is OK on my PC despite using the same Wi-Fi network.) Is it due to buffer size? Can I increase it client-side, or should it be done server-side? Also, thanks for not missing South Kora in your "global" CDN map! |
|
| ▲ | solardev 4 days ago | parent | next [-] |
| Is it Chrome only? On Android Firefox it just says no browser support :( |
| |
|
| ▲ | kixelated 4 days ago | parent | prev | next [-] |
| Horizontal black lines? Dunno what that could be about, we render to a <canvas> element which is resized to match the source video and then resized again to match the window with CSS. |
| |
| ▲ | chrismorgan 4 days ago | parent | next [-] | | What’s that like for performance and power usage? I understand normal videos can generally be entirely hardware-accelerated so that the video doesn’t even touch the CPU, and are passed straight through to the compositor. I’m guessing with this you’re stuck with only accelerating individual frames, and there’ll be more back and forth so that resource usage will probably be a fair bit higher? An interesting and unpleasant side-effect of rendering to canvas: it bypasses video autoplay blocking. | | |
| ▲ | kixelated 4 days ago | parent | next [-] | | It's all hardware accelerated, assuming the VideoDecoder has hardware support for the codec. VideoFrame is available in WebGL and WebGPU as a texture or gpu-buffer. We're only rendering after a`requestAnimationFrame` callback so decoded frames may get automatically skipped based on the display frame rate. I don't think the performance would be any worse than the <video> tag. The only exception would be browser bugs. It definitely sounds like the black bars are a browser rendering bug given it's fine when recorded. | | |
| ▲ | DaleCurtis 3 days ago | parent [-] | | Unfortunately canvas (rgb'ish) can't overlay as efficiently as <video> (yuv'ish), so there is some power cost relative to the lowest power video overlays. It really only matters in long form content where nothing else on the page is changing though. | | |
| ▲ | chrismorgan 3 days ago | parent [-] | | > It really only matters in long form content where nothing else on the page is changing though. Did you not just describe at least 99% of all web video? | | |
| ▲ | DaleCurtis 3 days ago | parent [-] | | If only that were true, battery usage would be much better :) Just consider the prominence of content like tiktoks/shorts/reels/etc alone. |
|
|
| |
| ▲ | kixelated 4 days ago | parent | prev [-] | | Oh and the autoplay restrictions for <video> don't apply when muted. | | |
| ▲ | chrismorgan 4 days ago | parent [-] | | Depends on your configuration. Firefox has a “block audio and video” option. Which this bypasses. |
|
| |
| ▲ | Numerlor 4 days ago | parent | prev | next [-] | | Doesn't show up on screen capture, but there's random rolling quickly flickering lines on my phone, kinda like from analog distortion on old tvs | |
| ▲ | chronicler 4 days ago | parent | prev [-] | | I have got same issue with the black lines |
|
|
| ▲ | nine_k 4 days ago | parent | prev | next [-] |
| The page mentions a lot of Rust code and WASM. Maybe your phone's CPU cannot run WASM fast enough? My Samsung S20 shows no black lines. |
| |
| ▲ | TheMrZZ 3 days ago | parent [-] | | My Samsung S24 Ultra shows black lines too, on Chrome and Samsung Internet. |
|
|
| ▲ | Twirrim 3 days ago | parent | prev | next [-] |
| Chrome on my oneplus ten, I get flickering black lines routinely. The fact they're going from somewhere along the top, down towards the right makes me wonder if it's a refresh artifact maybe? It's sort of like the rolling shutter effect |
|
| ▲ | bb88 4 days ago | parent | prev | next [-] |
| On a mac book air m4 with a 600mbps connection, it's instantaneous and amazing. |
| |
| ▲ | tonyhart7 3 days ago | parent [-] | | with this pc spec and internet speed, I expect its "normal" | | |
| ▲ | bb88 14 hours ago | parent | next [-] | | Let's create a metric, call it "click to streaming time" (CTST). This site was instantaneous. Youtube was not. (Even if it's an M4) | |
| ▲ | maccard 3 days ago | parent | prev | next [-] | | You’d be amazed. A very significant number of websites are anything but instant on my i9 14900k and 1000mbps connection. Our work identity provider/vpn app for 80 people takes about 15 seconds to start up on said machine. Apparently that’s “normal” | |
| ▲ | cchance 3 days ago | parent | prev | next [-] | | You'd be surprised i have 1g/1g and youtube still is not buttery smooth lol on my m3 mac pro, theirs always a noticeable gap between clicking play and it actually starting to stream | |
| ▲ | ofrzeta 3 days ago | parent | prev [-] | | I have the same experience on a Macbook Air M1 (I don't think that matters at all) and 100 MBit/s DSL. |
|
|
|
| ▲ | stronglikedan 4 days ago | parent | prev | next [-] |
| I don't get the black lines on Android/Chrome but it doesn't respect my aspect ratio when I go full screen. Instead of adding black bars to the sides, it excludes the top and bottom of the video completely. |
| |
| ▲ | kixelated 4 days ago | parent [-] | | I am bad at CSS. | | |
| ▲ | Waterluvian 4 days ago | parent [-] | | Managing aspect ratios in conjunction with managing a responsive page layout is one of the darker parts of CSS in my experience. You’re not alone. | | |
|
|
|
| ▲ | cchance 4 days ago | parent | prev [-] |
| Holy shit that starts streaming fast! like WTF |
