BtbN changed the topic of #ffmpeg to: Welcome to the FFmpeg USER support channel | Development channel: #ffmpeg-devel | Bug reports: https://ffmpeg.org/bugreports.html | Wiki: https://trac.ffmpeg.org/ | This channel is publically logged | FFmpeg 7.0 is released
SuicideShow has quit [Ping timeout: 252 seconds]
SuicideShow has joined #ffmpeg
Everything has quit [Quit: leaving]
bertieb has quit [Ping timeout: 264 seconds]
bertieb has joined #ffmpeg
rex has quit [Ping timeout: 264 seconds]
Marth64 has joined #ffmpeg
louipc has quit [Ping timeout: 260 seconds]
Marth64 has quit [Quit: Leaving]
rex has joined #ffmpeg
xx has quit [Ping timeout: 260 seconds]
Kei_N_ has joined #ffmpeg
Kei_N has quit [Ping timeout: 276 seconds]
rex has quit [Ping timeout: 272 seconds]
rex has joined #ffmpeg
jab416171 has joined #ffmpeg
<chiselfuse>
JEEB: but what's the point? how is it useful to know
gchound has joined #ffmpeg
<BtbN>
How else would you tell two libx264 encoders apart that are working in parallel?
<chiselfuse>
oh so it's meant as an identifier?
<chiselfuse>
i thought it was for debugging in gdb or something
qubuepe24_ has quit [Remote host closed the connection]
<BtbN>
You can use it for that as well I guess. It's the pointer to the AVCodecContext after all
<BtbN>
or whatever the log context happens to be
<BtbN>
But you don't want to look at that context thaaat often for debugging
Guest0 has joined #ffmpeg
<Guest0>
which is better for naming photos and videos?
<Guest0>
the only difference between the underscore vs the space
<Guest0>
versus hyphens and dots
<BtbN>
Whatever you prefer
<BtbN>
spaces always need escaped or quotes
lucasta has quit [Quit: Leaving]
Traneptora has quit [Quit: Quit]
nigetilly has joined #ffmpeg
<aaabbb>
Guest0: i prefer underscore for filenames generated automatically
gchound has quit [Quit: WeeChat 4.1.1]
vampirefrog has quit [Quit: Leaving]
gchound has joined #ffmpeg
Hackerpcs has quit [Quit: Hackerpcs]
Hackerpcs has joined #ffmpeg
Hackerpcs has quit [Max SendQ exceeded]
EmleyMoor has quit [Ping timeout: 246 seconds]
EmleyMoor has joined #ffmpeg
Dotz0cat has quit [Ping timeout: 252 seconds]
Dotz0cat has joined #ffmpeg
nigetilly has quit [Read error: Connection reset by peer]
nigetilly_ has joined #ffmpeg
Hackerpcs has joined #ffmpeg
markizano has quit [Quit: Poweroff]
Hackerpcs has quit [Remote host closed the connection]
Hackerpcs has joined #ffmpeg
gchound has quit [Quit: WeeChat 4.1.1]
stolen has joined #ffmpeg
gchound has joined #ffmpeg
Traneptora has joined #ffmpeg
Dagger has quit [Ping timeout: 260 seconds]
Dagger has joined #ffmpeg
darkapex has quit [Ping timeout: 252 seconds]
markizano has joined #ffmpeg
gchound has quit [Quit: WeeChat 4.1.1]
<noobaroo>
Most vids are h264 so I can use the h264_metadata bsf, but with basically all of the open-source codecs the only way I can set crop into mkv container is by using mkvtoolnix. It then shows up in ffprobe as sidedata for the video stream specifier. But IIRC -vf sidedata in ffmpeg does not work with codec copy. So I havent even tried to look if there is a way to set this cropping sidedata on cmdline ffmpeg.
qubuepe24 has joined #ffmpeg
<noobaroo>
I have a 12GB video file right now that Im using mkvtoolnix to add the cropping sidedata and then im going to remux again with ffmpeg since mkvtoolnix cant do cues_to_front = true, and its a 12GB file so this is even more important because of the size
<noobaroo>
I considered doing it in tmpfs so it doesnt take 10mins but im not sure if i have enough ram.
<noobaroo>
Is there a way to add cropping sidedata with ffmpeg? I dont see it under matroska section in the ffmpeg.org docs
<noobaroo>
and IIRC -vf sidedata doesnt work with stream copy
darkapex has joined #ffmpeg
StephenLynx has quit [Quit: Leaving]
stolen has quit [Quit: Connection closed for inactivity]
Tano has quit [Ping timeout: 245 seconds]
qubuepe24 has quit [Remote host closed the connection]
Tano has joined #ffmpeg
qubuepe24 has joined #ffmpeg
vincejv has quit [Ping timeout: 260 seconds]
qubuepe24 has quit [Remote host closed the connection]
nigetilly_ has quit [Quit: Konversation terminated!]
qubuepe24 has joined #ffmpeg
qubuepe24 has quit [Remote host closed the connection]
Marth64 has joined #ffmpeg
System_Error has joined #ffmpeg
Keshl_ is now known as Keshl
<noobaroo>
If something says "1920x1080 [SAR 1:1 DAR 16:9], SAR 20:27 DAR 320:243, 23.98 fps, 23.98 tbr, 1k tbn (default)" Does that mean the real SAR and DAR are the ones in the brackets or is it the one right after?
Suchiman has quit [Quit: Connection closed for inactivity]
EmleyMoor has quit [Ping timeout: 252 seconds]
EmleyMoor has joined #ffmpeg
SakuraChan has quit [Ping timeout: 246 seconds]
Sakura`Kinomoto has joined #ffmpeg
nigetilly has joined #ffmpeg
vincejv has joined #ffmpeg
upekkha has quit []
upekkha has joined #ffmpeg
rv1sr has joined #ffmpeg
Blacker47 has joined #ffmpeg
Perflosopher2 has joined #ffmpeg
Perflosopher has quit [Ping timeout: 260 seconds]
Perflosopher2 is now known as Perflosopher
evilscreww has joined #ffmpeg
xx has joined #ffmpeg
Suchiman has joined #ffmpeg
System_Error has quit [Ping timeout: 260 seconds]
System_Error has joined #ffmpeg
cmc has quit [Remote host closed the connection]
xx has quit [Read error: Connection reset by peer]
xx has joined #ffmpeg
cmc has joined #ffmpeg
nigetilly has quit [Ping timeout: 276 seconds]
Sketch has quit [Remote host closed the connection]
DetourNetworkUK has quit [Remote host closed the connection]
DetourNetworkUK has joined #ffmpeg
Sketch has joined #ffmpeg
j45 has quit [Ping timeout: 276 seconds]
relue has quit [Ping timeout: 255 seconds]
j45 has joined #ffmpeg
relue has joined #ffmpeg
treefrob has quit [Ping timeout: 265 seconds]
Buliarous has quit [Ping timeout: 252 seconds]
Buliarous has joined #ffmpeg
treefrob has joined #ffmpeg
j45 has quit [Ping timeout: 248 seconds]
j45 has joined #ffmpeg
DetourNetworkUK has quit [Ping timeout: 265 seconds]
DetourNetworkUK has joined #ffmpeg
<aaabbb>
noobaroo: it means that the ratio stored in the container and the ratio stored in the bitstream differ. one is not automatically correct. but for a hd1080 video, you can probably assume that the sar 1:1 one is correct and the sar 20:27 one is not
Guest0 has quit [Quit: Client closed]
lavaball has joined #ffmpeg
<noobaroo>
Which one is the container?
<noobaroo>
I guess its the 1920x1080
<furq>
xx: those are colour primaries, not pixel formats
<furq>
those are stored in the container
<furq>
they should also be copied from the source with recent enough ffmpeg
<xx>
yeah I realized it some time later that pixel formats are not the same thing, my bad
<xx>
still strange that they change the color primaries (I'm unsure what it is anyway)
<furq>
well i guess next time i won't take 24 hours to reply
<xx>
recent enough ffmpeg would be what version?
<furq>
no idea
<furq>
about a year old maybe
<furq>
it used to not set any primaries unless you set them explicitly
<furq>
now it tries to copy them from the source
<furq>
i guess what mediainfo is reporting is some default value from somewhere
<furq>
hard to say because 0x0 is down and i can't see those pastes
Arokh has quit [Quit: //ThisShouldNeverHappen]
Arokh has joined #ffmpeg
<noobaroo>
i have no idea where ffprobe is getting the "SAR 20:27 DAR 320:243" from
<noobaroo>
mediainfo and mkvtoolnix only show 1920x1080 and the raw video stream to a file only shows 1080
lavaball has quit [Remote host closed the connection]
StephenLynx has joined #ffmpeg
lavaball has joined #ffmpeg
Traneptora has quit [Quit: Quit]
<noobaroo>
Is the only reason we still use ac3/eac3 is for compatibility? Even if thats the case in 2024, why in all of time did nobody ever use ac3/eac3 for music? Is it that bad?
<noobaroo>
I would think a movie audio codec would need better VBR than music codecs. You know... Because of so many silent or quiet scenes for several seconds at a time
ewomer has quit [Read error: Connection reset by peer]
ewomer has joined #ffmpeg
xx has quit [Remote host closed the connection]
rex has quit [Ping timeout: 252 seconds]
xx has joined #ffmpeg
rex has joined #ffmpeg
HarshK23 has quit [Quit: Connection closed for inactivity]
HarshK23 has joined #ffmpeg
Sakura`Kinomoto has quit [Ping timeout: 276 seconds]
minimal has joined #ffmpeg
SakuraChan has joined #ffmpeg
<kepstin>
iirc the main use cases for ac3 have actually been for broadcast and optical discs, where vbr can at times be counterproductive since you have limit bitrate for transfer speed.
<kepstin>
as far as I understand it, ac3 is fine for music, but other codecs are more efficient (lower average bitrate for same quality)
microlappy has joined #ffmpeg
microlappy has quit [Client Quit]
trillion_exabyte has quit [Ping timeout: 276 seconds]
trillion_exabyte has joined #ffmpeg
ewomer has quit [Quit: WeeChat 4.4.3]
ewomer has joined #ffmpeg
<BtbN>
Yeah, movies typically have super strict cbr requirements.
<BtbN>
I think the ac3 family of codecs stems from cinema even? Where the physical film reel is rolling at constant speed, so the digital audio on there had to be perfect cbr no matter what's going on
<BtbN>
And in broadcast TV it's also strict cbr, though mpeg-ts can pad the data just fine
Nact has joined #ffmpeg
evilscreww has quit [Quit: Leaving]
Nact has quit [Quit: Konversation terminated!]
qubuepe24 has joined #ffmpeg
noobaroo has quit [Remote host closed the connection]
vedranm has joined #ffmpeg
noobaroo has joined #ffmpeg
mven97 has quit [Ping timeout: 260 seconds]
lucasta has joined #ffmpeg
<noobaroo>
I understand the physical layout difference of 5.1(side) vs 5.1, at least I think, it seems pretty simple and true to the name. But why is there a different ffprobe channel map layout? Apparently 5.1=FL+FR+FC+LFE+BL+BR vs 5.1(side)=FL+FR+FC+LFE+SL+SR and in audacity, the program doesnt ever name channels or care about intended channel maps, it just numbers them. The first 4 channels are the same between these, with both using 2 as the main
<noobaroo>
dialogue channel and 3 as LFE. The only difference is the last two channels
<noobaroo>
And its really a superficial difference because maybe I have my speakers slightly on the side and slightly behind. What matters is that SL and BL are both in the same channel number. And SR and BR are in the same spot
<noobaroo>
I dont understand why there is a software labeling difference
Traneptora has joined #ffmpeg
mven97 has joined #ffmpeg
mven977 has joined #ffmpeg
mven97 has quit [Ping timeout: 252 seconds]
mven977 is now known as mven97
yans has quit [Quit: Let us play... Hide and Slay!]
realies has joined #ffmpeg
mven97 has quit [Ping timeout: 252 seconds]
hbbs has quit [Quit: bye]
mven97 has joined #ffmpeg
Kruppt has joined #ffmpeg
rv1sr has quit [Ping timeout: 244 seconds]
Tano has quit [Quit: WeeChat 4.4.2]
rv1sr has joined #ffmpeg
qubuepe24 has quit [Remote host closed the connection]
Traneptora has quit [Quit: Quit]
low-key has quit [Remote host closed the connection]
jemius has joined #ffmpeg
<ePirat>
noobaroo, I would assume ffmpeg follows some of the standards for that there
<JEEB>
plus certain definitions of channel layouts between different specifications. doesn't help that then retroactively like 10 years later one of the specs retroactively redefines stuff and you're left with a mess :)
iive has joined #ffmpeg
bertieb has quit [Read error: Connection reset by peer]
Everything has joined #ffmpeg
bertieb has joined #ffmpeg
<furq>
15:30:23 ( BtbN) I think the ac3 family of codecs stems from cinema even?
<kepstin>
are you sure you actually want loudnorm (dynamic loudness normalization) rather than a fixed offset based on the measured ebur128 integrated loudness?
acovrig6012 has joined #ffmpeg
<realies>
i want to conform to the specific ebur128 specs using that input file
<kepstin>
if this is a file and you don't need the dynamic range adjustment stuff, I'd recommend doing a 2 pass measurement first using the ebur128 filter to do measurements, then a second pass applying any needed gain adjustment using the volume filter.
<realies>
i think it would be better not to dynamically change the loudness over time, but that sounds like tweaking the dynamic range
<realies>
i should have mentioned, this is a two pass loudnorm where the first one takes measurements and the second one applies them to the file
<kepstin>
the two-pass loudnorm will, depending on the measurements and settings automatically pick between either applying a single gain adjustment or do the second pass in dynamic mode.
<kepstin>
mostly if the measured dynamic range is larger than your settings, it'll run in dynamic mode to reduce dynamic range.
<realies>
yeah, i tried linear=true/false but the result was identical
<kepstin>
linear=true (the default) will cause it to do a linear adjustment _if possible_. in your example file it's apparently not possible to do linear mode while fulfilling your requested parameters, so it's running the second pass in dynamic mode.
<realies>
(i've also tried without setting linear= explicitly)
<kepstin>
setting linear=false forces it to always do dynamic mode even when linear is possible. The default is to use linear when possible.
<realies>
i understand, but the output is identical with linear=false and linear=true
<kepstin>
yes, because with your input file and chosen settings, linear mode is not possible.
<kepstin>
so it always uses dynamic (non-linear) mode
<realies>
isn't dynamic mode expected to reduce the dynamic range instead of clip the output?
<kepstin>
it's not perfect :/ sometimes get some weirdness on specific audio.
<realies>
this is actually weird
<realies>
"output_tp": -1, "output_lra": 3.8,
<kepstin>
if you don't need dynamic range reduction, i continue to recommend using ebur128 (or loudnorm first pass) to get measurements, then apply gain adjustment with the volume filter.
<realies>
using the ebur128=peak=true filter on the output file tells me Integrated loudness: I: -16.0 LUFS Threshold: -26.5 LUFS
<realies>
why would ebur128 say TP 3.5 dBFS but loudnorm "output_tp": -1?
<kepstin>
it looks like the issue is that your target integrated loudness is -16 but the file is measured as -18, so it has to increase the volume to meet the loudness. But the true peak of 0.01 exceed the target true peak, even more so after increasing volume, so it has to run in dynamic mode in order to apply the peak limiter to bring peaks down to -1
* realies
goes checking the way things are parsed
<kepstin>
output tp is tp _after_ the peak limiter is applied to bring peaks down to your requested -1dB
<realies>
why would the ebur128 filter report TP 3.5 dBFS on the output file when loudnorm has a peak limiter?
<kepstin>
so it successfully did what you asked - raised loudness from -18.93LUFS to -16.02LUFS while reducing true peak from 0.01dBFS to -1dBFS
<kepstin>
i dunno, bugs in the loudnorm peak limiter? :/
<realies>
fair enough
<realies>
it has been getting better over the years but it's still not universally great it seems
<realies>
do you know of any other cli tools that can do ebur128 normalisation?
<kepstin>
if you just want to do loudness normalization, ffmpeg's ebur128 and volume filters are fine. If you want to do loudness normalization + peak limiting, then use the volume filter followed by the alimiter filter (if you need to limit true peak, then upsample before the alimiter filter)
<kepstin>
you only need something fancier if you specifically want to do dynamic range reduction
darkapex has quit [Ping timeout: 246 seconds]
Blacker47 has quit [Quit: Life is short. Get a V.90 modem fast!]
rv1sr has quit [Ping timeout: 260 seconds]
rv1sr has joined #ffmpeg
lavaball has quit [Quit: lavaball]
vampirefrog has joined #ffmpeg
j45 has quit [Ping timeout: 276 seconds]
j45 has joined #ffmpeg
relue has quit [Ping timeout: 260 seconds]
arbitercoin has joined #ffmpeg
Everything has quit [Ping timeout: 260 seconds]
Everything has joined #ffmpeg
vampirefrog has quit [Quit: Leaving]
lucasta has quit [Remote host closed the connection]