[HN Gopher] The most unhinged video wall, made out of Chromebooks
___________________________________________________________________
The most unhinged video wall, made out of Chromebooks
Author : varun_ch
Score : 240 points
Date : 2025-03-01 17:54 UTC (5 hours ago)
(HTM) web link (varun.ch)
(TXT) w3m dump (varun.ch)
| szvsw wrote:
| Congrats on delivering this fun project! I do a lot of work with
| synchronizing media content across devices so it's always fun to
| see the solutions people come up with. You probably came across
| them in your research, but the industry standard way of creating
| a synced video wall like this is with BrightSign media players.
| The total cost for purchasing them and the screens would for 20
| displays could easily end up in the 10s of thousands, so big
| kudos to you guys for finding a way to make this work with
| recycled devices.
|
| If you are ever interested in working on some mediasync-related
| codebases hit me up! We hire devs to do freelance contracts
| fairly often.
| varun_ch wrote:
| Thank you!
|
| I didn't get the chance to mention them in the blog post, but
| yes we checked out the price tags on the commercial solutions
| :) It's crazy! I've always wondered how much of the cost is
| hardware vs software... and I would imagine professional
| digital signage is also designed for reliability longevity and
| all that.
| szvsw wrote:
| Reliability is a big part of it - but they are not really all
| that expensive for what you get IMO, especially in an
| enterprise context. A BrightSign is effectively a very
| sandboxed Linux box (you can SSH into them!) which has
| extremely reliable video and audio output, plus a huge amount
| of customizability, networking, scripting etc - plus various
| fleet provisioning/management software that goes with it. In
| terms of $/minute, the amount you pay ends up being
| vanishingly small IMO.
|
| Your main "cheap" alternative to a BrightSign is a Raspberry
| Pi, which is definitely cheaper, but has its own host of
| issues to deal with.
| mikepurvis wrote:
| Is the separate box thing because of commercial display
| realities? Certainly at trade shows and the like I mostly
| see people just plug a usb stick into the smart tv from
| wal-mart and play their sizzle reel off of that.
|
| Is there some incentive to not just bake a small arm
| computer into each display?
| szvsw wrote:
| I entirely work with museums, where there are lots and
| lots of considerations in re: rendering device. The
| considerations for eg a commercial display are a little
| different, but I don't have experience with working with
| those sorts of clients, so my answer is from the
| perspective of the media art context.
|
| Having a separate box is just good separation of concerns
| - you can hook it up to whatever kind of projector you
| like (one projector might cost as much as $100k!), or you
| might need to use an analog display device (eg a CRT
| monitor) which certainly won't have any USB/SD
| compatibility, in which case you will need some sort of
| hardware to convert signals appropriately. The separation
| of concerns just gives you much more flexibility.
|
| Additionally, as mentioned before, you can network the
| boxes, which lets you do things like creating multi-
| channel synchronized video art installations.
|
| Most BrightSigns also have GPIO pins on them, so I've
| even done things where I've synchronized kinetic art to
| the video playback.
|
| You can write entire custom applications for your
| brightsigns (or plugins to the BrightAuthor configuration
| engine) - it's just its own self contained platform, so
| there are a lot of benefits to having it be agnostic to
| the display.
| dividuum wrote:
| I operate a digital signage company based around the Pi.
| Curious what problems you run into. SD cards?
| szvsw wrote:
| The deprecation of OMXPlayer has been problematic for
| one, since I rely on some custom applications which need
| to be able to have some fairly precise/low latency
| requirements between when you tell it to start playing vs
| when the playback actually starts, etc. I haven't found a
| suitable mechanism which meets our reqs on a Pi for
| controlling/playing videos yet since that deprecation.
|
| The lack of a regular HDMI output is mildly annoying but
| not really a problem. Audio configuration is _sometimes_
| problematic, usually not...
|
| If a client wants to use their own Pis, getting them
| provisioned with our software isn't always the easiest if
| the customer is techno-phobic (though that's partly on us
| - RPi usage is relatively infrequent for our customers so
| we haven't put the time/energy into docs and into baking
| an image etc).
|
| I love Pi's, but they just that extra bit more finicky
| than BrightSigns which are hyper optimized for our use
| case and prevalent in our customers' equipment rooms
| already.
| dividuum wrote:
| > The deprecation of OMXPlayer has been problematic for
| one, since I rely on some custom applications which need
| to be able to have some fairly precise/low latency
| requirements between when you tell it to start playing vs
| when the playback actually starts, etc. I haven't found a
| suitable mechanism which meets our reqs on a Pi for
| controlling/playing videos yet since that deprecation.
|
| Yeah. The Pi3 -> Pi4/5 jump was quite a massive change in
| how things work. I've been writing my own playback engine
| for 10 years now and that one was quite challenging.
| Precise playback start is something my software supports:
| You control everything in Lua and can, for example,
| preload a video and then start it based on either
| internal logic or based on an external trigger. Up to the
| Pi3, my software also supports dynamically adjusting the
| HDMI clock, so the vsyncs of multiple displays are
| synchronized. Customers have been using that for almost
| 10 years for video wall playback.
|
| If you go with the hosted version of the software,
| provisioning is as simple as extracting a single 60MB zip
| file to an empty SD card and placing that into the Pi. If
| needed you can even use the API to preconfigure that ZIP
| file to include settings like WiFi.
| nolist_policy wrote:
| By the way, you can use Chromebooks and -boxes for digital
| signage (and kiosk) as well if you manage them with Google
| Cloud.
| jojol wrote:
| Excellent work, and a great read.
|
| What videos did you end up playing on this after your testing was
| complete? Do you have any recordings to share of this in action?
| varun_ch wrote:
| Thank you! We haven't figured out what to play on it yet
| actually - I think the plan is to build out all the tools so
| that our school can create and upload their own videos (eg.
| montages of students work - this is in the Design workshop
| after all) to display on the screen. It could be self-service
| even after we graduate in June.
| i-am-gizm0 wrote:
| I think a very wide game of Pong would be fun!
| xmprt wrote:
| If you want to spend more time on this I think one fun idea
| would be an infinite bouncing DVD logo. Just sync the
| location of the logo every time it bounces so all devices
| have a consistent view and then the individual screens can
| compute whether and how much of the logo to show and at which
| location.
| IshKebab wrote:
| That's an insane amount of work. Enjoy having free time while it
| lasts...
| nashashmi wrote:
| I wonder if it would have been easier to make just one video and
| have the computer zoom in to different parts of the video. And
| then run the video simultaneously through a web browser
| gloflo wrote:
| At least computationally that would be much more expensive and
| might not work well with weak devices or power saving goals.
| dividuum wrote:
| You very very likely won't be able to decode a 13660x768 video
| fast enough.
| xmprt wrote:
| The toughest part of this wasn't setting up different videos to
| play on each screen but rather the "run videos simultaneously
| through a web browser" part. So even if you could decode and
| process such a large video on those Chromebooks, it wouldn't
| help with video sync. That's not to mention the other
| challenges with installing the software and getting it to
| autoload on startup.
| greggman25 wrote:
| I worked at Google when Chromebook shipped. They put out a call
| for decorations for the lobby and I proposed something similar to
| this but they said "no" :( Maybe because I asked for 40-64
| machines :P
|
| I would not have tried to sync video though. Instead I'd have
| made time based animations and use the network the synchronize
| the clocks.
|
| you can see an example here:
| https://www.youtube.com/watch?v=64TcBiqmVko
|
| It's 8 machines running Chrome. The only thing synchronized are
| the settings and the time.
|
| They machines do not have to be in a grid either. I was inspired
| by the Boston Science Museum's virtual aquarium
| szvsw wrote:
| If you have fixed media (as opposed to realtime dynamically
| generated or streamed etc) this trick can go a very long way -
| or even if it is generative, if the time is used to drive the
| animation. It just requires good clock sync, like you said,
| which can be non trivial (especially if audio is involved where
| desync of even 20-30ms becomes very noticeable). But yeah, with
| NTP/PTP you can get v v far.
| bazzargh wrote:
| A similar thing from many years back: the junkyard jumbotron let
| you assemble a random collection of displays to display their
| portions of a much larger image
|
| https://github.com/mitmedialab/Junkyard-Jumbotron
|
| Video https://youtu.be/cAUtSVSTbzU?feature=shared
| varun_ch wrote:
| The Media Lab makes so much random fun stuff. I feel like it
| would be fun to remake this with modern web tech. (doing the
| alignment photo over email does sounds like fun too hehe)
| fitsumbelay wrote:
| so awesome
| layer8 wrote:
| Literally unhinged, the Chromebooks.
| mezzman wrote:
| This one from 2013 when the Chromebook Pixel was announced was
| pretty great too. https://tomsepe.com/portfolio/google-pixeltree/
| cjaackie wrote:
| I remember when someone adapted the Chromebook Pixel display as
| a standalone monitor [0]. I'm sure it made the rounds here. I
| was almost tempted to do it myself because, at the time, it was
| a nice 4:3 screen. I couldn't , the Chromebook Pixel was too
| beautiful to hack up.
|
| [0] https://hackaday.com/2015/05/02/excruciating-quest-turns-
| chr...
| cjaackie wrote:
| fun to see the 'write protection' screw and think back to my
| toshiba chromebook, it also got coreboot thanks to Mr. Chromebox.
| Linux never ran quite right on the eMMC sadly...
___________________________________________________________________
(page generated 2025-03-01 23:00 UTC)