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
<aaabbb>
sorry i meant 1/8 and 8 not 1/4 and 4
ewomer has quit [Quit: WeeChat 4.4.3]
<aaabbb>
uh, 1/16 and 16. i'm bad at math
Everything has quit [Quit: leaving]
rex has joined #ffmpeg
SuicideShow has quit [Ping timeout: 264 seconds]
green44 has quit [Quit: Client closed]
SuicideShow has joined #ffmpeg
<aaabbb>
anyway yeah decreasing volume in software, especially with integer precision, can reduce quality. but in general unless you are doing silly post-processing like increasing volume over again (in software or hardware), then it should be fine and everything that you'll loose would be below the noise floor anyway
<noobaroo>
Under the gui volume control under pavucontrol actually considered "software"? Im assuming it is, since it is on a screen, but not completely sure. Also, one time I asked in #mpv why --ao=pipewire is noticeably louder and poor quality compared to --ao=pulse, turns out I had increase volume beyond 100% for the mpv app one time in pavucontrol-qt and the setting stuck from then on
<noobaroo>
That was for a specific app though, not for the master volume. Maybe master volume is not "software" ?
<aaabbb>
just because it's on screen doesn't mean it's doing it in software to the pcm itself
<aaabbb>
i guess it's like cameras that have hybrid optical/digital zoom where past a certain point (100% in your case) it cannot tell the audio hardware to get louder and instead has to keep it at 100% and then tamper with the audio itself and hope that nothing clips
Traneptora has joined #ffmpeg
<noobaroo>
yeah... but my experience with the >100% --ao=pipewire thing was some time ago when I didnt even care about audio quality and was just trying to use PC normally, and it was noticeable enough for me to be perplexed
<noobaroo>
Its not like i was trying to listen carefully and tweak and rice (like i have been within the past week or so)
<noobaroo>
So i know for sure pavucontrol per-app volume is bad. The only question that remains is if the master volume in pavucontrol is any better, and if so, by how much
<aaabbb>
master volume usually means instructing the hardware to apply volume changes
<noobaroo>
Thanks, so theoretically even at 5% master volume and then the physical wheel on my headset cable turned all the way up, it shouldnt be bad?
<aaabbb>
per-app volume is necessarily software mixing (for 99% of people... but you can get sound cards that do hardware mixing)
luva8889 has quit [Ping timeout: 260 seconds]
<aaabbb>
noobaroo: no that would be not good
<aaabbb>
well
<aaabbb>
it depends on how loud the sound originally is
<aaabbb>
oh
<aaabbb>
i misunderstoo
<aaabbb>
d
<aaabbb>
noobaroo: that would be totally fine, the physical wheel is not an amplifier, just a variable resistor. and 5% master volume will almost certainly be 5% in harware, not in software
<noobaroo>
If you are wondering, I only have the desire to do this because i used the tone generator in audacity because i was wondering how high in kHz i can hear, and i noticed starting at >6khz approx, maybe 8khz, i had to MASSIVELY spin the physical wheel up higher on my headset and then the tone would cut in all at once
<aaabbb>
does your headset use an external dac?
talismanick has joined #ffmpeg
<aaabbb>
or is it just a little wheel on the wire?
<noobaroo>
It wasnt a gradual thing, like not at all, and then for >12khz which was about max, i had volume maxed out completely to hear it at same volume as 4khz on minimum volume wheel setting
<noobaroo>
The wheel on the wire
<aaabbb>
then you should generally keep that wheel at 100%. it's just a variable resistor. it's roughly the equivalent of adjusting the distance between your ear and the speaker
<noobaroo>
Thanks
<aaabbb>
btw all humans are less sensitive to high frequency sounds
<aaabbb>
a tone at 16khz that sounds quiet would be horribly loud at 2khz
<aaabbb>
that shows how it's basically logarithmic how high the pitch has to get to hear the same change in pitch. and with higher frequencies, you *also* need louder sounds
<aaabbb>
so that kind of compounds (needing more changes in frequency at high freqs to notice a change + needing higher amplitude) and together you need higher frequencies to be waaaay louder to hear them
FlorianBad has quit [Remote host closed the connection]
FlorianBad has joined #ffmpeg
Marth64 has quit [Quit: Leaving]
luva8889 has quit [Ping timeout: 252 seconds]
luva8889 has joined #ffmpeg
Dagger has quit [Ping timeout: 276 seconds]
Dagger has joined #ffmpeg
Kruppt has quit [Ping timeout: 260 seconds]
monkeystu_ has quit [Remote host closed the connection]
monkeystu has joined #ffmpeg
vlm has quit [Ping timeout: 260 seconds]
Vonter has joined #ffmpeg
relue has joined #ffmpeg
Kruppt has joined #ffmpeg
Kruppt has quit [Remote host closed the connection]
theobjec- has joined #ffmpeg
theobjectivedad has quit [Read error: Connection reset by peer]
System_Error has joined #ffmpeg
Vonter has quit [Quit: WeeChat 4.4.3]
Vonter has joined #ffmpeg
StephenLynx has quit [Quit: Leaving]
<noobaroo>
aaabbb, i wasnt surprised to need to turn up the volume to be able to hear frequencies that are not normal ones, but it was not a gradual effect, it would kick in all at once
<noobaroo>
That to me makes me think that it's a problem with the setup. These headphones are probably somewhere around 10 years old and they are meant for gaming and talking on the mic. Its all I was able to scavenge, I cant afford to buy anything new
chiselfuse has quit [Ping timeout: 260 seconds]
Cheetahze has joined #ffmpeg
chiselfuse has joined #ffmpeg
wyatt8740 has quit [Ping timeout: 252 seconds]
wyatt8740 has joined #ffmpeg
realies has quit [Quit: Ping timeout (120 seconds)]
realies has joined #ffmpeg
realies has quit [Client Quit]
realies has joined #ffmpeg
realies has quit [Client Quit]
realies has joined #ffmpeg
realies has quit [Read error: Connection reset by peer]
realies has joined #ffmpeg
realies has quit [Read error: Connection reset by peer]
realies has joined #ffmpeg
realies has quit [Read error: Connection reset by peer]
realies has joined #ffmpeg
realies has quit [Ping timeout: 248 seconds]
evilscreww has joined #ffmpeg
lockywolf has joined #ffmpeg
rsx has quit [Quit: rsx]
realies has joined #ffmpeg
realies has quit [Read error: Connection reset by peer]
Suchiman has quit [Quit: Connection closed for inactivity]
<noobaroo>
aaabbb remember when we talked about how AAC producing warped-looking spectrographs is not a good indicator of sound quality?
<noobaroo>
I was dissing aac because its visual graphs in audacity are always more warped than opus and its not a close call ever. And you guys said there is a reason why audio codecs are not good image encoders or something like that.
<aaabbb>
noobaroo: about the headphones if they're for gaming, then probably they're only rated for up to 8khz
<aaabbb>
since it's meant for speech
<aaabbb>
so it's not going to give a nice linear or even close to linear frequency response
<aaabbb>
and yeah i remember about that
<noobaroo>
Well, I was thinking, with in the SoX manpages it says that resampling can cause ringing. I've never actually heard this but I was wondering if maybe there is some of this general area of phenomena going on at a more microscopic high frequency level, like within the normal words? In puberty we have bubbly voices and you can imagine that if the ringing effect is extremely-extremely zoomed in, like it lasts nanoseconds, then maybe it could make
<noobaroo>
I ask because it seems like time and time again, my lossy re-encodes of these flac files sound better than the the source file. I'm using mainly opus, fdk, and vorbis. A little mp3 but not much.
acovrig6012 has joined #ffmpeg
<noobaroo>
Either my lossy products sound better, or they are exactly the same. I haven't actually experienced even a s ingle time that the flac file sounded better to me.
<aaabbb>
have you done abx testing? if you're not starving the codec of bits, then a lossy encode should be 100% impossible to distinguish from flac
<noobaroo>
I dont think these headphones are meant for speech, I think that would be like an earpiece. These are actual headphones that encompass the ears completely
<noobaroo>
Well, not speech-only
<aaabbb>
even so, cheap headphones will not have a nice, nearly-linear response all the way up to 20khz
<noobaroo>
But up to 8khz?
Some_Person has quit [Ping timeout: 260 seconds]
<aaabbb>
good enough to not have serious problems, at least. but you're putting the headphones through frequencies that they are probably not intended to accurately reproduce
<noobaroo>
And what causes the sudden kick-ins? Its not a gradual volume reduction like i would expect in nature. So its some sort of technological fuckery
<aaabbb>
non-linear response
<noobaroo>
Does that mean the volume meter distance thing that you were talking about is doing it?
<aaabbb>
the distance thing (the bark scale) is an example of non-linear behavior of our ear
<aaabbb>
but what's doing it probably has to do with the speaker driver and diaphragm just not being designed for that
louipc has quit [Remote host closed the connection]
Guest0 has joined #ffmpeg
louipc has joined #ffmpeg
<Guest0>
I'm converting all my videos to MP4 from old and modern MP4s, is there a side effect of specifying them as -pix_fmt yuv420p
FH_thecat has joined #ffmpeg
Dagger has quit [Ping timeout: 265 seconds]
Dagger has joined #ffmpeg
<BtbN>
well, if they're something better, it'll reduce them to 420
<BtbN>
But the usual disclaimer: There is very rarely a point to transcoding video to a more modern format, if it's not using absolutely excessive bitrate
<BtbN>
Quality only ever gets worse
<noobaroo>
Guest0: what were they originally ? I dont know of anything older than yuv420p. I think i might have heard of some weird pix_fmt that old .avi used, but ive personally only seen yuv420p avis that are usually mpeg4
<Guest0>
they were mostly old MJPEGs and WMV. I do have some avc1 MP4s, I found out I can compress those without any quality loss. I'm using yuv420p for all of them
<BtbN>
You can never compress anything with a lossy codec without any quality loss
Dagger has quit [Ping timeout: 252 seconds]
<BtbN>
There's some few exceptions like jpeg under special circumstances has no generational loss, or the ndi codec
<Guest0>
yep definitely but to me, i didnt notice anything significant
Dagger has joined #ffmpeg
<xx>
I'd say avoid doing it, you definitely lose something
<xx>
related, I don't know why ffmpeg changes the pixel format when doing -c:v copy
<xx>
isn't that bad?
<Guest0>
chatgpt says: 1. Mismatched Container Metadata 2. Container vs. Codec Color Information 3. Incorrect Default Values 4. Container-Specific Limitations etc
<Guest0>
probably the first or second reason:
<Guest0>
When copying video streams, FFmpeg may adjust the metadata or flags stored in the container, including:
<Guest0>
Color Primaries
<Guest0>
Transfer Characteristics
<Guest0>
Matrix Coefficients
<Guest0>
If the original file's container lacks explicit color metadata, FFmpeg may apply default values when remuxing, which can differ from the source's intended values.
<Guest0>
Some containers (like MP4, MKV) and codecs (like H.264, HEVC) handle color metadata differently. For example:
<Guest0>
The codec stream might specify one set of color parameters.
<Guest0>
The container might store another set or none at all. When copying the stream, FFmpeg might reinitialize container-level metadata, leading to discrepancies.
<xx>
if I wanted to use chatgpt, I'd ask it
acovrig6012 has joined #ffmpeg
<furq>
xx: when have you seen the pixel format change when copying
<xx>
furq: `ffmpeg -i in.mp4 -c copy out.mp4`
<furq>
what did it change from and to
mven971 has joined #ffmpeg
mven97 has quit [Ping timeout: 260 seconds]
mven971 is now known as mven97
lavaball has joined #ffmpeg
<xx>
bt.709 to bt.601 PAL
ewomer has quit [Read error: Connection reset by peer]
chiselfuse has quit [Remote host closed the connection]
<rvalue>
I am on ffmpeg 7.1 on macOS. I am trying to clip a video file and turn into mp4. This command is taking way more video data than expected, whats wrong here?: ffmpeg -ss 01:55:33 -i file.mkv -t 01:56:09 clip.mp4
acovrig6012 has joined #ffmpeg
<rvalue>
I am expecting a clip of 60-33+9 so 36 seconds
Guest0 has quit [Quit: Client closed]
<rvalue>
with -t 36 it works fine
<rvalue>
my first try was using -to 01:56:09 but that didnt work either
<JEEB>
time is for how long you want it duration wise so that at least is how it should be. to exists but I've never utilized it
<rvalue>
here was my command using -to, ffmpeg -ss 01:55:33 -i file.mkv -to 01:56:09 clip.mp4
<rvalue>
nvm, figured it out
<rvalue>
it was, ffmpeg -ss 01:55:33 -to 01:56:09 -i file.mkv clip.mp4
Some_Person has joined #ffmpeg
wobbol has quit [Ping timeout: 260 seconds]
wobbol has joined #ffmpeg
DetourNetworkUK has quit [Ping timeout: 252 seconds]
<dumpster>
I need to creato a for loop in windows with multiple inputs ffmpeg -i something -i something and so on. Can someone please tell me how to do that?