five618480 has quit [Remote host closed the connection]
five618480 has joined #ffmpeg
moviuro has quit [Quit: Reboot? Or did my jail(8) just die?]
moviuro has joined #ffmpeg
navi has joined #ffmpeg
jarthur has joined #ffmpeg
billchenchina has quit [Remote host closed the connection]
ballsxd has joined #ffmpeg
<ballsxd>
hey all, i have this movie file with a 24 bit DTS XXL audio track. i need to check if this track is padded with zeroes and if it is, remove it. how can i do this?
markizano has joined #ffmpeg
jarthur has quit [Ping timeout: 268 seconds]
jarthur_ has joined #ffmpeg
moviuro has quit [Quit: Reboot? Or did my jail(8) just die?]
omegatron has joined #ffmpeg
<Marth64[m]>
ballsxd: might need eac3to for that
<ballsxd>
Marth64[m]: i'm afraid that isn't packaged by my pm :p
Copy_of_nrg has joined #ffmpeg
<JEEB>
the track should be decode'able by FFmpeg, so then you'd have to somehow analyze the decoded result
waleee has quit [Ping timeout: 276 seconds]
nrg has quit [Ping timeout: 264 seconds]
Copy_of_nrg is now known as nrg
Marth64[m] has quit [Read error: Connection reset by peer]
<ballsxd>
i used ffmpeg -i title_t44.mkv -af astats -f null -. all 6 of the channels returned a bit depth of 24/24 so i think it's good :D
minimal has joined #ffmpeg
BtbN has quit [Ping timeout: 256 seconds]
Muimi has joined #ffmpeg
BtbN has joined #ffmpeg
lucasta has quit [Quit: Leaving]
Exagone313 has joined #ffmpeg
Exa has quit [Ping timeout: 252 seconds]
Exagone313 is now known as Exa
moviuro has joined #ffmpeg
alexherbo2 has quit [Ping timeout: 250 seconds]
luc4 has quit [Ping timeout: 256 seconds]
iive has joined #ffmpeg
Marth64 has joined #ffmpeg
alexherbo2 has joined #ffmpeg
<ballsxd>
is there a way for me to remove specific audio tracks from a mkv file?
duckscarf has joined #ffmpeg
<Marth64>
ballsxd: yup :)
<Marth64>
step 1) ffprobe INPUT.mkv ==> figure out the index # of the tracks you don't want
<Marth64>
step2) ffmpeg -i INPUT.mkv -map 0 -map -0:a:5 OUTPUT ===> as an example, uses the negative mapping feature to say "Copy all tracks except the 5th audio stream"
<Marth64>
where OUTPUT can be another mkv file. you have to remux in order to remove the tracks
<ballsxd>
can i also do this in reverse? like delete all audio tracks except for 0:1
<Marth64>
ballsxd: yes absolutely
<Marth64>
ffmpeg -i INPUT.mkv -map 0:0 -map 0:1 -c copy OUTPUT ===> copy only track 0 (video) and track 1 (audio track index 1)
<Marth64>
missed the -c copy earlier ... will need that
<duckscarf>
hello, does anyone use Media Player Classic here?
<ballsxd>
gonna test it on a copy first to save myself a lot of headache :)
<ballsxd>
seems like it worked Marth64! although i accidentally removed the wrong track xD
<ballsxd>
thank you :)
<Marth64>
ballsxd: np have fun
TheSashmo has joined #ffmpeg
yoo has quit [Ping timeout: 256 seconds]
rvalue has quit [Ping timeout: 268 seconds]
yoo has joined #ffmpeg
rvalue has joined #ffmpeg
yoo has quit [Ping timeout: 246 seconds]
duckscarf has left #ffmpeg [#ffmpeg]
<FlorianBad>
If I don't want to escape $path, how can I call ffmpeg using -i "$path/*.png" (since in this case obviously * is between quotes so it is therefore a character)
<FlorianBad>
I thought "$path/"*.png would work, but it doesn't for some reasons
<Marth64>
try "$path"/*.png
<Marth64>
bash should figure it out
<Marth64>
assuming bash
<Marth64>
although i am not sure if interpolation will work like that for input you might need a loop
<Marth64>
for f in "$mydir"; do ffmpeg -i "$f" ....; done
<Marth64>
backup plan^
<FlorianBad>
an wait a second... I think the error I'm getting might come from somewhere else ;) Maybe even "$path/*.png" might work
<Marth64>
i gave up on bash dealing with these types of games it was too much for me lol
<Marth64>
just started using python
<FlorianBad>
I hate Python so much, I use Perl
<Marth64>
even perl is ok
<Marth64>
i am just so done with bash for anything that is beyond super basic
<Marth64>
perl the glue of the internet for years
<FlorianBad>
yeah
<FlorianBad>
so in this case e.g. you would just make a list and pass it all as THOUSANDS of -i options?
<Marth64>
No I am now realizing what you are trying to do kinda
<Marth64>
You trying to turn sequence of PNGs into video?
<furq>
-pattern_type glob -i "$path/*.png"
<Marth64>
ya this ^^
<furq>
you specifically have to quote the * here to stop your shell interpreting it
<FlorianBad>
well, sort of, I do a lot of things with it, but my $path might have spaces for example, and I don't want to have to escape the whole thing, so using quotes is good, but then *.png is a problem with quotes. But again, hold on because it might come from somewhere else, because I believe "$path/"*.png should work in theory
<FlorianBad>
furq, ohoh!
<furq>
that would work if you wanted your shell to interpret the glob
<Marth64>
skip the shell use furq's command if you can
<Marth64>
save yourself the headache and time over trivial matters like space vs. no space quote and bash shenanigans
<Marth64>
also then you are no longer tied to bash and your functions are more portable later
<FlorianBad>
sure, also it makes more sense to pass only one thing to ffmpeg which then figures it out by itself
<Marth64>
yep less ambiguous
<Marth64>
sorry did not mean to come heavily opinionated on bash. bash is great. but it has its limits. i had once spent hours just trying to troubleshoot string interpolation until i realized "why am i wasting my time over trivial problems like this" that are a huge time sink
<FlorianBad>
maybe it's a bug then, what's your system furq?
<FlorianBad>
furq, hmmm did you try double quotes?
<furq>
-pattern_type glob -i "hls/*.png"
<FlorianBad>
that works for you?
<furq>
yes
<FlorianBad>
ok, well for me it doesn't
<sonicrules1234>
Are the png file names numbered?
<FlorianBad>
And it seems it's the same for the people in that stackoverflow page
<FlorianBad>
yes, it was generated with %05d.png
<furq>
-f image2 -i "%05d.png"
<sonicrules1234>
You can use the %05d.png as input too
<Marth64>
it works for me too
<sonicrules1234>
No need for pattern_type
<furq>
either should work
<FlorianBad>
ok, but it won't always be the case unfortunately
<sonicrules1234>
It works with sub directories too IIRC
<sonicrules1234>
You might also be able to feed the images through stdin
<Marth64>
does your shell scrip have the bash shebang at the top?
<Marth64>
wondering if another inteerpreter is at play?
<Marth64>
#!/usr/bin/env bash
<Marth64>
is the preferred shebang
<Marth64>
s/the/my
<FlorianBad>
well, I'm calling a perl script so hard to tell what it will have each time I run it
MajorBiscuit has joined #ffmpeg
<FlorianBad>
I think I might just handle that manually in perl, list all the dir, then put an array with -i ... -i .... etc.
<FlorianBad>
It's probably the most reliable solution
MajorBiscuit has quit [Client Quit]
<Marth64>
ah, so you are no using bash at all?
<FlorianBad>
So the equivalent would be -i png/0001.png -i png/0002.png -i png/0003.png correct?
<furq>
that will give you a million separate inputs instead of one video input
<Marth64>
no that wont work
<Marth64>
yea^
<FlorianBad>
I tried both, same thing. Technically perl should inherit of everything that was in the shell that executed perl, but I don't want to count on that. I might run that script 3 years from now on another machine and not understand why it's not working...
<FlorianBad>
furq, ah... hmm, so how does ffmpeg understsands the frame-by-frame png inputs then?
<Marth64>
there is a special demuxer called image2
<Marth64>
it will concatenate things based on the patten
<FlorianBad>
hmm, so then I can just use the cd trick and go with: cd png ; ffmpeg -f image2 -i * ../output-png/%05d.png ?
<FlorianBad>
or "*" in this case?
<furq>
you're missing -pattern_type glob
<FlorianBad>
ok I see
<sonicrules1234>
Looking at a program I wrote a while back, you can indeed pipe the images into ffmpeg
TheSilentLink has quit [Ping timeout: 268 seconds]
<kepstin>
for some image formats, yes; it depends on whether the image format is supported by image2pipe (it has to be able to parse out / separate the images in the stream)
<FlorianBad>
I could use that, right? > ffmpeg -f image2 -pattern_type glob -i "png/*.png" -preset slower -tune film -c:v libx264 -b:v 4000k -pix_fmt yuv420p -profile high -c:a libfdk_aac -b:a 256k -ar 44100 -ac 2 -f mp4 -y bitrate1.mp4 -c:v libx264 -b:v 2000k -pix_fmt yuv420p -profile high -c:a libfdk_aac -b:a 128k -ar 44100 -ac 2 -f mp4 -y bitrate2.mp4
<FlorianBad>
And if so, should the -preset and -tune options be before each -profile instead?
<BtbN>
the order of options is almost always irrelevant. They always affect the next input/output following them.
<FlorianBad>
yeah, which means that my -preset and -tune placed at the beginning will only affect the first output? Or will they remain for the second one?
bitoff has quit [Ping timeout: 256 seconds]
bitoff has joined #ffmpeg
<FlorianBad>
If I ever want to use -pass 3 all 3 passes use the same -passlogfile file? They will just continue writing to it and then read from it all passes?
five618480 has quit [Remote host closed the connection]
<kepstin>
any option is per-input or per-output unless it's specifically marked as global in the docs. I already told you this yesterday :)
five618480 has joined #ffmpeg
realies has joined #ffmpeg
Tano has quit [Quit: WeeChat 4.1.2]
<FlorianBad>
kepstin, I don't understand how that relates to my question though? These will be different instances of ffmpeg
cingorf has joined #ffmpeg
<kepstin>
that was an answer to your questions about which outputs will be affected by options
<kepstin>
regarding multiple passes; yes, all passes need to use the same data file. In general it's write-only by pass 1, and read-only by pass 2. There's not normally any use case for so-called "3-pass" mode, it's more of a curiosity.
<kepstin>
(with libx264 in multi pass mode, you do a first pass with -pass 1, then all following passes with -pass 3, and all of the following passes read the file, then rewrite it when they complete using updated stats)
<cingorf>
It seems like I can cut the beginning of a video with -ss or the end with -sseof but how can I cut 10s from the start and 10s from the end? I want to use -c copy and I am looking for a way that doesn't require me to know the length of the video.
MrZeus has quit [Ping timeout: 260 seconds]
<kepstin>
FlorianBad: it is critically important when running multiple separate instances of ffmpeg that each has a different value for -passlogfile
<kepstin>
FlorianBad: er, that is - if you're using multiple instances to encode multiple videos in parallel
Tano has joined #ffmpeg
Vonter has quit [Ping timeout: 240 seconds]
<kepstin>
cingorf: nothing provided in the ffmpeg cli; you're free to use e.g. ffprobe to find out how long the video is before running the ffmpeg command.
<FlorianBad>
kepstin, yes, I was talking about one pass after the other, not parallel
<FlorianBad>
(I see, you were referring to my previous question)
Vonter has joined #ffmpeg
<FlorianBad>
kepstin, regarding -pass 3 you mean that pass 3 would in fact result in strictly the same as -pass 2 ? If they rewrite the file then in theory at least they learned from each previous pass?
<kepstin>
in theory, performing additional passes might allow it to achieve more accuracy on hitting your target bitrate.
<kepstin>
it will _not_ increase quality.
<kepstin>
(unless it results in increasing bitrate, then quality will slightly increase as a side-effect)
SuicideShow has quit [Ping timeout: 268 seconds]
<kepstin>
in practise, libx264's rate control is so good that the accuracy improvement with more than 2 passes is so small that it's not really necessary
<cingorf>
kepstin: Okay, thanks. That's the only method I've found. It's nicer in bash but a little clumsy in Windows cmd.
<kepstin>
just a waste of time, really
<FlorianBad>
I see, well in my case it's actually important because I will have many bitrates that my custom back-end will choose from, so it's a good idea to be pretty accurate
<FlorianBad>
ah, ok
<FlorianBad>
Will test that to see
SuicideShow has joined #ffmpeg
<kepstin>
(using -pass 3 unnecessarily instead of -pass 2 will also slow down the encode, since it results in x64 having to track statistics during the encode. very small difference, but it's there)
<kepstin>
in libx264*
Marth64 has quit [Remote host closed the connection]
<kepstin>
an amusing fact - the "crf" mode that's a cool feature of x264 is actually an internal implementation detail of how their 2-pass encode works. During pass 1 it performs a normal ABR encode tracking stats, then it uses those stats to calculate a "constant rate factor" that's applied to a measure of per-frame complexity to determine how many bits to use for each frame in the second pass.
<kepstin>
but then they allowed you to provide a crf value directly to run a second pass encode without doing a first pass :)
<FlorianBad>
but doesn't that force a rate that may not be necessary at a particular point in the video?
<kepstin>
not sure what you mean. the way it works, it guarantees that the amount of bits used for each frame is proportional to how complex the frame is to encode, providing "even" visual quality over the whole video.
<FlorianBad>
BTW, obviously I should not provide any audio input nor output for any pass that isn't the last one, right? Since it will go to -f null - anyway
<kepstin>
it does the exact opposite of forcing a rate that isn't necessary at a certain point in the video.
<FlorianBad>
ah! ok I see, it's a proportion of that factor of complexity of video
<kepstin>
FlorianBad: it's generally a good idea to disable audio processing during a multipass video encode, yes. makes it run faster, saves energy :)
<FlorianBad>
ok
<FlorianBad>
Do I need to use -lavfi '[0:v]split=2[v1][v2]' if my -map "[v1]" and v2 will simply be the same thing with a different bitrate? I wrote that in my notes a few days ago but now I wonder why split it in the first place
<kepstin>
keep in mind that performing a 2-pass encode ensures that the _average_ bitrate will be on target, but individual portions of the video might be _much_ lower or _much_ higher than average depending on complexity. This could cause issues for internet streaming; a complex section of video might cause buffering even if someone's connection could handle the specified average.
<kepstin>
you can use vbv controls in combination with a 2-pass encode to limit the max short-term bitrate that's permitted to be used, based on expectations of client buffer amounts.
<kepstin>
that will cause the visual quality of extremely complex/high motion scenes which would require more bitrate to be reduced compared to the rest of the video.
<FlorianBad>
yeah I know, I plan to have my back-end select the various qualities available based on filesize of each chunk, so the original -b:v 1234k value is only there to make sure all these bitrates available are evenly far apart
<kepstin>
if you're going to be doing that, then don't bother with a 2-pass encode at all. Just use straight crf encodes.
<kepstin>
crf is proportional to filesize on a decibel scale - adding ~6 to crf halves filesize
<FlorianBad>
hmm, so using crf will allow me to have more evenly spaced filesizes for each chunk ("stream") of dash output?
<kepstin>
but if you're mixing and maxing chunks, then it's important that your gop boundaries align, which means using fixed gop length and disabling scene-cut detection.
<kepstin>
that's... complicated
<FlorianBad>
ah! Well, I'm very interested in that! tell me more please!
<FlorianBad>
lol
<FlorianBad>
so far the only thing I was going to use about this is for the container, doing this: -movflags frag_keyframe+empty_moov+default_base_moof
<kepstin>
in general, you want to avoid sudden jumps in visual quality getting better or worse
<FlorianBad>
But now you're saying that x264 should also have some special options if I want to transition from a chunk of dash to another that used a different bitrate ?
<kepstin>
which means that for less complex scenes, you will _on purpose_ be serving chunks which have lower bitrate than the stream specified average, to make sure that there's no sudden quality loss when you hit a complex section.
<FlorianBad>
kepstin, yes my program will handle that too, it won't just react without keeping track of what happened before...
<kepstin>
the point is that if you react, you've lost - if you are forced to do a quality switch, that's going to be noticable degradation or inconsistency to the viewer.
<FlorianBad>
I'm ok with that, because it will be very rare, most likely that in the first 4 seconds of video it detected everything and will stick to the same quality for the rest of the video, unless it was calculated that the video will stop. Don't worry I will write that well, it's not an issue
<kepstin>
for live streams specifically, there's some interesting arguments the other way - connections aren't able to quickly scale up the amount of bitrate they're transferring, even if the available max bandwidth would be sufficient. so you need to make sure that the bitrate stays relatively even, even if doing so means wasting bits on easy-to-encode sections of video.
<kepstin>
for VoD stuff with sufficient buffers, that's not something you need to care about
<FlorianBad>
don't forget I will know what comes next in my video, which means I know exactly which version will fit based on browser/cpu/fps and bandwidth stats that I gathered up to that point
<kepstin>
well, as long as you know the max bitrate of upcoming chunks at the current quality level, that should be good yeah :)
<FlorianBad>
that's right
<FlorianBad>
as I said I will write this very well ;)