Marth64 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.1 is released
System_Error has joined #ffmpeg
ryoskzypu has quit [Remote host closed the connection]
ryoskzypu has joined #ffmpeg
drv has quit [Ping timeout: 248 seconds]
drv has joined #ffmpeg
iive has quit [Quit: They came for me...]
Mister_Magister has quit [Quit: bye]
Mister_Magister has joined #ffmpeg
Shuriko has quit [Read error: Connection reset by peer]
lavaball has quit [Remote host closed the connection]
Shuriko has joined #ffmpeg
minimal has quit [Read error: Connection reset by peer]
minimal has joined #ffmpeg
Dagger has quit [Ping timeout: 248 seconds]
xx has quit [Quit: xx]
Dagger has joined #ffmpeg
EmleyMoor has quit [Ping timeout: 248 seconds]
EmleyMoor has joined #ffmpeg
EmleyMoor has quit [Ping timeout: 244 seconds]
EmleyMoor has joined #ffmpeg
Sciencentistguy has quit [Quit: o/]
Sciencentistguy has joined #ffmpeg
YUiNA has quit [Remote host closed the connection]
minimal has quit [Quit: Leaving]
rvalue has quit [Read error: Connection reset by peer]
rvalue has joined #ffmpeg
^Neo has quit [Ping timeout: 260 seconds]
Warcop has joined #ffmpeg
kasper93 has quit [Remote host closed the connection]
kasper93 has joined #ffmpeg
System_Error has quit [Remote host closed the connection]
System_Error has joined #ffmpeg
Some_Person has quit [Ping timeout: 268 seconds]
Some_Person has joined #ffmpeg
acidbunny has quit [Quit: ERC 5.5.0.29.1 (IRC client for GNU Emacs 29.4)]
Some_Person has quit [Client Quit]
function1 has quit [Ping timeout: 246 seconds]
Some_Person has joined #ffmpeg
turlando has quit [Ping timeout: 244 seconds]
function1 has joined #ffmpeg
Warcop has quit [Remote host closed the connection]
YuGiOhJCJ has quit [Quit: YuGiOhJCJ]
tsujp has quit [Remote host closed the connection]
ninjin has quit [Remote host closed the connection]
atrius has quit [Remote host closed the connection]
ursa-major has quit [Remote host closed the connection]
RetroPunk has quit [Remote host closed the connection]
cherries has quit [Remote host closed the connection]
noelle has quit [Remote host closed the connection]
jasom has quit [Remote host closed the connection]
OctopusET has quit [Remote host closed the connection]
brocellous has quit [Remote host closed the connection]
probie has quit [Remote host closed the connection]
jmcantrell has quit [Write error: Connection reset by peer]
samhza has quit [Write error: Broken pipe]
samhza has joined #ffmpeg
noelle has joined #ffmpeg
ninjin has joined #ffmpeg
probie has joined #ffmpeg
jasom has joined #ffmpeg
RetroPunk has joined #ffmpeg
brocellous has joined #ffmpeg
jmcantrell has joined #ffmpeg
cherries has joined #ffmpeg
atrius has joined #ffmpeg
ursa-major has joined #ffmpeg
OctopusET has joined #ffmpeg
tsujp has joined #ffmpeg
pyre has quit [Remote host closed the connection]
pyre has joined #ffmpeg
lavaball has joined #ffmpeg
Blacker47 has joined #ffmpeg
^Neo has joined #ffmpeg
^Neo has joined #ffmpeg
^Neo has quit [Ping timeout: 244 seconds]
<intrac> hi, I'm trying to understand how ffmpeg maps the sample level (amplitude) of a PCM input signal to a lossy format (eg MP3/AAC) and then decode back to PCM and retain the same sample amplitude
<intrac> as there are various statements that lossy codecs don't have a bit depth. eg: https://superuser.com/questions/553552/how-to-determine-aac-bit-depth
<JEEB> yea. since with lossy formats often you're dealing with a representation of an approximation that then can be represented as floating point
<intrac> so how do the Ffmpeg decoders know what sample level to decode to (with regard to peak levels) - i.e. making sure the output PCM waveform isn't too quiet or loud in relation to peak levels
<JEEB> it's whatever comes from the decoder process, so unless the decoder specifies some limits - it's whatever was coded in the bit stream
<intrac> JEEB: do you mean that a 16 bit input (0 to 65,536) is represented as floating point 0.0 to 1.0 (or some other range)?
<intrac> I'm just trying to understand if there's any variations in the way decoders interpret AAC/MP3 streams (in other words, different decoders might output waveforms of different amplitudes)
<JEEB> how much leeway *decoders* have depends on the spec
<intrac> so do you mean that a PCM sine wave that is close to peak levels (e.g. 65536 value) *should* be encoded and then decoded back to the same level?
<intrac> or very closely
<JEEB> like with lossy video for like 20+ years now the formats have been specified bitexact. but before that you might have had mismatching IDCT etc since the spec only required that it was "close enough"
<intrac> ok, so it *should* decode and be fairly close to the original
<JEEB> but of course what did the encoder decide to keep or not to keep is a whole different ballpark
<JEEB> since the specification only defines how a bit stream is decoded
<JEEB> thus "how well a specific signal is going to be kept through a lossy coding thing" is "depends on the encoder and most likely the parameters given to an encoder"
<intrac> the reason I ask is I'm trying to work out if a quiet audio stream can probably be attributed to the original PCM signal (or specific audio filters) and less likely to be a mismatch between encoder/decoder specs
<JEEB> there is no encoder spec in general, just how a bit stream is interpreted is specified, and then as long as an encoder outputs something that can be validly interpreted it is a valid encoder
Shine has joined #ffmpeg
<intrac> ok
<intrac> I thought I read that some codecs might have metadata where you can set a different playback/decode volume
<intrac> to basically adjust the output level without having to re-encode
<JEEB> like, with lossy coding most encoders do a lowpass since values that are outside or close to limits of human hearing in general are not too useful to keep
<intrac> I'm just trying to work out if there are any gotchas like that for me to look out for
<JEEB> yes, you can set DRC or replaygain metadata
<intrac> is that just for some codecs? it seems MP3 doesn't have it as part of its official spec
<JEEB> which is then separate from *decoding* technically, except I think in some MPEG formats it's considered as part of the decoding process
<JEEB> yes, replaygain etc is generally just a specific metadata block that utilizes existing metadata additions to various formats
<JEEB> like id3v2 with mp3
<JEEB> those are completely separate from the base audio bit stream format spec
<intrac> do you know if mediainfo should report this, if it exists?
<JEEB> it's just one way that additional random metadata got specified at some point
<JEEB> no idea
<intrac> yes, I see a comment here which mentions it's part of the container metadata, not the raw/elementary stream
<intrac> brb
<JEEB> """container""" , where with mp3 it's just the raw bit stream lol
<JEEB> but yes, it is defined in various containers as well
<JEEB> then there's stuff like MPEG-D DRC which is then often coded as metadata in the bit stream, and its application may be defined as part of the decoding process for example for some extensions of the AAC spec (AAC is at this point so sprawling it's kind of funny for how many specs you have to look at to get a full view)
Shuriko has quit [Ping timeout: 260 seconds]
HarshK23 has joined #ffmpeg
SuicideShow has quit [Ping timeout: 260 seconds]
SuicideShow has joined #ffmpeg
<intrac> JEEB: what do you mean by """container""" and mp3 raw bitstream?
<JEEB> because mp3 files don't have a container, they're the raw bit stream
emanuele6 has joined #ffmpeg
Sketch has quit [Remote host closed the connection]
System_Error has quit [Remote host closed the connection]
Sketch has joined #ffmpeg
System_Error has joined #ffmpeg
<intrac> ah ok
<intrac> thanks, I think that answers what I was trying to understand
<intrac> JEEB: oh, do you know if ffmpeg can report back this volume metadata (and possibly optionally disable it from being used)?
<intrac> oh, I can see that exiftool has a 'Preferred Volume : 100.00%' on one file I've tested at random
<intrac> I guess this might be the replaygain or equiv
System_Error has quit [Remote host closed the connection]
<JEEB> intrac: ffprobe most likely will list some stuff with `ffprobe -of json -show_sterams -show_format -i INPUT`
<intrac> JEEB: thanks, I'll try that out :)
<JEEB> *streams of course
manwithluck` has quit [Remote host closed the connection]
System_Error has joined #ffmpeg
manwithluck` has joined #ffmpeg
Shine has quit [Read error: Connection reset by peer]
emanuele6 has quit [Read error: Connection reset by peer]
microchip_ has quit [Quit: There is no spoon!]
microchip_ has joined #ffmpeg
Shine has joined #ffmpeg
litheum has quit [Ping timeout: 248 seconds]
EmleyMoor has quit [Ping timeout: 268 seconds]
EmleyMoor has joined #ffmpeg
EmleyMoor has quit [Ping timeout: 245 seconds]
EmleyMoor has joined #ffmpeg
vincejv has quit [Ping timeout: 252 seconds]
xx has joined #ffmpeg
vincejv has joined #ffmpeg
litheum has joined #ffmpeg
beneth has joined #ffmpeg
emanuele6 has joined #ffmpeg
^Neo has joined #ffmpeg
^Neo has joined #ffmpeg
nikolay_ has joined #ffmpeg
hjckr has quit [Ping timeout: 245 seconds]
nikolay_ is now known as hjckr
Koltes has joined #ffmpeg
<Koltes> Hi. I'm trying to use FFMPEG to split an audio file. Almost all pages I've found are about video splitting, for which keyframes are important. I've found nothing related to eventual audio keyframes, so I believed FFMPEG would be able to split at exact times. It's actually not so accurate.
<Koltes> For instance, I've generated a 2 second long tone using Audacity, with a single "tick" at exactly 1 second. Yet when I `ffmpeg -i .\in.wav -f segment -segment_times 1 out%02d.wav`, the split occurs at 1.021 s, meaning it's almost 1000 samples off.
<Koltes> Is it expected? How could it be more accurate?
<Koltes> Thanks in advance :)
<Koltes> BTW ffmpeg version 7.1-full_build-www.gyan.dev installed via Scoop.
Koltes has quit [Remote host closed the connection]
Koltes has joined #ffmpeg
<kepstin> Koltes: the splitting using the segment muxer happens after audio encoding, so it can only split at the boundaries of "frames" produced by the encoder. it's not aware of the fact that "frames" in pcm audio like in wave can be split, it treats them as indivisible units.
<kepstin> what is your goal here? maybe there's a different way to think about what you're trying to do.
Marth64 has joined #ffmpeg
lexano has quit [Remote host closed the connection]
olndrxyz has joined #ffmpeg
abdu has joined #ffmpeg
microlappy has joined #ffmpeg
<vlt> Koltes: Maybe sox can help here.
microlappy has quit [Quit: Konversation terminated!]
microlappy has joined #ffmpeg
Marth64[m] has joined #ffmpeg
Marth64 has quit [Ping timeout: 260 seconds]
rsx has joined #ffmpeg
microlappy has quit [Quit: Konversation terminated!]
Marth64[m] is now known as Marth64
microlappy has joined #ffmpeg
turlando has joined #ffmpeg
microlappy has quit [Ping timeout: 244 seconds]
minimal has joined #ffmpeg
rsx has quit [Quit: rsx]
abdu has quit [Ping timeout: 240 seconds]
HarshK23 has quit [Quit: Connection closed for inactivity]
olndrxyz has quit [Read error: Connection reset by peer]
olndrxyz has joined #ffmpeg
sentriz has quit [Ping timeout: 260 seconds]
abdu has joined #ffmpeg
sentriz has joined #ffmpeg
lexano has joined #ffmpeg
System_Error has quit [Remote host closed the connection]
System_Error has joined #ffmpeg
rvalue- has joined #ffmpeg
rvalue has quit [Ping timeout: 260 seconds]
rvalue- is now known as rvalue
HarshK23 has joined #ffmpeg
Marth64 has quit [Remote host closed the connection]
Shubham has joined #ffmpeg
<Koltes> kepstin: Thanks, I was also expecting chunks as "audio frames", but none of `-filter:v fps=30 -r 30 -force_key_frames 'expr:gte(t,n_forced)'` work, or altogether. Also I've chosen to split at second 1 to fit in frames, hoping that framerate is an integer.
<kepstin> size of audio frames (i.e. number of samples of audio in a frame) depends on the codec. video framerate is irrelevant, and all audio frames (in most codecs) are already "key frames". size of audio frames is usually based on either programming convenience or details of how the compression format works, so there's no reason that it'll be a nice factor of 1 second.
<furq> the asegment muxer will do this properly i think
<furq> at the cost of a much more annoying command
<furq> the asegment filter i mean
<kepstin> for uncompressed pcm audio specifically, using the asetnsamples filter will let you re-frame the audio to have a different number of samples per frame. But that won't help you with compressed audio formats.
Shubham has quit [Quit: Client closed]
<kepstin> Koltes: anyways - going back - i did ask you "what is your goal here? maybe there's a different way to think about what you're trying to do."
<Koltes> Background: it's for organizing a character animation festival, where groups of people have each a couple of seconds to make. Musicians made a music for us. Now I want to split the music, so that each group is given its music chunk. Having an offset of half a frame (at 24 fps) is okay, but annoys my perfectionist ego.
Shubham has joined #ffmpeg
System_Error has quit [Remote host closed the connection]
<kepstin> you might be best off using the "atrim" filter, and running a separate ffmpeg command with different arguments to that filter for each segment you want to extract. No easy way to do sample exact splitting and generate multiple files like you want in a single command with ffmpeg.
Marth64 has joined #ffmpeg
<kepstin> but "ffmpeg -i audio_track.wav -af atrim=start=0:end=1 segment_1_audio.flac" will give you exactly the audio you want, and you can run it again with all the numbers incremented by 1 to get the next segment.
<kepstin> er, wait, misread it, that also works on frame boundaries by default. that's annoying.
<kepstin> er, wait, maybe i'm misunderstanding the docs
shibboleth has joined #ffmpeg
<furq> pretty sure that works
<Koltes> furq: asegment does work! Complex command is no problem as it's generated anyway.
<furq> but yeah that works
<kepstin> yeah, if you're able to script the generation of the command, asegment will be equivalent but should be a bit faster.
System_Error has joined #ffmpeg
<kepstin> when you're combining submissions to generate the final file, better to use the original full audio track rather than attempt to concatenate the separate audio tracks chunks - if the audio tracks got compressed with a lossy format at some point, it'll be hard to get everything joined properly.
beaver has joined #ffmpeg
<Koltes> We'll combine the video frames and add the original music on top, there'll be no recombination of audio, the chunks just serve as a hint for the groups to produce the frames.
<Koltes> But ignoring the compression step, I was expecting that recombination could work, and it appears to be the case with asegment.
<Koltes> Besides I'm interested in taking and outputting .ogg files, not .wav, and you said asetnsamples wouldn't work.
Shubham has quit [Quit: Client closed]
Shubham has joined #ffmpeg
abdu9 has joined #ffmpeg
<Koltes> Thanks all for your help! Filter graphs is a new land for me, so I've even learned new things :)
lavaball has quit [Remote host closed the connection]
abdu has quit [Ping timeout: 240 seconds]
<Shubham> Hello I am Shubham Nayak, I am interested to be a GSOC contributor in FFMPEG this year. It would be great if someone could point me to beginner friendly issues where I can contribute.

Also, some getting started tasks that will help me understand the code base would help.
<Shubham> Thanks in advance.
<JEEB> you probably want to poke #ffmpeg-devel
<JEEB> but start with building :)
coldfeet has joined #ffmpeg
<JEEB> essentially, something like `mkdir -p lunix_build && cd lunix_build && path/to/ffmpeg/configure` and if the configuration succeeds, `make -jN` should work, where N is the amount of things you want to build/link at the same time
shibboleth has quit [Quit: shibboleth]
Shubham has quit [Quit: Client closed]
olndrxyz has quit [Read error: Connection reset by peer]
olndrxyz has joined #ffmpeg
iive has joined #ffmpeg
olndrxyz has quit [Read error: Connection reset by peer]
olndrxyz has joined #ffmpeg
YUiNA has joined #ffmpeg
beaver has quit [Quit: Tor daemon upgrade truc du style]
beaver has joined #ffmpeg
System_Error has quit [Remote host closed the connection]
<Koltes> kepstin: I've tried a bit further. Neither asegment nor asetnsamples are sample-perfect when both input and outputs are .ogg. I haven't found a way to reencode the streams, before or as part of the filter graph. Is it even possible, or do I have to simply reencode to .wav using another ffmpeg command?
<kepstin> ffmpeg decodes, filters, then encodes always
<kepstin> ogg vorbis should be sample-exact
olndrxyz has quit [Read error: Connection reset by peer]
olndrxyz has joined #ffmpeg
System_Error has joined #ffmpeg
olndrxyz has quit [Read error: Connection reset by peer]
olndrxyz has joined #ffmpeg
olndrxyz has quit [Read error: Connection reset by peer]
olndrxyz has joined #ffmpeg
<Koltes> Ha, it actually works with *both* `asetnsamples=44100,asegment=timestamps=1000ms`. Beforehand I was mentioning only `asetnsamples` with `-f segment`, hoping for a simpler command.
olndrxyz has quit [Read error: Connection reset by peer]
coldfeet has quit [Quit: Lost terminal]
olndrxyz has joined #ffmpeg
olndrxyz has quit [Read error: Connection reset by peer]
olndrxyz has joined #ffmpeg
kushal__ has joined #ffmpeg
kus has quit [Ping timeout: 252 seconds]
nitrix has quit [Remote host closed the connection]
Flat has quit [Ping timeout: 252 seconds]
nitrix has joined #ffmpeg
Flat has joined #ffmpeg
coldfeet has joined #ffmpeg
abdu9 has quit [Ping timeout: 240 seconds]
olndrxyz has quit [Read error: Connection reset by peer]
abdu9 has joined #ffmpeg
olndrxyz has joined #ffmpeg
olndrxyz has quit [Read error: Connection reset by peer]
olndrxyz has joined #ffmpeg
olndrxyz has quit [Read error: Connection reset by peer]
coldfeet has quit [Quit: Lost terminal]
olndrxyz has joined #ffmpeg
lavaball has joined #ffmpeg
pit has joined #ffmpeg
abdu15 has joined #ffmpeg
abdu9 has quit [Ping timeout: 240 seconds]
ryoskzypu has quit [Ping timeout: 264 seconds]
ryoskzypu has joined #ffmpeg
olndrxyz has quit [Read error: Connection reset by peer]
olndrxyz has joined #ffmpeg
Marth64 has quit [Quit: Leaving]
System_Error has quit [Remote host closed the connection]
olndrxyz has quit [Read error: Connection reset by peer]
olndrxyz has joined #ffmpeg
olndrxyz has quit [Read error: Connection reset by peer]
olndrxyz has joined #ffmpeg
olndrxyz has quit [Read error: Connection reset by peer]
olndrxyz has joined #ffmpeg
olndrxyz has quit [Client Quit]
System_Error has joined #ffmpeg
abdu has joined #ffmpeg
talismanick has joined #ffmpeg
abdu15 has quit [Ping timeout: 240 seconds]
Shine has quit [Read error: Connection reset by peer]
VarunAgw has joined #ffmpeg
VarunAgw has quit [Remote host closed the connection]
Blacker47 has quit [Quit: Life is short. Get a V.90 modem fast!]
DauntlessOne4 has quit [Read error: Connection reset by peer]
DauntlessOne4 has joined #ffmpeg
mrelcee has quit [Quit: I want Waffles!]
ryoskzypu has quit [Ping timeout: 264 seconds]
ryoskzypu has joined #ffmpeg
mrelcee has joined #ffmpeg
mrelcee has quit [Remote host closed the connection]
mrelcee has joined #ffmpeg
s55 has quit [Read error: Connection reset by peer]
s55 has joined #ffmpeg
sr55 has joined #ffmpeg
s55 has quit [Read error: Connection reset by peer]
Paul0207 has joined #ffmpeg
emanuele6 has quit [Quit: good night]
<aaabbb> if i am converting a video to 10bit and i have a filter chain, should i convert to yuv420p10le at the beginning or end of the chain?
<aaabbb> like "-vf format=yuv420p10le,foo,bar,baz" or should it be "-vf foo,bar,baz,format=yuv420p10le"?
<aaabbb> i use the latter usually because it seems to be what -pix_fmt yuv420p10le does. so i guess the question is whether filters benefit at all from the higher precision of 10 bit. obviously some filters won't care, but what about filters like scale, or denoisers like hqdn3d?
<vlt> aaabbb: My gut always told me to put it first, so that filters that would use them would know that it makes sense :)
<devinheitmuell-1> If the video originated as 10-bit, it will be that way at the start of the Filtergraph. If you’re converting to 10-bit, you might as well do it at the end since it’s not like any of the filters are going to do anything that requires 10-bit (unless you have some custom filter that generates test patterns that include a 10-bit ramp)
<BtbN> processing 10 bit is slower than 8 bit, so if you don't profit from it quality wise, I'd put it as late as possible
<aaabbb> usually i just put it after the scale filter if i have one, since it will merge with it into a single scale filter, and the scale filter is usually at the end. but what filters would benefit from 10 bit?
<aaabbb> some like select, mpdecimate etc won't care, but filters that blur or denoise or merge?
<BtbN> I think you will need to test that. I doubt there's a noticeable difference, but I don't know
<furq> they might be slightly higher quality but i bet they're missing a lot of fast paths
<aaabbb> then i suppose if the denoising is done before downscaling, the downscaling probably eliminates any noticible difference
beaver has quit [Remote host closed the connection]
sr55 is now known as s55
s55 has quit [Changing host]
s55 has joined #ffmpeg
Guest27 has joined #ffmpeg
<Guest27> Hi, all. I have a DVD video that I ripped which has some interlacing. I heard that nnedi3 is the best for deinterlacing.
<Guest27> What would be the best command for the absolute highest quality deinterlacing/closest to lossless as possible?
<Guest27> Would this be sufficient? I'm not super knowledgeable on this stuff:
<Guest27> ffmpeg -i "input.mkv" -c:a copy -c:v libx265 -x265-params lossless=1 -vf "nnedi=weights='./nnedi3_weights.bin'" "output.mkv"
<aaabbb> if you are doing truly lossless, then don't deinterlace
<aaabbb> using true lossless will give you a gigantic and unnecessarily large file size though
<Guest27> I am actually planning on upscaling the video using Topaz Video AI, so the interlacing messes with the upscaling model slightly. I am not worried about file size or processing speeds as I have quite good storage and hardware.
<Guest27> What would be the "closest-to-lossless" or "absolute 100% ultimate" deinterlacing? I only need this so that I can provide really good input to the AI model whilst upscaling.
Koltes has quit [Ping timeout: 240 seconds]
<aaabbb> you would want to use vaporsynth qtgmc then
<aaabbb> it is not supported in ffmpeg. nnedi3 is very good but there is some content it is bad at
<Guest27> Ah! I have heard of that. I don't think it can be used with ffmpeg as you said, though. I will look it up and do some research. Thanks much.
Guest27 has left #ffmpeg [#ffmpeg]
SuicideShow has quit [Ping timeout: 248 seconds]
SuicideShow has joined #ffmpeg
lavaball has quit [Quit: lavaball]
DauntlessOne4 has quit [Read error: Connection reset by peer]
abdu has quit [Ping timeout: 240 seconds]
iive has quit [Quit: They came for me...]
lavaball has joined #ffmpeg