kierank

The AMD Alveo ASIC isn't actually available to buy yet. Their older Alveo FPGA (formerly NGCodec) is available but is not competitive by any metric apart from marketing noise.

How would you edit a sports highlights package?

SpaceX deliberately doesn't make money as they want to invest as much as possible into going to Mars.

Sure, when there's a consistent experience between browsers with decent echo-cancellation amongst other audio processing I'll be happy to move.

I don't want to get stuck on lowest common denominator WebRTC, that pales in comparison with a native application like Zoom.

This isn't the fault of RPi as such. It's the fault of the whole embedded industrial SBC industry whose boards are expensive, long lead time, have awful software and are poorly documented.

"bwdif" is a hybrid of "yadif" and "w3fdif"

It's easier to do an update with a single security fix rather than an update that rolls in a ton of new functionality that ends up breaking your device. Seen this time and time again with OS/dependency update.

Yes, there's substantial value in being able to have a specific bugfix and not have to upgrade an application and a ton of dependencies.

Absolutely spot on here, there's no reason for the obsession HN (and the wider internet) has with upgrades in these kinds of environments. These are not environments where you can tolerate unplanned downtime, this isn't a silly web app running in us-east.

FFmpeg has a lot of assembly language that can be added to:

https://blogs.gnome.org/rbultje/2017/07/14/writing-x86-simd-...

The RFC does not mandate that the RTCP timestamp (which you need to handle wraparound if you join a stream halfway through) needs to be the same as the video/audio clock.

In practice this clock is generated via the PC clock so it isn't the same clock at all: https://chromium.googlesource.com/external/webrtc/+/lkgr/mod...

RTCP SRs are sent quite rarely (defaulting to 1s for video, 5s for audio) so quite poor for precise clock recovery required in professional applications.

Probably practical implementations just use buffer fullness to drive their resampler.

Author here:

>I have had no problems with measuring NTP drift. As the clocks change I would measure.

Did you read the article? NTP is not the same as the video/audio clock which is what you need to care about. I have to now take a drink even though it's 5am here in Singapore.

> Common Clock for Audio and Video

No idea what sequence numbers have to do with clocks here. Maybe you mean a mapping of absolute time to relative time in RTCP? If the RTCP SR value for absolute time is using NTP (or any other wrong clock as it's not mandated to match audio/video clock), then it's by definition impossible to know how to sync audio and video after several wraparounds of each RTP timestamp.

> WebRTC provides playoutDelay.

This is not the same as a defined, video frame or audio sample accurate delay (ten milliseconds as a unit...) to allow for variations in frame size to maximise quality. It also appears to mix up network delays vs VBV delays. They are separate delays and are handled at different layers of the stack.

> You can transport anything you want via RTP or DataChannels

None of this is standardised and therefore requires control of both ends. Also high end applications need Uncompressed Audio and for the above RTP timestamp reasons this can't be precisely synced with video.

Just to be clear this is is a patch and is not necessarily going to be accepted into FFmpeg.

Take a flight and use the onboard wifi to visit websites.

There was a brief period in 2020 before the chip shortage when 100/25G was affordable on eBay.

Unfortunately the industry I am in (multimedia) is slowly getting invaded by all the awful embedded development practices, binary blobs, custom forks, hacks galore. It's ruining an area where there was clean code, no blobs.

Also Linus' ARM rant for good measure: https://lkml.org/lkml/2012/7/15/133

And imagine the stuff they didn't upstream...I'm sure that's part of some magic SDK that only works on one version of glibc and kernel.

Embedded development is substantially worse when it comes to out of tree unmaintainable kernel patches, compiler forks, binary blobs around terrible hardware etc etc.

Completely incomparable to web, enterprise and mobile (android and co is a part of the embedded trashfire of course). They all have their problems but are minor league compared to embedded development hell.

Embedded development takes BoM reduction to the extreme and piles all the technical debt onto software.

Seems to miss the part where it's ok to create terrible software in embedded, with custom forks of everything, binary blobs galore. But it's all fine as it shaves a few cents from the BOM.

I do wonder if anyone actually read the Amazon post before creating their hot takes.

The crux of the post is simple and obvious to anyone who's ever actually developed "low-level" (used loosely) video libraries. Microservices are not suited for video because exchange of video between microservices is substantially more costly than bits of JSON.

Is there any good way to do OAuth on a headless system? I want to be able to run batch jobs without a browser involved. There's OAuth for devices but that has limited real world use.

It's similar to how many "media" and "video" companies just call FFmpeg

Surely the problem with GSO is that you're now bursting UDP over the wire as fast as possible and that will be problematic for downstream switches?

Multimedia isn't something that is easily represented on a CLI.

This is as realistic as the moon rocket in my back garden.

This solves all the problems:

https://blogs.gnome.org/rbultje/2017/07/14/writing-x86-simd-...

Most professional network cards have PTP support and a grandmaster is cheap enough or your colo provider will provide PTP as a service.

"The Web Audio API exposes access to the audio subsystem’s hardware clock."

I can't speak for Windows and Mac but in ALSA this isn't possible.

Or just have a way for a chipset to expose it's clock instead of all the methods people use to guess using buffer fullness.

No consumer chipsets that I know of allowing drifting the clock to match an external clock source so PTP is a non starter. And I've not seen many pro sound cards with drifting support either.

Ooooh something I know quite a lot about:

So for AES67 receive, in principle no as PTP stack exists for RPI yet. You could cheat like the majority of manufacturers do and just play the audio as it arrives instead of using the timestamps. You'd also need a way of drifting the audio out clock to match the frequency of the PTP clock. If you didn't care about bitexact audio, you can resample, though ALSAs clock measurement kind of sucks.