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
minimal has quit [Quit: Leaving]
Unit640 has quit [Quit: Leaving]
shibboleth has joined #ffmpeg
iive has quit [Quit: They came for me...]
shibboleth has quit [Quit: shibboleth]
Sketch has quit [Ping timeout: 265 seconds]
crossby1004 has quit [Quit: leaving]
lusciouslover has quit [Read error: Connection reset by peer]
realies8 has joined #ffmpeg
lusciouslover has joined #ffmpeg
realies8 is now known as realies
realies has quit [Ping timeout: 272 seconds]
billchenchina has joined #ffmpeg
\\Mr_C\\ has quit [Remote host closed the connection]
Sketch has joined #ffmpeg
billchenchina- has joined #ffmpeg
billchenchina has quit [Ping timeout: 260 seconds]
sentriz has joined #ffmpeg
a0z has joined #ffmpeg
billchenchina has joined #ffmpeg
billchenchina- has quit [Ping timeout: 276 seconds]
Muimi has joined #ffmpeg
luva8889 has joined #ffmpeg
luva888 has quit [Ping timeout: 260 seconds]
militantorc has quit [Quit: Free ZNC ~ Powered by LunarBNC: https://LunarBNC.net]
billchenchina has quit [Ping timeout: 260 seconds]
lucasta has quit [Quit: Leaving]
shibboleth has joined #ffmpeg
fling has quit [Remote host closed the connection]
fling has joined #ffmpeg
dostoyevsky2 has quit [Ping timeout: 252 seconds]
billchenchina has joined #ffmpeg
dostoyevsky2 has joined #ffmpeg
moviuro has quit [Quit: Reboot? Or did my jail(8) just die?]
moviuro has joined #ffmpeg
billchenchina has quit [Remote host closed the connection]
billchenchina has joined #ffmpeg
billchenchina has quit [Max SendQ exceeded]
moviuro has quit [Excess Flood]
billchenchina has joined #ffmpeg
billchenchina has quit [Client Quit]
moviuro has joined #ffmpeg
MrZeus has quit [Ping timeout: 260 seconds]
StephenLynx has quit [Quit: Leaving]
JanC_ has joined #ffmpeg
JanC is now known as Guest8309
Guest8309 has quit [Killed (silver.libera.chat (Nickname regained by services))]
JanC_ is now known as JanC
Muimi has quit [Quit: Going offline, see ya! (www.adiirc.com)]
shibboleth has quit [Quit: shibboleth]
a0z has quit [Quit: Leaving]
a0z has joined #ffmpeg
billchenchina has joined #ffmpeg
Muimi has joined #ffmpeg
Sketch has quit [Ping timeout: 276 seconds]
Some_Person has quit [Ping timeout: 276 seconds]
Some_Person has joined #ffmpeg
Muimi has quit [Remote host closed the connection]
lusciouslover has quit [Ping timeout: 260 seconds]
lusciouslover has joined #ffmpeg
low-key has quit [Ping timeout: 252 seconds]
FH_thecat has quit [Quit: Leaving]
yuckey2d3 has quit [Quit: Ping timeout (120 seconds)]
yuckey2d3 has joined #ffmpeg
Some_Person has quit [Ping timeout: 260 seconds]
tokyovigilante has quit [Ping timeout: 245 seconds]
tokyovigilante has joined #ffmpeg
Sketch has joined #ffmpeg
Some_Person has joined #ffmpeg
bengalih has joined #ffmpeg
<bengalih>
Hello. I am trying to chop a large (12 hour+) audio file up into multiple segments using multiple -ss/-to positional operations. It works fine, but was taking about 4 minutes. When I reverted to older versions this operation completes much quicker. About 20 seconds with version 6.1 and about 10 seconds on version 5. There is some discrepancy with how the old versions report the length of
<bengalih>
the file (it appears to show only about 6.5 hours processed), but the reulting output files appear to be correct.
drew has quit [Ping timeout: 248 seconds]
drew` has joined #ffmpeg
<bengalih>
This is an example of the syntax I am using:
<bengalih>
Perhaps my usage syntax is wrong, I arrived on this because using individual command were processing the entire file each time to parse out the section I wanted. This syntax I am using appeared to work quickly in comparison. However when I see the older versions process it in a matter of seconds instead of minutes something has obviously changed, and perhaps there is a better syntax to use.
billchenchina has quit [Read error: Connection reset by peer]
billchenchina has joined #ffmpeg
welder has quit [Quit: WeeChat 3.8]
billchenchina- has joined #ffmpeg
billchenchina has quit [Ping timeout: 260 seconds]
<bengalih>
re: the quicker versions shwoing the wrong time, I am speaking specifically about "out_time" output. They seem to be inaccurately reporting it as about 6.5 hours instead of 12, however the resultant total duration of the created files is actually correct (12 hours).
billchenchina- has quit [Ping timeout: 260 seconds]
<bengalih>
If I split them up into individual commands with -ss/-to *before* the input, then it actually takes longer with version 5/6, about 45 seconds. However with the latest version 7 it takes about 1 min, 15 secs. Much better than the 4 minutes using my monolotihic format but still well slower than using version 5/6 with my pastebin syntax.
<bengalih>
So, in short, why am I able to (apparently) properly split this 12 hour file into about 25 different segments in about 10 seconds using the pastebin format on version 5, but it takes 2x that long on 6, and 30x that long on 7? I assume there are just syntax changes I can't figure out.
<ChocolateArmpits>
bengalih, are you sure the file or portions of it don't get cached during your tests?
low-key has joined #ffmpeg
low-key has quit [Remote host closed the connection]
microchip_ has quit [Read error: Connection reset by peer]
microchip_ has joined #ffmpeg
evilscreww has joined #ffmpeg
microchip_ has quit [Client Quit]
microchip_ has joined #ffmpeg
xx has quit [Remote host closed the connection]
crossby1004 has joined #ffmpeg
stolen has joined #ffmpeg
makidoll has quit [Remote host closed the connection]
makidoll has joined #ffmpeg
StephenLynx has joined #ffmpeg
xx has joined #ffmpeg
crossby1004 has quit [Quit: leaving]
lucasta has joined #ffmpeg
blb has quit [Remote host closed the connection]
blb has joined #ffmpeg
ChocolateArmpits has quit [Read error: Connection reset by peer]
minimal has joined #ffmpeg
Unit640 has joined #ffmpeg
Traneptora has quit [Quit: Quit]
ewomer has quit [Read error: Connection reset by peer]
j45 has joined #ffmpeg
ewomer has joined #ffmpeg
billchenchina has joined #ffmpeg
coldfeet has quit [Remote host closed the connection]
billchenchina has quit [Remote host closed the connection]
billchenchina has joined #ffmpeg
elvis_a_presley has quit [Quit: smoke-bomb ; grapple-hook]
elvis_a_presley has joined #ffmpeg
Juest has quit [Ping timeout: 265 seconds]
rsx has quit [Quit: rsx]
Juest has joined #ffmpeg
phonemic has quit [Ping timeout: 246 seconds]
phonemic has joined #ffmpeg
<bengalih>
I'm fairly certain, although I'm not sure where they could get cached. My script deletes the files upon each run and the runs are fully recreatable in terms of time. So regardless of the pattern I try in, the results are always the same for each version of ffmpeg.
<furq>
bengalih: no idea about what changed but you probably want to use the segment muxer and -segment_times
crossby1004 has joined #ffmpeg
<furq>
you'd have to rename the files afterwards but i guess this is already all generated by a script
<bengalih>
Yes I did see that was option, but would rather not have to perform all that extra scripting, although I might test that method just to see the results. The results are just so wildly inconsistent between versions I would like to figure out why this is happening. How can the same syntax take 10 seconds on 5, 20 seconds on 6, and 4 minutes on 7+? I can't find anything in changelog that would
<bengalih>
describe this and such a performance decrease on later versions seems very strange.
<bengalih>
I just tried with just segment times option instead and it was fairly quick, but problem with segment option is you can't overlap at all, the times have to be sequential
ewomer has quit [Quit: WeeChat 4.4.2]
ShadowJK has quit [Ping timeout: 255 seconds]
evilscreww has quit [Quit: Leaving]
FH_thecat has quit [Quit: Leaving]
billchenchina has quit [Remote host closed the connection]
ewomer has joined #ffmpeg
<bengalih>
What is also crazy is using the segment method, the current version takes ~20 seconds, and version 6 takes like 12 seconds.
<bengalih>
so..yes, segment is quicker, but still almost 80% slower than prior versions?!?
MetaNova has quit [Quit: quit]
MetaNova has joined #ffmpeg
<noobaroo>
When i save a livestream sometimes it switches resolutions if the uploader connection changes, usually if they are walking around and livestreaming from a phone
<noobaroo>
I know how to use -ss and -t/-to to cut and separate if I have to do it this way and just get it approximate but is there a way to separate the good resolution half of the video with the bad ?
coldfeet has joined #ffmpeg
FH_thecat has joined #ffmpeg
coldfeet has quit [Remote host closed the connection]
<furq>
i don't think there's a way to do that without decoding
<furq>
-flags drop_changed if you are decoding
Krusher has quit [Quit: Leaving]
<BtbN>
Neither Twitch nor YT support resolution changes mid stream as far as I'm aware.
<BtbN>
Is it just scaling on the fly or something?
tomaw has quit [Remote host closed the connection]
tomaw_ has joined #ffmpeg
tomaw_ is now known as tomaw
noobaroo has quit [Ping timeout: 252 seconds]
microchip_ is now known as putacho
Buliarous has joined #ffmpeg
<bengalih>
So I've done some more testing, and to the best of what I can tell, the later the version of ffmpeg, the slower it performs. My script performs 3 tasks: 1) concat several files into only large mp3 (copy) 2) split this large file up into about 35 segments. In these tests I am using the "segment" method as we just discussed and 3) Tag each created file with some metadata. The times for each
<bengalih>
tasks with versions 5, 6, and 7 are the following (in order)
<bengalih>
ffmpeg 5: 8, 10, 39 seconds
<bengalih>
ffmpeg 6: 14, 17, 39 seconds
<bengalih>
ffmpeg 7: 25, 23, 55 seconds
welder has joined #ffmpeg
chandash has joined #ffmpeg
StephenLynx has quit [Ping timeout: 245 seconds]
StephenLynx has joined #ffmpeg
TheSilentLink has quit [Ping timeout: 272 seconds]
lavaball has quit [Remote host closed the connection]
<bengalih>
I've simplified it down to a simple command, extracting a 6.5 hour segment out of the 12 hour file:
<Wulf>
Hi. How can I extract the first frame of a video and store it in a new video file?
<Wulf>
I know that the video will be, well, very short. I need it for a bug report/
MrZeus has joined #ffmpeg
<furq>
Wulf: -i foo.mkv -frames:v 1 bar.png
<furq>
ignore the warning
<bengalih>
Is this something I should be filing a bug report or regression for? I don't understand how a simply command like above (-ss/-to) performs substantially worse with later versions. Unless some default behavior changed and I'm supposed to use a different switch/syntax?
<Wulf>
furq: thanks
<BtbN>
stream copying mp3 should always be incredibly fast. For it to 30 seconds, I'd expect the file to be multiple gigabytes
<BtbN>
+take
<bengalih>
It is not. The entire file is about 350MB and the output is about 190 MB.
<bengalih>
And the exact same command just run with different binaries has drastically different extraction times
<BtbN>
Sounds like something is wrong with your binaries, or storage. There is no good reason, it's not doing anything noteworthy
<BtbN>
mp3 is not even muxed
<bengalih>
I have some 7 version installed as my main version which is what is taking forever, I download some specific builds from both windows sources and they seem to be much quicker. This is what is taking forever:
<bengalih>
ffmpeg version N-113322-ga87a52ed0b-20240114 Copyright (c) 2000-2024 the FFmpeg developers
<bengalih>
let me try to grab the latest 7 version and see if it is the same.
<BtbN>
It should pretty much only ever be limited by I/O speed
<furq>
i can't reproduce that here
<furq>
takes about three seconds to cut four hours out of a five-hour file on an ssd
<furq>
on a windows build of 7.1
<BtbN>
Yeah, hence my suspicion that something is wrong with those binaries/files/disks
<chandash>
bengalih: what happens if you do `-c:a` instead of `-c`
<furq>
encoding a 12-hour file now just in case
<BtbN>
If stream copying got ridiculously slow suddenly, I'm sure we'd have long heard about that
<furq>
-c should make no difference
<BtbN>
-c:a and -c are completely identical for an mp3 files, ignoring maybe cover art
<furq>
the only way that would make a difference is if there's album art in which case that would make it very slightly slower
<bengalih>
Ok, so the version that I apparently have installed on my system " N-113322-ga87a52ed0b-20240114" seems to maybe be problematic. I downloaded your lated build and it seems to be quicker. I need to try and locate " N-113322-ga87a52ed0b-20240114" and download it directly and test with it stright from the zip to see if the issue was with that version or something on my system.
<bengalih>
Any idea what the source of that build is?
<furq>
that's just a normal ffmpeg build id
<bengalih>
I'm trying to locate that on the downloads, not sure which it would be, I don't see a build with that date.
<furq>
idk about all the ffmpeg builds for windows nowadays but i think everyone except BtbN tags theirs somewhere
<furq>
so i would guess it's one of his
<bengalih>
Yeah that's where I'm looking
<BtbN>
I think I'm the only one adding the date at the end
<furq>
at least the windows build i have has "gyan.dev" in -version
<BtbN>
That's not normally there
<bengalih>
I would have thought I got it there, but maybe somehow on this system I got a rogue build somewhere? BtbN is this one of your builds?
<BtbN>
Unless someone else decided to also add the date to the end
<bengalih>
Would I still be able to locate it? On your GH I only see a 12/31 and a 1/31 build, no 1/14.
<bengalih>
I'll try both of those and see if I can recreate the issue.
<furq>
there's only monthly builds beyond two weeks ago
<BtbN>
If the latest works, it would seem the issue is solved?
<bengalih>
yes, but I would like to understand what happened... I tried those two builds and they both seem ok, so I can only assume I got a rogue build from somewhere? Ok, so yes - mostly resolved, but I am still curious about this thing:
<bengalih>
when I first wrote my script I was using this command here, I arrived on it as the "quickest" way to do it based on the issues I was having..
<bengalih>
basically using a monolithic command as shown. This syntax works much quicker in 5/6 then in 7. Any ideas why?
<bengalih>
anyway, I've rewritten my script to use individual -ss -to commands for each section and include the metadata I want in each file. The entire split of the 12 hour file into 25 chapters now only takes about 35 seconds with your latest build, so I think that is acceptable.
<bengalih>
*35 chapters
<bengalih>
The only thing I'm trying to optimize is a conversion from mp3 to AAC. I'm using pretty simple syntax "-map 0:a -c:a aac -b:a 64k" is there any thing else that might make the encoding go faster (apart from a CPU upgrade :) ).
<furq>
not without running multiple jobs in parallel
<furq>
which is something you'd have to script yourself
<bengalih>
so performance with parallel jobs is even quicker than just using all threads sequentially?
<furq>
the aac encoder is singlethreaded
<furq>
i don't know of any audio encoder that uses multiple threads
rex has quit [Ping timeout: 265 seconds]
phonemic has joined #ffmpeg
rex has joined #ffmpeg
<bengalih>
thanks, did some tests and seems right...will try to script it.
chandash has quit [Ping timeout: 252 seconds]
jbennett1 has quit [Quit: WeeChat 4.4.2]
System_Error has quit [Remote host closed the connection]
iliv has quit [Quit: "<paniq> you know when i walk out the door, there is plenty of stupid people. i open irc, there is plenty of intelligent people. so the choice comes easy."]