bobdvb

Yup, I have a pair of CRS504, so I can learn MLAG and my three node cluster doesn't really tickle the sides of that.

On their video Patrick points out that this is now lower than $1 per Gbps, cheaper than any of the cheapest AliExpress switches.

There was a black and white fantasy TV show called "Adam Adamant Lives!" from the 60s. The BBC always wanted to re-release it but the original contracts for the show were written when no one ever considered re-runs and physical releases. The BBC didn't have rights from the original actors for anything other than the original broadcast. And one of the actors who appeared in a few episodes didn't want it to be shown again, even if they were paid, the BBC didn't want to release a box-set without all the episodes. Eventually they just waited until that actor died and they were then able to release it.

I'm lead to believe that in music there are some similar contractual issues. The rights for some artists were for radio, and physical media, but no one considered streaming or downloads because those things didn't exist. So they have to go back and tidy up the contracts to cover their asses. And it doesn't just have to be the headliner on the recording, you may need to get every performer/contributor.

What's interesting about the rise of the mega weight models is that if you look at the smaller models of the same family you see some significant improvements over time. So there's possibly some trickle down, at least some learning from techniques that is improving things across all model classes.

The other interesting one is how some of the Chinese open weights models have changed licenses that prevent some commercial exploitation of them. That's not closing their doors, but it's some steps towards ensuring their business model is protected.

That's my home lab, it's ugly and I am starting to use MTP breakouts instead because those DACs get in the way so much.

And an extra £40~ per server is irrelevant if we're worried about an outage on £500k-£1.5m of gear and the services they provide.

Some network guys I know prefer fibre even within the rack, just because they don't want the weight and the obstructions in the rack. Apparently more than once the weight of the DACs and the bulk of the cable bundle has caused a problem with NICs.

Personally that surprised me, but I can see where they're coming from.

Film is a chemical medium for storage of images.

Video is an electronic process for capturing images and displaying them.

Before digital video there was analogue video, and analogue video was perfectly possible without digital sampling, or computers. Heck, video pre-dates silicon chips and used to be done with CRTs and valves.

As a broadcast technology architect I agree with you a whole lot on the broader technology statements.

But as a former lecturer, I also think the promise of interactivity is dependent less on the tools than on the people. Authoring interactive learning materials is difficult and while that interactivity is engaging, it's not necessarily great at getting a density of information out there.

The Socratic method is great, but that level of interactivity presumes in advance that you know what questions the student will be asking, otherwise it's just a dumb gate. Branching stories for interactivity are highly labour intensive. I suppose if you use AI you could generate a massive number of videos to cover branching learning, but that's going to still be an intensive operation, especially if you're supervising that.

It's definitely competing in rural areas, but Starlink does suffer from physical limitations on the number of terminals per geographic area.

This is a long standing problem with cellular in urban areas. For example at Clapham Junction train station in London, which is not a terminus but a through station with 17 platforms and around 2000 trains passing each day, the local cell towers struggle to keep up with demand because so many devices pass in and out of the station every few minutes.

For Starlink D2D they can definitely gap fill for rural areas, but people are mistaken if they think Starlink can compete with the majority of the users (who aren't rural). Less than 10% of rural folk in the USA have unreliable signal. That's still an interesting market, because that's somewhere in the region of 3-6mil people. But I want to temper the hype because people seem to think LEO satellite can take over everything, when the reality is that terrestrial connectivity is always going to be better for the majority because of physics.

Spectrum contention is going to be insane in D2D.

Starlink already has to constrain the number of broadband accounts per locale to avoid saturation.

Yeah.

Someone recommended Bunny to me and I looked at it previously based on that but didn't have a use case then. But as someone who regularly recommends vendors for v.big CDN contracts I'm not impressed with their attempts to downplay things.

Yeah, I think when people are getting hundreds, or thousands of channels cheaper from some off-brand name, or from a referral from a bloke down the pub, they know what's what.

It's like buying something from the local market, those Adidas trackies are either a knock-off copy, or knocked-off stolen, but if they're 1/4 the price then they're still going to sell to someone.

The only thing I'd point out is that a security researcher found that a significant number of those grey market pirate boxes they tested had malware on them. So using them can open you up to a whole lot of risk. After all, there's no accountability for those pirates!

As someone in the media technology business, it's very frustrating for me that the pirate streaming industry has co-opted the name IPTV for it's offerings.

But it's not the articles that are driving it, it's the pirates themselves who have done it and the articles following that nomenclature. If you go online the search results for IPTV are very much about pirate services and tools now.

In the previous work I was involved in, I was responsible for technical measures against piracy and had to get comfortable with the services being called IPTV.

YouTube channel DextersTechLab was looking at a piece of retro tech, an interface box for an early broadcast painting system, it acts as a kind of hub for serial tablet, "rat" and other devices. It was built on an x86 microprocessor, some SDRAM and an EEPROM.

Mark gave me the ROM image, I tried using more conventional decompiling methods but the chips were exotic enough that I didn't get good results and as a last resort, I put it into Claude raw. Claude was actually able to parse the binary and sort of decompile it. It was able to tell me what the ports did and what the interfacing protocols were.

It then started making stuff up, clearly trying to impress me, but after a few rounds of reprimanding it and saying how making stuff up wasn't helpful, Claude stuck to facts.

A somewhere over 10 years ago a certain Linux distro company commissioned a company I worked for to make a TV specific distro. The team built something amazing, as a DVR it would have been better than anything on the market. Think people who professionally build software for millions of TVs and STBs for years, getting told they can do anything they need to in order to build a Linux based, open-source focused distro for TVs/STBs/DVRs.

Then that well known distro company realised they couldn't get any TV company to actually license it. So they abandoned the project and asked us to remove their name from it. We then went out to the market and tried to sell it to the TV and STB manufacturers. Europe, Japan, USA, China, we visited everyone we could. I met with so many companies you'd recognise. We couldn't get anyone to license it.

We considered just releasing it, but it needed tidying up and the Distro company still had an option on it, but we didn't get an adequate answer on releasing it for free.

Eventually, under the burden of building something no one wanted to pay for, the company got sold to a Russian company for not enough. And the code was effectively lost inside that organisation.

Writing a distro for smart TVs is harder than you'd think. MStar, who makes >90% of the chipsets, has their own version of GStreamer which is not quite compatible and quite outdated (last time I was involved). Managing the lifecycle of apps in a resource constrained environment with a lean-back experience (e.g. no mouse and keyboard), requires experience. Almost all consumers want Android/AppleTV levels of simplicity, not ArchLinux with a full screen browser.

So it's good when people who know what they're doing maintain the software that goes into TVs.

But getting organisations to pay for the support and development is hard. Especially when TVs are horrifically unprofitable for most companies. And that's the key part that most people don't understand. When I was working on this strategy, most companies had 9 months to make any profit on a new TV model before the market put price pressures enough that each unit sold wasn't helping. TVs have become ridiculously cheap in the past 20 years, and every extra penny the manufacturers spend hurts their bottom line.

Ultimately, this is one of the reasons why TV manufacturers are always looking for new ways of making money (like adverts in menus), because TVs aren't a profitable business to be in. Notice how large screen PC monitors are usually much more expensive than the comparable TV but with less tech?

There's an elder gentleman I talk to in my village, I'm not sure how old he is but well over 70. He worked for old IBM in the 60s.

He's still doing a little coding for charities and he's now loving using AI.

There's very little margin in pure CDN products right now, so they're likely only making money on the value add products. Any money from CDNs is likely going back into maintenance, upgrading and growth.

There's a fine line, reduce quality too far and customer satisfaction drops. Some customers will have a higher tolerance to dropping quality than others, but you've got to draw the line somewhere.

So you do studies, you look at the impact of quality changes to customer churn and then you move the line appropriately.

It depends on which vendor they're using.

It generally occurs as patterns which are slightly in the noise. Good systems pick locations where its easier to hide and turn it off when the scene would expose it. Usually when badly done increasing sharpness in a scene can help reveal it.

Basically, if you can damage the watermark the picture quality is bad enough that it's harming your viewing. You need to compress into crap SD quality to make it hard to detect and even then you'll get something.

You don't even need a complete pattern, if you can get enough fragments you can narrow down the possible identities until you have a high match probability. I.e. partial fingerprints or DNA match.

It was 1999 I think, I was doing a placement at a media company. One of the PAs was heavily pregnant, an old guy in the office said to her "My my Jane, your breasts are coming along nicely."

WTF!

My SIL, this week(!) was told by her supervisor that if she tries to apply for another team and doesn't get that job, she'll be set back in her career progression in her team. Asshole managers are everywhere.

Strippers... brothels... and /hypothetically/ I could tell one story from a well known company where a sales team got in trouble for trying to expense hookers AND blow on a business trip.

That's all post-Millennium

We waste so much resources in storing/transiting data in human readable forms. Ultimately it's binary, we already use software to display it, requiring the data be in forms that are human readable just wastes resources.

If the data spends more time being executed than read by humans it doesn't deserve to be human readable.

Use binary packed data and have an AI write you an interpreter for the structure.

I'll upvote you because you're mostly right.

But to be fair, there is a standard that could have been used for digital video, SDI/HD-SDI, but the transceivers were expensive and it doesn't support any form of bi-directional handshake. There was already prosumer kit, mostly in the US, which had SD-SDI connections as an alternative to component. It didn't get popular in Europe mostly because of SCART.

I was once talking with someone who was very much involved in the process of standardising TV connectivity, a senior engineer at Gennum, and he said it wouldn't have been practical and SDI couldn't have been competitive with HDMI.

Personally, I would have loved the idea of some kind of SDI with return path signalling, like a test probe connector: https://w140.com/tekwiki/images/thumb/8/86/Tek_Interface_Evo...

That's probably how NVidia did it.

But there's very little software involved in HDMI, it's mostly hardware and a control API.

No, the connectors wouldn't be regulated, you're not violating any IP by buying them and there's no prohibition on any of the manufacturers selling them to unlicensed companies. At worst you can assert a patent against the design but there's no specific patent for that design, there are patents for some aspects of the design/implementation but they're hold by the manufacturers of the connectors themselves.

There have been many examples in the past of consumer electronics companies selling things that are electrically and logically compatible with HDMI, but they just have to avoid using the word HDMI.

Probably one thing that the HDMI forum is holding over AMD/Valve is that there's an API to manage some of the functions of the HDMI driver. They could infer that this API is a part of the closed standards of HDMI Forum. But 90% of the threat is about certification and branding I am sure.

I need to post this everywhere:

THIS ISN'T AN IP/PATENT ISSUE!

This is branding and marketing issue. Anyone can implement the spec, it doesn't need to be a cleanroom implementation. It's almost certain that you could license the patents from the patent holders because HDMI doesn't develop it's own patentable stuff, they just get it from Sony, Panasonic, etc.

THIS IS A MARKETING / BRANDING ISSUE.

Saying they don't want an open source implementation is just a smokescreen. 99% of the implementation is in hardware anyway.

The spec is open to them and this isn't an IP issue, it's a branding issue.