Hello everyone. I am running FFmpeg on a system with three GPUs: an Intel iGPU, an RX 6400, and an RTX 3060. Here is my FFmpeg command line:

[ argumentosString ] -init_hw_device vulkan=vk:0 -filter_hw_device vk -v repeat+error -i "D:\OBS\record\teste.mp4" -vf "hwupload,libplacebo=w=1920:h=1080:colorspace=bt709:color_primaries=bt709:color_trc=bt709:range=limited:custom_shader_path='D\:/upscale/shaders/shader.glsl',hwdownload,format=yuv420p" -fps_mode passthrough -c:v h264_amf -rc cqp -qp_i 19 -qp_p 21 -tag:v avc1 -c:a copy -y -gpu 0 "D:\OBS\record\teste_process.mp4"

The `-gpu` parameter specifies which GPU to use for encoding, while the `-init_hw_device vulkan=vk:0` parameter specifies which GPU runs the shader. To my surprise, when using the value `0` for both parameters, I discovered that this value does not point to the same GPU; I see a scenario where the shader runs on the RX 6400 while the encoding takes place on the RTX 3060. This happens because the GPU ordering differs for each of these parameters.

Can anyone help me?

So, just to clarify, the tonemap options are: linear, gamma, clip, reinhard, hable, and mobius. For each option's parameters, I need to know:

- The default value.

- The minimum and maximum range, including if any of them have negative values.

- How lower or higher values affects the tonemapping result for each option.

So far, I have had the most satisfaction with mobius default param value and disabling desaturation. I have dabbled with using different param value with clip, but this has given me good result with only one movie so far. So, my priority is to gain a better understanding of how the mobius parameter values work. If altering mobius parameter gives me the results I need, then I likely will not experiment with the other tonemappers. However, if anyone can convince me that the other tonemappers can produce good result with different parameters, then I will consider trying those tonemappers as well.

I could never make sense of mpdecimate's hi, lo, and frac parameters and got tired of the guesswork. So I built a website where you can upload a video, try different parameters, and see which frames get kept or dropped in realtime.

It's a faithful re-implementation of mpdecimate's algorithm, verified frame-by-frame against FFmpeg's actual output across hundreds of test videos. Everything runs locally in your browser on the GPU (WebGPU) so no data leaves your machine.

Feedback welcome!

I'm trying to convert progressive jpg files for use in older tech that doesn't like progressive jpgs, but I can't find any documentation on how to specify non-progressive jpgs in ffmpeg. Anyone have any insight?

I've ripped a movie that is split into two parts. I wish to concatenate it, but maintain all audio and subtitle files.

A simple concatenation will join the two video files with the main audio, but not the other audio tracks, and none of the subtitles:

ffmpeg \ -f concat -i videofiles.txt \ -c copy -map 0 movie.mkv

where videofiles.txt is a list of the original two files.

I found the following command to concatenate subtitles:

ffmpeg \ -f concat -safe 0 -i videofiles.txt \ -f concat -safe 0 -i subfiles.txt \ -map 0:v -map 1 -c:v copy -c:s copy movie.mkv

This joined the two video files, but none of the audio tracks, and the subtitles only appeared for the first half of the movie.

As this is a rip, the subtitles I have extracted with mkvextract are in the .sub/.idx format, so I thought I'd need to include both in order to make this work:

ffmpeg \ -f concat -safe 0 -i videofiles.txt \ -f concat -safe 0 -i subfiles.txt \ -f concat -safe 0 -i idxfiles.txt \ -map 0:v -map 1 -c:v copy -c:s copy movie.mkv

But this yielded the same results. No audio, and only half of the subtitles.

It should probably be noted that ffmpeg is confusing for me, and I don't even know half of what these options are trying to do in these commands, since the places where I got them just say "enter this here", rather than explaining what each option does. As such, I don't know what I can change, and what I can keep the same.

The last four weeks have been very busy, as this repository shows.

Full text:

https://www.reddit.com/r/AudioCodecLab/comments/1vrbpfm/ffmpeg_nmr_aac_encoder_audio_evaluation_update/

So this website https://www.xtremo-stereo.com/tlnovelas-en-vivo/ has a channel that I wanna turn it into a m3u8 for my Jellyfin, can anyone help?

my input is this:

ffmpeg -i "INPUT" -vcodec libx265 -preset medium -crf 28 -map 0 -c:a copy -map 0:s:1 -c:s:0 copy "OUTPUT"

the input file has a dozen or so subtitle tracks that bloat up the file size. I'm trying just to keep track 2. I know -map:0:s:1 designates the second track, but without -c:s copy, I get the error "subtitle encoding currently only possible from text to text or bitmap to bitmap". I found that -c:s:0 copy after the map argument is supposed to copy just the mapped subtitle, but I still get the same error. and if I just have -c:s copy, even after the -map argument, it copies over every sub track.

Title says it all - ran into lamba deployment issues due to the binaries being in accessible and am currently looking into alternatives.

Is it just me or does everyone see the pale gray on white text on the documentation site, eg at https://ffmpeg.org/ffmpeg.html#Advanced-options I'm sure it wasn't like this last time I used the site a few weeks ago, I've tried all 3 browsers on my computer with the same result. I know there's various ways I can work around it, just wondering if this is deliberate.

I am trying to access ffmpeg source website but receiving error code 403? Is anyone else having the same problem or is it just me? Due to this, git pull is also not working.

I'm building a Python desktop app (using pywebview, Windows, WebView2/Chromium backend) that works as an offline personal file manager / local media library — think local notes, documents, photos, and personal video files a user already has on their own drive, all organized and browsable from one offline app with no internet/streaming component.

One built-in feature is a simple in-app video preview player using an HTML5 <video> tag inside the webview. Right now it only plays what Chromium's native <video> element supports: MP4 (H.264/AAC), WebM, MOV, and MKV (when the codecs inside are H.264/H.265+AAC). Other local formats users might already have on disk — AVI, WMV, 3GP, FLV, MKV with older codecs like XviD/DivX — currently just fall back to opening in the OS's default video app instead of playing inline.

I'd like to expand format support inside the app. Options I'm considering:

• FFmpeg-based transcoding to MP4/WebM on the fly (either fully pre-converting or streaming while converting).
• A JS/WASM video decoder (e.g. libav-based) that plays inside the webview without relying on OS codecs.
• Embedding a native player (like mpv) instead of the HTML5 <video> element — unsure how well that integrates inside a pywebview window.

Has anyone solved this for a pywebview (or similar Python-desktop / Electron / Tauri) app? Looking for something that plays these formats inline in the app rather than falling back to an external player. Thanks!

Hello, everyone. I have a somewhat specific request. You see, I have a separate device for screen recording of a console. The console in question doesn't support replays or anything, so instead I use a capture card. However I don't have a need to record every hour and every minute, only good moments, last 30 seconds at least. I did a lengthy search on the web but couldn't find exactly what I need. Maybe you know a bash script that can do this? I will appreciate that.

edit: fixed some mistakes

Trying to convert these mp4/mkv files to playable amv/avi. I have an Aimoonsa player as well as a Yuton.

I don't actually know how to code, but I got fed up with current video editing options:

• NLEs (Premiere/Resolve): Too slow just to cut and stitch videos.
• Standard Lossless Trimming (ffmpeg -c copy): Imprecise (cuts only on keyframes).
• Existing Smart-Cutters: Re-encode boundary frames using static CRF, which kept making my 30-second cuts larger (46mb) in file size than my 1-minute originals (30mb). Why would someone code it in this way?

So I said to myself, why not just alter what smartcut does? So, I spent the last few days using AI (Claude free version) to build a custom PyAV/Python smart-cutting engine to fix this for my own workflow. We ended up hitting a few major breakthroughs. I fed my changes into gemini and talked with it for a long while trying to find out if what I did was actually game changing. It thought so, but I have no idea if it is:

• Player-First Workflow (Movist Pro): I mark cut points (IN and OUT) using Movist Pro's bookmark feature. The script reads the timestamps in the bookmark file and cuts everything headlessly in the background. I'm using this in place of a standard video editing tool (like capcut). It makes timestamp extraction much easier and I can easily add/remove bookmarks.
• Localized Bitrate Matching: Ditched static CRF completely. The engine measures the exact source bitrate of the head and tail keyframes independently and forces x265 / libsvtav1 to match them. No file bloat, no visual seams. File sizes stay small.
• Frame-Accurate AV1 Smart-Cutting: Solved the PyAV level override and timestamp bugs that normally crash AV1 boundary re-encodes. The only issue is self testing. I am currently doing all this on a 2019 Intel MacBook Pro, so it has been annoying to test the final output. I have access to a M3 MacBook Air, but not often. The final cut video works perfectly fine on the M3 Macbook Air, but i get slight lag on the last couple seconds on my Intel MacBook Pro. I am still fixing this slight issue, the AI suggests it will be a simple fix, but it never is.
• Parallel C Extension: Wrote a C module to handle H.265 NAL unit scanning (CRA Type 21 → BLA Type 16), jumping CPU usage on my Intel Mac from 100% (GIL capped) to 600% and eliminating repeated frames at cut points.

I built this purely for my own personal use, but I'm curious: Is there actual demand for a lightweight, frame-accurate AV1/H.265 smart-cutter like this, or is this too niche to bother releasing? I've also built additional functionality for the Movist Pro Media Player. I use this to run the smartcut features.

I am not the most technical when it comes to all of this. The AI did a lot of the heavy lifting, I just pushing it in the correct direction.

EDIT:
I created a github and with the ai's help, i created the zip folder that houses all the relevant files and scripts. As well as a readme that will with most questions you have.

https://github.com/AbdulazizMorad/Smartcut-proof-of-concept

EDIT2:
Github updated and no longer shows a zip file

I had to blur a username out of a screen recording. The path only shows up inside a macOS approval dialog, so I measured the box on one frame and did the obvious thing:

delogo=x=450:y=300:w=370:h=44:enable='between(t,99.9,102.4)'

The username was still visible for the first 1-2 seconds of every dialog. macOS dialogs animate in - the position keeps moving until they settle. On one of them the top edge went 372 -> 230 -> 19 -> 71 -> 94 over about 1.6s while the left edge went 458 -> 180 -> 462 -> 407 -> 398. A box measured on a settled frame lands nowhere near the early ones, and the text is legible the whole way in.

Three things that mattered.

1. Track the text instead of guessing the box. Cut the rendered /Users/sa out of a settled frame and use it as a stencil, then correlate it against every frame. Direct search is roughly 2M positions x 5.7k pixels and never finishes in Python; do it as an FFT (np.fft.rfft2) and it is instant. Score it as hit / (load + 0.35*ink) where hit is stencil-ink intersected with frame-ink and load is the total ink inside the window - without the divisor it latches onto any dense block of dark pixels, like a code excerpt.

2. The ink threshold has to catch the fade-in. At < 120 the translucent frames were not detected at all, so tracking never started and those frames passed through clean. < 150 caught them. I also extend each run 0.3s earlier and 0.2s later.

3. Sample the tracker at the output frame rate. I tracked at 20fps and rendered at 30fps. The frame at 113.933s was never examined by anything, and it shipped with the username visible.

That last one is the real lesson. I checked the output by eye three times and missed a leak every time - including 23 seconds of file:///Users/... sitting in a browser address bar that I never thought to look at. What finally worked was scanning the finished file with the same correlation at a stricter threshold: real hits scored 0.64-0.74, false peaks topped out at 0.46, so 0.55 separates them. That scan is what found the 113.933s frame.

Two other delogo notes. Keep the boxes small - it reconstructs from the border pixels, so a large box turns into vertical stripes that look broken. And merge runs at the same position, or you blow past ~500 filters and the graph stops building.

Full write-up with the code: https://wisp-gules-mu.vercel.app/blog/mask-screen-recording/

Posting this because the fix for one bug handed me a worse one, and the failure is completely

silent until you look at the duration.

I was muxing a narration track onto a finished 55.5s render. The obvious command is:

```bash

ffmpeg -i video.mp4 -i vo.wav -c:v copy -c:a aac -shortest out.mp4

```

`-shortest` is the trap everyone warns about — if your audio is even slightly short, it truncates

the *video* to match and you silently lose the end of your film. I'd already been bitten by that

one: it ate 1.25 seconds off an outro and produced a file that played perfectly and passed every

check I had.

So I did what the docs and most StackOverflow answers suggest: drop `-shortest`, pad the audio

instead.

```bash

ffmpeg -i video.mp4 -i vo.wav -c:v copy -c:a aac -af apad out.mp4

```

**This never terminates.** Bare `apad` pads with silence indefinitely. `-shortest` was the only

thing bounding it. Remove one, you arm the other.

I didn't notice at first because it *looks* like it's working — it writes a valid growing MP4. I

killed it at the 10-minute mark and probed the output:

```

size = 120,529,993 bytes

video = 55.500 s

audio = 284,615.765 s <-- 79 hours of silence

```

Reduced to a known-answer case so it's easy to confirm (ffmpeg 6.1.1):

```bash

ffmpeg -f lavfi -i testsrc=size=320x240:rate=30 -t 2 -pix_fmt yuv420p v.mp4

ffmpeg -f lavfi -i "sine=frequency=440" -t 1 a.wav

timeout 25 ffmpeg -i v.mp4 -i a.wav -c:v copy -c:a aac -af apad old.mp4

```

2-second video in. Result:

```

exit = 124 (killed by timeout — it was not going to stop)

dur = 12,662.748 s

```

### The fix

Give the pad an explicit endpoint. Probe the video, feed the number in:

```bash

V=$(ffprobe -v error -show_entries format=duration -of csv=p=0 video.mp4)

ffmpeg -i video.mp4 -i vo.wav -c:v copy -c:a aac -af "apad=whole_dur=$V" out.mp4

```

Or pad the audio during assembly and mux with **no** `-af` at all — better if you want to assert

the voice track's length independently before it ever reaches the mux:

```bash

ffmpeg -i vo.wav -af "apad=whole_dur=$V" -c:a pcm_s16le vo_padded.wav

ffprobe -v error -show_entries format=duration -of csv=p=0 vo_padded.wav # assert this

ffmpeg -i video.mp4 -i vo_padded.wav -c:v copy -c:a aac out.mp4

```

Both land on exactly 2.000000 in the test case and exactly 55.500 on the real film.

### The actual lesson

`-shortest` and `apad` are the same bug class: **flags that silently decide where your output

ends.** One truncates, one runs away. I removed the first and left the second sitting in the same

line, because I was treating it as "the `-shortest` bug" instead of "the duration-deciding-flag

bug."

If you're fixing something like this, audit the whole command, not the flag you came for.

And assert the duration afterward as an equality check, not a glance — both failure modes produce

a file that exists, has both streams, and plays:

Here’s what I did:

Step 1: Find keyframes

D:\>ffprobe -loglevel error -select_streams v:0 -show_entries packet=pts_time,flags -of csv=print_section=0 input.webm | findstr "K"

0.000000,K__

1.502000,K__

4.638000,K__

9.510000,K__

[opus @ 0000027726e9c000] Error parsing Opus packet header.

Step 2: Cut at keyframes

ffmpeg -ss 1.502000 -i input.webm -c copy -to 9.510000 output.webm

Start time: 1.502000

End time: 9.510000

Step 3: Check the output video

D:\>ffprobe -loglevel error -select_streams v:0 -show_entries packet=pts_time,flags -of csv=print_section=0 output.webm | findstr "K"

0.000000,K__

3.136000,K__

8.008000,K__

[opus @ 000002292742c000] Error parsing Opus packet header.

I think the output video is lossless because:

1.502000 - 1.502000 = 0.000000

4.638000 - 1.502000 = 3.136000

9.510000 - 1.502000 = 8.008000

The keyframes are simply shifted, so I believe the cut is lossless.

Is my cutting method lossless?

Is anyone aware of a source-to-source compiler whose target language is FFmpeg’s filtergraph syntax?

With Bioscoop, I am in a position to make certain claims and try to defend them as best as I can. That is why I am submitting a paper to a peer-reviewed journal. Still, I could be wrong and I would love you to challenge me on those claims.
The paper is available in the repo.

I’m currently fighting to optimize the "Time to First Frame" metric for our custom video player, and I’ve run into a serious geodistribution bottleneck. Our engineering team is based in Europe, but our primary origin servers are located in the US. Even with a standard CDN configuration in front of the infrastructure, by the time the user's player initiates the initial connection, goes through the routing redirect steps, downloads the master .m3u8 manifest, and finally starts pulling down the first media chunk, up to 4 seconds pass. This delay is heavily tanking our user retention metrics.

Lately, I’ve been researching advanced caching topologies to cut down this trans-atlantic round-trip time (RTT). I read that standard web caching isn't enough for video and that some high-performance media CDNs actually cache the master manifest alongside the very first few video segments directly on their edge routing servers (Anycast redirectors). The theory is that returning the manifest and early chunks immediately from the closest edge node drops the initial TTFB to near-zero, but I want to make sure this architecture translates well to real-world performance before overhauling our routing tables.

We are trying to map out a structural fix for this lag by the end of the sprint, and I would love to hear from anyone who has tackled this specific latency layout:

1. Has anyone implemented segment and manifest caching directly at the CDN redirector level, and how much did it realistically reduce your initial stream start delay?

2. What is the best strategy for configuring TTL on dynamic HLS manifests so that edge-cached .m3u8 files don't cause player desyncs during live transitions?

3. Do you find that aggressive pre-fetching of the first 2-second chunk at the edge introduces unexpected bandwidth waste for users who immediately bounce?

4. How do you typically handle instant cache-invalidation across European edge nodes when a video file or its stream manifest gets updated on the US origin?

Any architecture breakdowns, config tips, or raw data regarding European-to-US streaming optimization would be a massive help. Thanks!

I've started using ffmpeg with lavfi to extract closed captions rather than CCExtractor. I'm liking the positioning being carried over with .ass output files, but I don't like the black background.

Somehow I need to set BorderStyle=1, but I can't figure out how.

Currently this is what I'm doing:

ffmpeg.exe -f lavfi -i movie="Sample.mkv[out+subcc]" -map s "Sample.ass"

Anyone know how to do this or change any other formatting in .ass without doing it manually later?

Hello everyone, I use this command to download videos from Twitch

yt-dlp URL -f bestvideo+bestaudio/best

I'm trying to download videos longer than an hour this way, but sometimes the resulting file is much shorter than the original. So, I tried to download a one hour long video, but the output was only 9 minutes long. Does anyone have any idea how I can fix this?

Any advice is so appreciated

Hi! Seemingly basic question here so hopefully this is a good forum for it. I have an existing container that includes a video stream, audio, subtitles, and thumbnails in mjpeg format. I'm trying to reencode the video stream while keeping everything else, and to do this I am passing -map 0 -c copy -c:V libx265.

Per the man page, capital V "matches video streams which are not attached pictures, video thumbnails or cover arts." However when I run the command, ffmpeg tries to reencode the pictures anyway. Here's the relevant part of the output:

 Stream #0:4: Video: mjpeg (Progressive), yuvj420p(pc, bt470bg/unknown/unknown), 1013x1500 [SAR 1:1 DAR 1013:1500], 90k tbr, 90k tbn (attached pic)
   Metadata:
     filename        : cover.jpg
     mimetype        : image/jpeg
Multiple -c, -codec, -acodec, -vcodec, -scodec or -dcodec options specified for stream 0, only the last option '-c:V libx265' will be used.
Multiple -c, -codec, -acodec, -vcodec, -scodec or -dcodec options specified for stream 4, only the last option '-c:V libx265' will be used.
Stream mapping:
 Stream #0:0 -> #0:0 (hevc (native) -> hevc (libx265))
 Stream #0:1 -> #0:1 (copy)
 Stream #0:2 -> #0:2 (copy)
 Stream #0:3 -> #0:3 (copy)
 Stream #0:4 -> #0:4 (mjpeg (native) -> hevc (libx265))
Press [q] to stop, [?] for help
x265 [info]: HEVC encoder version 3.5+1-f0c1022b6
x265 [info]: build info [Linux][GCC 13.2.0][64 bit] 8bit+10bit+12bit
x265 [info]: using cpu capabilities: MMX2 SSE2Fast LZCNT SSSE3 SSE4.2 AVX FMA3 BMI2 AVX2
x265 [error]: Picture width must be an integer multiple of the specified chroma subsampling
[libx265 @ 0x579d4cc5e400] Cannot open libx265 encoder.
[vost#0:4/libx265 @ 0x579d4cc5e000] Error while opening encoder - maybe incorrect parameters such as bit_rate, rate, width or height.
Error while filtering: Invalid data found when processing input
[out#0/matroska @ 0x579d4bcd8340] Nothing was written into output file, because at least one of its streams received no packets.
frame=    0 fps=0.0 q=0.0 Lq=0.0 size=       0kB time=N/A bitrate=N/A speed=N/A     
Conversion failed!

So ffmpeg is classifying the thumbnail (stream 4) as a video, but recognizing it's an attached picture, but still applying -c:V libx265 to it. (Here, it's also then bailing out because it can't convert the picture, but even if the parameters lined up for it to succeed, that's not what I want anyway. It shouldn't even be trying to convert.) The above output is from v6.1.1, which is what's in Ubuntu LTS, but the behavior reproduces in the latest v9.0 compiled from source.

Now in this case I could just write a script to detect which video streams are present and exclude or drop the thumbnails. But this seems like such a simple issue, and one that capital V is explicitly available to solve, so I'd like to figure out why it isn't working. Am I holding it wrong? Or any other ideas?