Forem: Martin Stark

nvoc - linux OC/UV cli utility for RTX-50 series

Martin Stark — Fri, 26 Sep 2025 08:22:26 +0000

I got tired of having to create multi-line scripts for applying a semblance of overclocking/undervolting on Linux, so I wrote a cli app that does it in a single line, example for 5090:

sudo nvoc -c 200,2820 -o 900 -m 3000 -p 105

-c = min,max core clocks
-o = graphics offset
-m = memory offset
-p = power limit

Since it's only possible to set a full curve offset on Linux (there is no per-voltage offset like in MSI Afterburner), and I don't want my idle clocks to be ~1100mhz, I wanted a utility to quickly apply and reset the OC when I need it.

NVIDIA kindly removed the ability to query GPU voltage from their Linux APIs. Due to that, I think the only way to simulate MSI Afterburner-like behaviour, where you can have default idle clocks (200mhz) and have an offset for higher load scenarios, would be to set up an elevated service that applies the OC as soon as the GPU goes above ~2000mhz, and resets the OC if the clocks drop down below 2000mhz for a number of seconds.

Functionality

# Show GPU information
nvoc info

# OC
sudo nvoc -c MIN,MAX -o OFFSET -m MEM_OFFSET -p POWER_LIMIT

# Reset
sudo nvoc reset

# Dry Run
nvoc -c 200,2800 --dry-run

info output:

$ nvoc info
Driver 580.82.09
0: NVIDIA GeForce RTX 5090
Blackwell v16777240
GPU: 1177MHz
GPU Offset: 960MHz
Mem: 15501MHz
Temp: 56°C
Power: 45W
Power Limit: 600W (104% of default)
Power Range: 400W-575W (hard limit: 600W)

Client Side Ad Insertion Crash Course

Martin Stark — Wed, 29 May 2024 12:43:28 +0000

This guide acts as a quick overview of concepts relevant to CSAI, it is not meant to act as a complete tutorial.

What is CSAI?

Client Side Ad Insertion means that the app on the user's device is responsible for fetching and displays advertisement as part of the streaming experience. This is in contrast to Server Side Ad Insertion, where the ads are stitched into the video on the server.

VMAP

The VMAP is fetched or polled by the client, it is parsed to check when an ad break should occur.

VAST

The VAST document is fetched and parsed by the client, it represents the content of an ad break.

The VAST document can contain several types of ads. For example: video, images, and companion links.

The VAST specifies how an ad should be tracked. It says which events need to be sent to a tracking server in order to verify if and how much of the ad was watched and/or interacted with.

Displaying the Ads

When it is time to show the ad to the user, it is usually handled by pausing the content stream, creating a new video element, overlaying it on the content stream, and playing the ad(s). When the ad break is finished, remove the ad specific video element and resume the content stream.

Interpreting HTML5 Video Events

Martin Stark — Mon, 13 Mar 2023 12:05:55 +0000

When building a HTML5 web video player, it tends to need a user interface, quality of service tracking, user interaction tracking, and sometimes ad tracking. To achieve this, the HTML5 Media Event standard needs to be interpreted.

After building multiple web video players, and having worked on more than one iteration of an event interpreter, something didn't feel right. Things weren't kept DRY.

When repetition strikes, it's usually a good idea to do something about it.

Creating a Media Event Filter

Enter @eyevinn/media-event-filter, a filter that interprets HTML5 media events in a way that makes sense.

This filter aims to provide a single source of truth that can be used across player engines and native browser playback.

Whether using one or multiple player engines, like Shaka Player, HLS.js, or dash.js, the filter will output a standardised event sequence. It does so without relying on events output by the player engine, giving applications a single, player agnostic, source of truth for video playback state updates.

Example Implementation

import {
  getMediaEventFilter,
  FilteredMediaEvent,
} from "@eyevinn/media-event-filter";

const videoElement = document.createElement("video");

const mediaEventFilter = getMediaEventFilter({
  videoElement,
  callback: (event: FilteredMediaEvent) => {
    switch (event) {
      case FilteredMediaEvent.LOADED:
        // handle loaded
        break;
      case FilteredMediaEvent.BUFFERING:
        // handle buffering
        break;
      case FilteredMediaEvent.BUFFERED:
      // handle buffered
      // ...
      default:
        break;
    }
  },
});

// Create a player, using your engine of choice
const player = createPlayer(videoElement);

// Load a manifest and play
player.load(url).then(player.play);

// Call when done
mediaEventFilter.teardown();

Live Example

See a barebones React + Shaka + Media Event Filter example over at codepen.

Production Readiness

While making the filter open source is recent, it has been battle tested for years. With millions of playback sessions, multiple third party tracking systems have been validated using the filter.

Event Sequence

The sequence follows the Eyevinn Player Analytics Specification, which maps directly to many popular tracking service provider SDKs.

Sample event sequence comparison, using <video autoplay> with Shaka Player in Firefox, excluding timeupdate:

Native	Filtered	Comment
ratechange	—	Shaka sets playback rate to 0 to control buffering
progress	—
durationchange	—
resize	—
loadedmetadata	—
ratechange	—
progress	—
loadeddata	—
canplay	—
play	—
playing	—
canplaythrough	loaded	video is ready to start playing
—	playing	video is playing, play event missing due to autoplay
progress	—
...	—
progress	—
pause	pause	manual pause
progress	—
seeking	seeking	seeking while paused
ratechange	—	Shaka sets playback rate to 0 to control buffering
play	play	Play requested during a seek
waiting	—
progress	—
progress	—
progress	—
seeked	—
canplay	—
playing	—
canplaythrough	—	video element thinks it can start playing, but playback rate is 0
progress	—
ratechange	seeked	shaka returns playback rate to normal
—	playing	video is playing again after previous pause
progress	—
progress	—
pause	pause
progress	—
play	play
playing	playing
progress	—
progress	—
seeking	seeking	seeking while playing
waiting	—
ratechange	—
progress	—
progress	—
seeked	—
canplay	—
playing	—
progress	—
canplaythrough	—
progress	—
ratechange	seeked	seek finished, video is rolling
progress	—
progress	—
progress	—
progress	—
ratechange	buffering	buffer empty, shaka sets playbackrate to 0
progress	—
progress	—
progress	—
canplaythrough	—	video element thinks it can start playing, but playback rate is 0
progress	—
ratechange	buffered	shaka returns playback rate to normal
progress	—
...	—
progress	—
seeking	seeking
waiting	—
ratechange	—
progress	—
...	—
progress	—
seeked	—
canplay	—
playing	—
canplaythrough	—
progress	—
ratechange	seeked
progress	—
progress	—
progress	—
durationchange	—
progress	—
seeking	seeking	seeking within buffer, no ratechange
waiting	—
seeked	seeked	seek finished
canplay	—
playing	—
canplaythrough	—
pause	pause
ended	ended	end of stream reached
emptied	—

Download it at npm.

Contribute at github.

HTML5 subtitles with dynamic width on OSX

Martin Stark — Thu, 17 Mar 2022 15:28:46 +0000

If you've run into subtitles taking up 100% width of the HTML5 video player window, which is common in Chrome or Safari on OSX, here is a neat styling trick:

::-webkit-media-text-track-display {
  // prevent subtitles from taking up 100% width
  // while remaining centered
  width: auto !important;
  left: 50% !important;
  transform: translateX(-50%);
  // prevent unexpected line breaks, since the  
  // above styling will otherwise force 50% width
  // on the subtitle element
  white-space: pre;
}

This code will center the subtitle element, make sure it keeps a dynamic width, and prevent unexpected line-breaks.

Since the fix maintains native subtitle rendering, it allows for operating system level accessibility options to be applied.

The equivalent of componentWillMount using React hooks

Martin Stark — Thu, 29 Apr 2021 12:29:48 +0000

Given that

the goal is to execute some code once, before the ui is updated
componentWillMount is deprecated (1, 2, 3), and that the suggested replacement is executing code in the constructor
code executed before the return statement of a functional component is implicitly run before rendering it
the rough equivalent of mounting a class component is the initial call of a functional component

The solution would be

Calling a function in the body of the functional component once. This can potentially be achieved with useState, useMemo, or useEffect, depending on the timing required for the use case.

Since the code needs to run before the initial render is committed to the screen, this disqualifies useEffect, as “The function passed to useEffect will run after the render is committed to the screen.” 4.

Since we want to guarantee that the code will only run once, this disqualifies useMemo, as "In the future, React may choose to “forget” some previously memoized values and recalculate them on next render" 5.

useState supports lazy initial state calculations that are guaranteed to only run once during the initial render, which seems like a good candidate for the job.

Example with useState:

const runOnceBeforeRender = () => {};

const Component = () => {
  useState(runOnceBeforeRender);

  return (<></>);
}

As a custom hook:

const runOnceBeforeRender = () => {};

const useBeforeInitialRender = (fn) => {
  useState(fn);
}

const Component = () => {
  useBeforeInitialRender(runOnceBeforeRender);

  return (<></>);
};

The runOnceBeforeRender function can optionally return a state that will be available immediately upon the first render of the function, triggering no re-renders.

See use-once on npm.