Live data from Hacker News

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

phoronix.com

31–40 of 186 posts

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

#31
post #20

When I stream 4k from my laptop ffmpeg gets very intense about cpu usage to the point fans are constantly at high speed and it's distracting. I hope this helps in some way. I have a fairly decent specces mid-tier laptop.

I believe ffmpeg can be compiled to support the GPU, if your laptop has one. It works at least for CUDA-enabled GPUs (https://docs.nvidia.com/video-technologies/video-codec-sdk/1...)

Talk with ChatGPT about it and see if you can do it.

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

#32
post #26
post #17

Earlier quoted context omitted.

Like what do you do?

One can use it instead of cat to display text files. Easy syntax to remember. ffmpeg -v quiet -f data -i file.txt -map 0:0 -c text -f data -

I'm dying.

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

#33
post #3

It’s nuts to think that in the near future LLM will be able to do that refactoring in seconds. All we need is enough context window.

Parent post is getting down voted to oblivion but it seems a reasonable belief for someone who is not highly engaged with AI. I have only the vaguest understanding of how it works (and it's probably wrong) and to my layman mind it also seems like a totally fair assumption, based on experience as a user and the constant flood of news. Please explain why the suggestion that a future AI / sufficiently advanced LLM could…

Because refactoring requires understanding, which LLMs completely lack.

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

#34
post #26

Earlier quoted context omitted.

One can use it instead of cat to display text files. Easy syntax to remember. ffmpeg -v quiet -f data -i file.txt -map 0:0 -c text -f data -

I'm dying.

https://www.youtube.com/watch?v=9kaIXkImCAM

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

#35
post #17

Earlier quoted context omitted.

FFMPEG does so much more than just video encoding. I use ffmpeg all day every day, and only a fraction of the time do I actually make a video.

Like what do you do?

you can make gif's with it

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

#36

Earlier quoted context omitted.

Parent post is getting down voted to oblivion but it seems a reasonable belief for someone who is not highly engaged with AI. I have only the vaguest understanding of how it works (and it's probably wrong) and to my layman mind it also seems like a totally fair assumption, based on experience as a user and the constant flood of news. Please explain why the suggestion that a future AI / sufficiently advanced LLM could…

Because refactoring requires understanding, which LLMs completely lack.

> Because refactoring requires understanding, which LLMs completely lack.

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:

Here is heatmap.tsx:

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?

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

#37

If I'm operating a cloud service like Netflix, then I'm already running thousands of ffmpeg processes on each machine. In other words, it's already a multi-core job.

Latency is still valuable. For example YouTube (which IIRC uses ffmpeg) often takes hours to do transcodes. This is likely somewhat due to scheduling but assuming that they can get the same result doing 4x threads for 1/4 of the time they would prefer that as each job finishes faster. The only real question is at what efficiency cost the latency benefit stops being worth it.

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

#39
post #23
post #3

It’s nuts to think that in the near future LLM will be able to do that refactoring in seconds. All we need is enough context window.

I see that you got some responses from people who may have not even used gpt-4 as a coding assistant, but I absolutely agree with you. A larger context window, a framework like Aider, and slightly-better tooling so the AI can do renames and other high-level actions without having to provide the entire changeset as patches, and tests. Lots of tests. Then you can just run the migration 15 times, pick from the one which…

If you think a large refactor is just renaming some stuff then it makes sense you think this.

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

#40
post #20

When I stream 4k from my laptop ffmpeg gets very intense about cpu usage to the point fans are constantly at high speed and it's distracting. I hope this helps in some way. I have a fairly decent specces mid-tier laptop.

I believe ffmpeg can be compiled to support the GPU, if your laptop has one. It works at least for CUDA-enabled GPUs ( https://docs.nvidia.com/video-technologies/video-codec-sdk/1... ) Talk with ChatGPT about it and see if you can do it.

???

Just Google it.

Post reply on HN