FFmpeg lands CLI multi-threading as its "most complex refactoring" in decades

Plus, computers aren't quad cores any more, people with powerful streaming rigs probably have 8 or 16 cores; and key frames aren't every second. Suddenly you're in this hellish world where you have to balance latency, CPU utilization and encoding efficiency. 16 cores at a not-so-great 8 seconds of extra latency means terrible efficiency with a key frame every 0.5 second. 16 cores at good efficiency (say, 4 seconds between key frames) means terrible 64 second of extra latency.

What make you think that? I very much care about encoding performance (for a fixed quality level) for offline use.

Also to be able to seek anywhere in the steam without decoding all previous frames.

It also has a lossless codec ffv1 where the entropy coder doesn't reset, so it truly can't be multithreaded.

I'd assume if each thread is working on its own key frame, it would be difficult to make b-frames work? Live content also probably makes it hard.

(Plus a couple more "legacy" encodes with PIFF instead of CENC for ancient devices, probably.)

New tech advances, sure, they probably do re-encode everything sometimes - even knocking a few MB off the size of a movie saves a measurable amount of $$ at that scale. But are there frequent enough tech advances to do that more than a couple of times a year..? The amount of difficult testing (every TV model group from the past 10 years, or something) required for an encode change is horrible. I'm sure they have better automation than anyone else, but I'm guessing it's still somewhat of a nightmare.

Youtube, OTOH, I really can imagine having thousands of concurrent ffmpeg processes.

Subjectively, me compressing my holiday video is much more important than Netflix re-compressing a million of them.

as long as it works for them...

  ffmpeg -v quiet -f data -i file.txt -map 0:0 -c text -f data -

I guess you could use AI to help create a coccinelle semantic patch.

[1] https://en.wikipedia.org/wiki/Coccinelle_(software)

I most certainly have not. At work, I do greenfield development in a specialized problem domain, and I would not trust a model (or, for that matter, a junior developer) to do any kind of refactor in an acceptable manner. (That aside, there's no way I'm goingto expose company code to any sort of outside party without the approval of upper management).

At home, I program for fun and self-improvement, and a big part of both is thinking hard about problems. Why would I want to wreck that with asking a model to do it for me?

Interesting.

Here's a sample question I just asked the AI:

We are working on a React mapping application. I am going to give you two components from this application. Our goal is to extract functionality to deduplicate code

We can make a single base component, extract code to hooks, or any other strategy which you think is appropriate

Here is travel.tsx:

<snip>

Here is heatmap.tsx:

<snip>

And here is the response:

To deduplicate code and improve maintainability between the `TravelMap` and `Heatmap` components in your React mapping application, we can identify common functionalities and extract them into reusable hooks or components. Here's a strategy considering your code:

1. *Extract Common Hooks*: Both components use similar hooks for managing markers, popups, and map references. We can create custom hooks that encapsulate these functionalities.

2. *Create Shared Utility Functions*: Functions like `initialViewState`, which are identical in both components, can be moved to a separate utility file and imported where needed.

3. *Refactor Map Layers and Sources*: The way map layers and sources are handled is quite similar in both components. A custom hook or component to manage map layers and sources would be beneficial.

4. *Generalize Popup Handling*: The popup handling in both components can be abstracted into a custom hook or a higher-order component.

5. *Combine Common Styling*: Shared styles, such as `MAP_CONTAINER_STYLE`, can be moved to a common CSS module or a styled-component that can be reused.

6. *Refactor Event Handlers*: Functions like `onMapClick`, `onMouseMove`, and `onMouseLeave` have similar structures. These can be part of a custom hook or a utility function with configurable parameters.

7. *Legend and Live Region Components*: These components are used in a similar way in both `TravelMap` and `Heatmap`. Ensure they are designed to be reusable with different props.

8. *Refactor Map Initialization*: The way the map is initialized and configured is quite similar. This can be abstracted into a custom component or hook.

### Example Implementations:

#### 1. Custom Hook for Map Markers:

```typescript // useMapMarkers.ts import { useState, useCallback } from 'react';

export const useMapMarkers = (initialLat, initialLng, world) => { // Similar marker logic from your components // ...

  return {
    marker,
    onMarkerDrag,
    onMarkerDragEnd,
    updateMarkerPosition,
    // other marker related states and functions
  };

#### 2. Shared Utility Function:

```typescript // utils/mapUtils.ts export const initialViewState = (map, mapType) => { // Implementation }; ```

#### 3. Custom Hook for Map Layers and Sources:

```typescript // useMapLayers.ts import { useState, useEffect } from 'react';

export const useMapLayers = (props) => { // Logic to handle layers and sources // ...

  return {
    dataLayer,
    patternLayer,
    // other layer related states and functions
  };

#### 4. Generalized Popup Handling:

```typescript // useMapPopup.ts import { useState } from 'react';

export const useMapPopup = () => { // Popup logic from your components // ...

  return {
    popupState,
    openPopup,
    closePopup,
    setPopupData,
    // other popup related states and functions
  };

### Integration:

Once these hooks and utilities are created, integrate them into your `TravelMap` and `Heatmap` components. Replace the duplicated logic with calls to these shared resources. This will significantly reduce code duplication and make future maintenance easier.

### Testing and Refinement:

After refactoring, thoroughly test both components to ensure that all functionalities work as expected. Watch out for any edge cases or specific behaviors that might be affected by the refactoring.

For those suggestions, I might use five out of eight of them, and probably do one or two things differently. But you cannot, with a straight face, say the model did not understand. It clearly did. It suggested reasonable refactors. If being able to refactor means understanding, I guess we have understanding!

I could continue with this conversation, ask it to produce the full code for the hooks (I have in my custom prompt to provide outlines) and once the hooks are complete, ask it to rewrite the components using the shared code.

Have you ever used one of these models?