<FlorianBad>
kepstin, so you were saying that x264 would require (or benefit) to have other things like gop options and scene-cut?
<FlorianBad>
Shouldn't it detect everything the same if I run all that in the same ffmpeg command with multiple outputs?
<FlorianBad>
Really the only parameters that changes for each output are bitrate of x264 and aac
<kepstin>
different encoding settings (video size, bitrate, etc) may cause x264 to make different decisions on where to place IDR frames
<FlorianBad>
(will be same resolution per ffmpeg command)
<FlorianBad>
ok, will look into gop and scene-cut then
<kepstin>
it's just the "-g" option to ffmpeg to set the gop size; you'll need "-x264opts scenecut=0"
<kepstin>
to disable scenecut detection
<FlorianBad>
but doesn't disabling scenecut detection harms quality a lot?
<furq>
not really for segmented streams
rvalue has quit [Ping timeout: 268 seconds]
<FlorianBad>
So the idea is that if the IDR frames end up at different locations when I switch from a chunk to another that will cause serious trouble when playing?
<furq>
the segment has to start on an idr frame
<furq>
so if they're in different positions then the segments won't start at the same time
<furq>
which obviously isn't great for playack
<furq>
b
<FlorianBad>
ah lol
<furq>
also remember there are non-idr i-frames
<FlorianBad>
Well I can check that with my script though just to make sure, because the various segments w/ timescale and d= and r= values will not match?
<furq>
which x264 can put in the middle of a segment if it feels it needs to
<FlorianBad>
So my script can already output an error if that's ever the case (for the context, what I'm coding now is a script that will take the final project export PNG+wav and turn it into all resolutions and all bitrates, then dash chunks)
<FlorianBad>
(and ready that for my custom back-end server)
<FlorianBad>
ok
<FlorianBad>
so these non-IDR i-frames are not a problem then, they just improve quality?
<FlorianBad>
And I'm assuming that the scenecut detection cannot use non-IDR I-frames?
cingorf has left #ffmpeg [#ffmpeg]
rvalue has joined #ffmpeg
navi has quit [Quit: WeeChat 4.0.4]
<FlorianBad>
furq, is ffmpeg -g 5 the same as -x264opts keyint=5 ?
lexano has quit [Ping timeout: 264 seconds]
Frayk has joined #ffmpeg
lavaball has quit [Quit: lavaball]
ivanich has quit [Read error: Connection reset by peer]
Tinos has joined #ffmpeg
Frayk has quit [Read error: Connection reset by peer]
slydacyfa has joined #ffmpeg
<FlorianBad>
furq, AH! CRF/CQP is incompatible with 2pass well then it's not even a question lol
s55 has quit [Ping timeout: 264 seconds]
iive has quit [Quit: They came for me...]
faxmodem has quit [Ping timeout: 260 seconds]
Raito_Bezarius has quit [Ping timeout: 256 seconds]
Muimi has quit [Quit: Going offline, see ya! (www.adiirc.com)]
s55 has joined #ffmpeg
MrZeus has joined #ffmpeg
alexherbo2 has quit [Ping timeout: 250 seconds]
NaviTheFairy has quit [Ping timeout: 252 seconds]
thilo has quit [Ping timeout: 260 seconds]
Tinos has quit [Quit: Ping timeout (120 seconds)]
thilo has joined #ffmpeg
<kepstin>
FlorianBad: i talked about this a bit before, crf mode is basically the second pass of a 2-pass encode :) so of course they're not compatible, it would be like saying "do a first pass to collect stats, oh, but ignore all the info you collected from that first pass and use this value i provided instead" :)
<FlorianBad>
kepstin, yeah, I just thought you meant it was not "recommended" or "silly", not that would be completely incompatible :D
Raito_Bezarius has joined #ffmpeg
<FlorianBad>
if I use: `-lavfi '[0:v]split=2[v1][v2]' -map '[v1]' -c:v .... -f out1.mp4 -map '[v2]' -c:v .... -f out2.mp4` instead of just putting the different outputs one after the other, is it threaded differently? (like more parallel or something?)
faxmodem has joined #ffmpeg
MrZeus has quit [Ping timeout: 260 seconds]
<kepstin>
FlorianBad: that's just an error, the "-f" option takes the name of the output format (muxer) to use
Tinos has joined #ffmpeg
<kepstin>
FlorianBad: if you want to encode a stream once but include it in multiple output files, the "tee" pseudo-muxer lets you do that.
<kepstin>
no threading advantage, just reduces duplicate work
lolok has joined #ffmpeg
<kepstin>
unless you want to try out the unreleased ffmpeg cli tool with threading improvements, best way to make things more parallel is to encode each audio or video stream with a separate ffmpeg command, and then remux the results afterwards to make the desired combinations.
Jaex has joined #ffmpeg
realies has quit [Quit: ~]
<FlorianBad>
kepstin, sorry, I meant -f mp4 each time
<aaabbb>
>crf is proportional to filesize on a decibel scale - adding ~6 to crf halves filesize
<aaabbb>
but only for the same input
<kepstin>
aaabbb: well, yes, since different inputs produce different filesize at the same crf...
<kepstin>
FlorianBad: then… what did you change? that looks exactly the same as the previous commands you were using.
<aaabbb>
kepstin: yeah i meant that for FlorianBad since i recommended to him before to use abr if he wants to target a specific bandwidth
<FlorianBad>
aaabbb, yeah, in fact it's pretty damn accurate. And I like dB unit because I made music my whole life so I'm very used to seeing dB units
<FlorianBad>
I don't actually need to aim at a specific bandwidth because nothing in my server will remember what bandwidth that was, it will just pick based on filesize of chunks of dash
<FlorianBad>
(and length, which really means final bw)
<FlorianBad>
s/length/duration/
<FlorianBad>
All I want is many increments it can pick from
<FlorianBad>
so something like -crf 18, -crf 20, crf 22, etc. e.g. for each resolution would be great
lemourin has quit [Read error: Connection reset by peer]
<FlorianBad>
kepstin, so the "tee" pseudo-muxer is needed because...? Because an input stream can only be used once? so it needs to be duplicated?
<aaabbb>
FlorianBad: tee just helps you optimize your workflow a bit
<aaabbb>
FlorianBad: the problem with crf is that you may have a video that is extremely large at the same crf that another video is, so you'd have to "slide" your possible crf scale for each video
<FlorianBad>
So otherwise it would be perfectly possible to reuse that same input stream with another output?
<kepstin>
FlorianBad: the "tee" mixer allows you to use _the output of an encoder_ in multiple output files
<aaabbb>
eg if your video goes from crf 18 to crf 24, well for some videos 18 may be way too big, or crf 24 might not be high enough
lemourin has joined #ffmpeg
<kepstin>
since encoders are separately per output file
<aaabbb>
FlorianBad: i mentioned tee in the past, it would help you deduplicate certain effort such as decoding, filters (before tee) etc
<FlorianBad>
kepstin, well then it's not what I need, and I suspect I need nothing maybe :)
Tinos has quit [Quit: Client closed]
<FlorianBad>
wait, let me just pastebin my perl script so you can see what ffmpeg command it will create
<kepstin>
decoding isn't ever duplicated, and using the global filterchain (with "-filter_complex" or its alias "-lavfi" avoids duplicating filters)
<FlorianBad>
(program not finished of course but that's what I wrote so far)
whatsupdoc has joined #ffmpeg
<kepstin>
FlorianBad: main thing i'd suggest is building the ffmpeg command as an array rather than a string so you don't have to worry about quoting/escaping issues :)
<kepstin>
been a while since i've used perl, but i'm pretty sure there's a form of the system command which accepts an array directly
<FlorianBad>
So lines 304-306 I add the only video and audio input (one specific resolution), then lines 312-342 I add each output which are increments of qualities for the same resolution
<FlorianBad>
kepstin, that's fine, I'm used to it ;)
<kepstin>
ah, you're used to your program doing unexpected things including running arbitrary different executables because someone felt like putting a ; in an input filename unexpectedly? Always better to be safe than sorry ;)
<FlorianBad>
It's a moderately quick program just for me, it's not like I'm going to release that as super-clean for everyone to use, no one would need this
Muimi has joined #ffmpeg
<FlorianBad>
not a problem because it's quoted, but that someone will always be me and I would never put anything else than [\w.-] in filenames
<kepstin>
yeah, it's just always good to make sure you reinforce good code safety habits, especially ones that don't make the code significantly more difficult to write.
waleee has quit [Ping timeout: 252 seconds]
<FlorianBad>
BTW, is there a way to have -i video-and-audio-file.mp4 act as if it was only importing an audio stream?
<kepstin>
FlorianBad: use -map options to only select the audio stream from it
<FlorianBad>
so that if I have -i video-only.mp4 -i video-and-audio.mp4 I end up having only video stream 0 and audio stream 0
<FlorianBad>
but it doesn't decode the whole video thing before that?
<kepstin>
no, it'll only decode streams which are actually used.
<FlorianBad>
ah great, so -map acts after demux but before any decoding?
<kepstin>
and even then, only if you have options set such that it actually needs to decode them (e.g. -c copy prevents decoding)
<kepstin>
it's more complicated than that
<kepstin>
-map acts before encoding
<FlorianBad>
s/complicated/smarter/ ? :)
<FlorianBad>
/clever/
<kepstin>
the "-map" option wires up filter graph outputs and video input streams to encoders and/or muxers.
<furq>
-vn would do the same thing
<FlorianBad>
ok I see, and then whatever is not "wired" anywhere won't be handled
<kepstin>
specifically, -vn as an input option
<kepstin>
(since -vn is actually two separate options - it has different behaviour if you use it on an input file vs on an output file)
<furq>
well there's something new
<furq>
there's also -discard as an input option which i don't understand the need for
<furq>
oh wait you can discard specific frames with that
<kepstin>
i think the discard option is more about its ability to filter to only decode keyframes than its ability to remove entire streams
minimal has quit [Quit: Leaving]
<kepstin>
but yeah, it can also remove specific entire streams :)
<kepstin>
looks like -discard applies between the demuxer and the decoder, so it can be used to prevent the decoder from seeing non-keyframes, or to allow doing a keyframe only stream copy? kinda weird.
<furq>
i guess it's faster than -skip_frame nokey (when it works)
<furq>
i wonder what formats that actually works with
<kepstin>
as long as the container has IDR frames correctly marked, i'd honestly suspect that at least the keyframe-only mode might work with a decent number of codecs.
Fischmiep has joined #ffmpeg
Tinos has joined #ffmpeg
Tinos has quit [Client Quit]
Kei_N_ has joined #ffmpeg
realies has joined #ffmpeg
Kei_N has quit [Ping timeout: 268 seconds]
NaviTheFairy has joined #ffmpeg
realies has quit [Read error: Connection reset by peer]
realies has joined #ffmpeg
slydacyfa has quit [Read error: Connection reset by peer]
theracermaster has joined #ffmpeg
<FlorianBad>
Should I be worried/hesitant about aac_at on Linux as opposed to libfdk_aac, just because it's Apple?
<furq>
you can't use it on linux anyway
<FlorianBad>
ah? I see i in my config.log but I did't actually compile it?
<FlorianBad>
So libfdk_aac would be best then? But is VBR limited to 5 which doesn't seem that high of an avg bitrate (almost all my videos will be music videos so I'm looking for absolute best AAC settings, especially if user can take thet bandwidth)
<FlorianBad>
Hmm, I'm getting this but I wonder what "combinations" it's referring to: [libfdk_aac @ 0x4d0ae00] Note, the VBR setting is unsupported and only works with some parameter combinations
LionEagle has quit [Ping timeout: 252 seconds]
LionEagle has joined #ffmpeg
q66 has quit [Ping timeout: 255 seconds]
<FlorianBad>
For libfdk_aac there's no "high" or similar high quality/slow profile? (or any other option that means slow) ? The only profile I saw was "aac_he" which of course I don't need
<aaabbb>
FlorianBad: like a -compression_level thing?
<FlorianBad>
aaabbb, no, I use -vbr or -b:a for that, just like a "slow" thing where it would take more time to do it better. That, or any other setting I could use that might impact quality?
<FlorianBad>
aaabbb, ah! wonderful, didn't even realize there was that help! thanks a lot
<aaabbb>
the encoder help option?
<aaabbb>
it's very useful, it tells you a lot about an encoder that sometimes isn't even in the documentation, like ffmpeg -h encoder=mpeg1video
<aaabbb>
(you don't want to use mpeg1 btw it was just an example)
<FlorianBad>
yeah, wish I realized that sooner lol
<FlorianBad>
I wonder what -vbr 0 means...
<aaabbb>
is that even valid?
<FlorianBad>
ah well, he described it in my link above
<aaabbb>
FlorianBad: on modern systems you can use xHE-AAC which is much more efficient, or at least opus
<FlorianBad>
aaabbb, don't forget I encode for web browsers
<FlorianBad>
Hmm, even with -thread_queue_size 1024 I still get: [in#0/image2 @ 0x3e44100] Thread message queue blocking; consider raising the thread_queue_size option (current value: 1024)
<aaabbb>
ah, then only opus would be widely supported
<aaabbb>
bring it up then
<FlorianBad>
can it come from my -r option? I put -r 24000/1001 before each -c:v of output
<aaabbb>
i doubt it. i only got that error once and i fixed it by setting it to 999999 or something (if it's the error i'm thinking of)
<FlorianBad>
ok, well I raised it to 1024 from 8 so I guess I should push it more. With 64GB of ram how high would you set it?
Tinos has joined #ffmpeg
<aaabbb>
just increase it until it goes away (put it before each -i causing a problem)
<FlorianBad>
I put 128 for audio.wav input, but doesn't cause problem so I'll leave it there
<FlorianBad>
So that's really 79.59% for OPUS vs 98.43% for AAC since we're talking about aac in mp4
<FlorianBad>
but as soon as all apple devices support aac in mp4 then I'll switch
Faely has joined #ffmpeg
Gaely has quit [Ping timeout: 252 seconds]
Tinos has joined #ffmpeg
Ogobaga has quit [Quit: Konversation terminated!]
Ogobaga has joined #ffmpeg
five618480 has quit [Remote host closed the connection]
Ogobaga has quit [Client Quit]
five618480 has joined #ffmpeg
Ogobaga has joined #ffmpeg
Ogobaga has quit [Client Quit]
Ogobaga has joined #ffmpeg
YuGiOhJCJ has joined #ffmpeg
Ogobaga has quit [Quit: Konversation terminated!]
Ogobaga has joined #ffmpeg
q66 has joined #ffmpeg
Ogobaga has quit [Quit: Konversation terminated!]
Ogobaga has joined #ffmpeg
Ogobaga has quit [Quit: Konversation terminated!]
Ogobaga has joined #ffmpeg
Tinos has quit [Quit: Ping timeout (120 seconds)]
wyatt8750 has quit [Remote host closed the connection]
wyatt8740 has joined #ffmpeg
chainik1 has quit [Quit: (╯°□°）╯︵ ┻━┻]
chainik1 has joined #ffmpeg
Tano has joined #ffmpeg
jarthur_ has quit [Quit: jarthur_]
<FlorianBad>
I was reading about "[vost#0:0/libx264 @ 0x4d109c0] More than 1000 frames duplicated" and people say I could use a variable frame rate, but I don't like that at all since it would seriously complicate my custom player (and possibly introduce browser compatibility issues). Is there a way to just turn them all into P-frames so that keyint is ignored exceptionally? (and the warning won't show, too)
Vonter has quit [Ping timeout: 276 seconds]
Vonter has joined #ffmpeg
Tano has quit [Quit: WeeChat 4.1.2]
rv1sr has joined #ffmpeg
<aaabbb>
FlorianBad: you need a keyframe no matter what
<aaabbb>
but you can do "-x264opts keyint=infinite:no-scenecut" to make only one single idr and the rest p/b frames
<aaabbb>
but then the entire video has just one keyframe
<aaabbb>
FlorianBad: how many duplicate frames are you getting? if it's a lot then you might seriously consider vfr
Tano has joined #ffmpeg
AbleBacon has quit [Read error: Connection reset by peer]
<FlorianBad>
aaabbb, well I definitely don't want that because don't forget I'm going to run something like ffmpeg -i that-res-and-bitrate.mp4 -c copy -f dash output.mpd
<FlorianBad>
and every resolution+bitrate will need to be able to transition from one to the other at any point
<aaabbb>
then you can't turn everything into all p frames
<FlorianBad>
right now I use -x264-params "scenecut=0:keyint=$keyint" where $keyint is typically fps/5
<FlorianBad>
yeah
<aaabbb>
that's a very very low keyint
<FlorianBad>
I don't know how many, it says more than 1000 and it says it twice for each video encoded (or maybe it's per output in which case that's only once for each)
<FlorianBad>
yeah but I don't want people to scroll somewhere and see some gray for a full second...
<aaabbb>
lots of frames duplicated has nothing to do with the keyint
<aaabbb>
it has to do with the source having a lower framerate than the video being encoded
<FlorianBad>
hmmm
<aaabbb>
also fps/5 is really low for a keyint, i'd suggest a keyint of fps (or maybe even one keyframe in the entire segment)
<FlorianBad>
now I'm interested because my final video has another issue: audio/video sync is off. Video gets later and later as I play, yet ffprobe shows that both input and output have same fps and same sample rate
<FlorianBad>
ok
<FlorianBad>
But one thing where I thing I might have messed up is that I do mp4 > PNG .. than I resize these PNGs, then > PNGs > mp4 + audio from original mp4
<FlorianBad>
and I wonder if I need different options in the last ffmpeg that encodes the final mp4
<aaabbb>
i'm not sure entirely what you're trying to do, but mp4 > pngs > resize png > mp4 has got to be the wrong way to do it
<FlorianBad>
no, I'm ok with that, it's a long story. But in the end I finish with PNG + audio > mp4 and I provide the original fps as -r $fps
<FlorianBad>
ah but wait, I need to set -r TWICE? once in the input options, and once in the output? (I only put it in the output options)
<FlorianBad>
Ah! I think I absolutely need the -framerate option just after -f image2 because otherwise it might just default to some random fps?
<FlorianBad>
(and of course it should be the same as -r in output in this case)
<aaabbb>
i'm not sure, i haven't done that before
<FlorianBad>
yeah I'm trying now, but I suspect that was the problem, we'll see what happens. The idea I think is that a PNG input with image2 is already technically a video feed, which means it should already have a frame rate, and the -r only influences the encoder after that
<FlorianBad>
looks like that might have even solved the "More than 1000 frames duplicated" warning
<FlorianBad>
But it's still encoding so I'll see in a few minutes about the audio/video sync
Muimi has quit [Quit: Going offline, see ya! (www.adiirc.com)]
<FlorianBad>
Yes, it solved both problems, indeed
<FlorianBad>
So it means that image2 must do something somewhat random with the fps (maybe dynamic based on input) if -framerate is not specified
<FlorianBad>
(at least up to that point, then I need to take these mp4 outputs and put into -f dash, but that's gonna be for another day)
five618480 has quit [Remote host closed the connection]
five618480 has joined #ffmpeg
stevenliu has joined #ffmpeg
navi has joined #ffmpeg
foul_owl has quit [Ping timeout: 246 seconds]
foul_owl has joined #ffmpeg
blaze has quit [Quit: WeeChat 3.5]
blaze has joined #ffmpeg
Kei_N has joined #ffmpeg
Kei_N_ has quit [Ping timeout: 268 seconds]
Blacker47 has joined #ffmpeg
fling has quit [Remote host closed the connection]
fling has joined #ffmpeg
fling has quit [Remote host closed the connection]
<rodeo>
wait, your input is a bunch of PNG images, not in a container?
<aaabbb>
apparently
<rodeo>
that's some scrollback, after like going 10-11 hours back I'm bored, so I'll assume the input is indeed individual PNG files
Suchiman has quit [Quit: Connection closed for inactivity]
<rodeo>
in which case common sense applies, you need to specify an input framerate, ffmpeg is not going to guess it out of thin air
<rodeo>
like, duh squared
<FlorianBad>
rodeo, well, what I didn't realize is that by the time that stream goes to the encoder it's already technically a video, as opposed to just a series of frames, which means that the -r option of the encoder is not enough
<FlorianBad>
I didn't realize why another fps option was needed until I understand that
MootPoot has quit [Quit: Connection closed for inactivity]
luc4 has joined #ffmpeg
fling has joined #ffmpeg
Ingvix has quit [Ping timeout: 256 seconds]
Ingvix has joined #ffmpeg
foul_owl has quit [Ping timeout: 256 seconds]
<dv_>
is it valid for an encoder that uses CBR and a HRD model to allow for on-the-fly bitrate adjustments?
<dv_>
that is, initially, the bitrate is for example 1024 kbit/s, and after 10 seconds, the user wants 2048 kbit/s instead
<dv_>
is this possible without effectively ending the current bitstream and starting another?
<dv_>
(this is about h264)
<dv_>
this is not the same as VBR, since the bitrate adjustment here is purely external, that is, until the user manually requests a different bitrate, the encoder does what it can to ensure that the bitrate stays constant
foul_owl has joined #ffmpeg
<aaabbb>
i don't see why not (but i could be wrong)
five6184804 has joined #ffmpeg
five618480 has quit [Ping timeout: 252 seconds]
five6184804 is now known as five618480
lavaball has joined #ffmpeg
Gaboradon has joined #ffmpeg
lexano has joined #ffmpeg
LionEagle has quit [Quit: Leaving]
LionEagle has joined #ffmpeg
LuKaRo has quit [Ping timeout: 240 seconds]
LuKaRo has joined #ffmpeg
MrZeus has joined #ffmpeg
<BtbN>
There is no CBR anyway
<BtbN>
it's not like the mode of the bitstream changes or anything. It's just instructions to the encoder to not exceed a certain bitrate over a given timeperiod.
<BtbN>
And even in CBR mode, encoders will happily produce a lower bitrate if they can
<JEEB>
if you break your initial HRD model configuration you will get an achtung for that and clients may barf, but that's it
<JEEB>
(achtung from the encoder like x264 does when it notices you broke your buffers)
<JEEB>
hopefully when the encoder switches it will then update the HRD NALUs' contents so then the newly entering clients will know
neilt has joined #ffmpeg
epony has quit [Remote host closed the connection]
realies has quit [Read error: Connection reset by peer]
epony has joined #ffmpeg
<aaabbb>
cbr is just abr with really tight constraints
realies has joined #ffmpeg
YuGiOhJCJ has quit [Quit: YuGiOhJCJ]
epony has quit [Excess Flood]
five618480 has quit [Remote host closed the connection]
five618480 has joined #ffmpeg
epony has joined #ffmpeg
epony has quit [Client Quit]
alexherbo2 has joined #ffmpeg
epony has joined #ffmpeg
omegatron has joined #ffmpeg
alexherbo2 has quit [Remote host closed the connection]
alexherbo2 has joined #ffmpeg
alexherbo2 has quit [Remote host closed the connection]
alexherbo2 has joined #ffmpeg
hightower2 has joined #ffmpeg
waeking has quit [Quit: Ping timeout (120 seconds)]
waeking has joined #ffmpeg
vampirefrog has quit [Ping timeout: 260 seconds]
waleee has joined #ffmpeg
<BtbN>
well, in one direction
<BtbN>
If you tell x264 to encode a solid color in cbr, it will not use most of the bitrate given
five6184808 has joined #ffmpeg
five618480 has quit [Ping timeout: 260 seconds]
five6184808 is now known as five618480
realies has quit [Read error: Connection reset by peer]
realies has joined #ffmpeg
realies has quit [Quit: Ping timeout (120 seconds)]
realies has joined #ffmpeg
five6184801 has joined #ffmpeg
five618480 has quit [Ping timeout: 240 seconds]
five6184801 is now known as five618480
natto has joined #ffmpeg
WereSquirrel has joined #ffmpeg
waleee has quit [Ping timeout: 252 seconds]
NaviTheFairy has quit [Ping timeout: 268 seconds]
<rodeo>
you can tell it to pad with --filler though IIRC?
<JEEB>
yes, it has a nal-hrd mode that pads the buffer so it always hits rate
<rodeo>
although that doesn't necessarily the question about reconfiguring for a different bitrate, I guess
lullerhaus has quit []
Suchiman has joined #ffmpeg
cc0_ has joined #ffmpeg
cc0_ is now known as cc0
minimal has joined #ffmpeg
luc4 has quit [Ping timeout: 268 seconds]
lullerhaus has joined #ffmpeg
navi has quit [Ping timeout: 260 seconds]
five6184800 has joined #ffmpeg
five618480 has quit [Ping timeout: 276 seconds]
five6184800 is now known as five618480
navi has joined #ffmpeg
alexherbo2 has quit [Remote host closed the connection]
alexherbo2 has joined #ffmpeg
billchenchina has joined #ffmpeg
fling has quit [Remote host closed the connection]
fling has joined #ffmpeg
Vonter has quit [Ping timeout: 264 seconds]
Vonter has joined #ffmpeg
waleee has joined #ffmpeg
billchenchina has quit [Quit: Leaving]
fling has quit [Ping timeout: 255 seconds]
fling has joined #ffmpeg
alexherbo2 has quit [Remote host closed the connection]
rvalue has quit [Ping timeout: 264 seconds]
alexherbo2 has joined #ffmpeg
neilt has quit [Quit: Leaving]
rvalue has joined #ffmpeg
AntimaD has joined #ffmpeg
AntimaD has quit [Ping timeout: 250 seconds]
AbleBacon has joined #ffmpeg
alexherbo2 has quit [Remote host closed the connection]
alexherbo2 has joined #ffmpeg
WereSquirrel has quit [Ping timeout: 252 seconds]
alexherbo2 has quit [Ping timeout: 250 seconds]
JanC_ has joined #ffmpeg
JanC has quit [Killed (lithium.libera.chat (Nickname regained by services))]
lavaball has quit [Remote host closed the connection]
nitrix has joined #ffmpeg
<FlorianBad>
1080 is not a multiple of 16, does it mean that x264 will actually waste 4 pixels of data on top and 4 at the bottom?
<FlorianBad>
So the data will be encoded and then wasted?
<JEEB>
yea, the coded height is 1088
<JEEB>
but that's normal and it isn't really wasted
<JEEB>
since the encoder can optimize those bits since they're not going to be visible anyways
<CounterPillow>
encoding a small band that contains nothing and does not change ever is not very intensive
<JEEB>
I think it might have been a bigger thing with older encoders pre-x264, but I'm not even sure about that
<FlorianBad>
oh I see, so it's almost as if I was inputing a video with a perfect-black band on top and bottom (minus the blur problem that would occur from doing that) ?
alexherbo2 has joined #ffmpeg
<CounterPillow>
I don't know for sure but I'd wager it just writes whatever is fast for it, knowing the decoder will discard it, so it's probably not even perfect black
<FlorianBad>
yeah, just no data or something
<JEEB>
and with AVC/H.264 it's 16x16 macroblocks, with HEVC/H.265 it's up to 64x64 CTUs, and AV1 goes to 128x128 I think. and VVC/H.266 also goes into larger blocks
<FlorianBad>
So the only downside is that the who motion detection for keyframes vs P-frames may not be as great in these top/bottom areas, and that's it?
<FlorianBad>
s/who//
<FlorianBad>
actually s/who/whole/
<CounterPillow>
wouldn't that be the case for any area close to the border regardless of whether it's perfectly the coded resolution?
<FlorianBad>
ok, maybe. I see. So pretty much zero downside then?
Tano has quit [Ping timeout: 252 seconds]
Tano has joined #ffmpeg
omegatron has quit [Quit: Power is a curious thing. It can be contained, hidden, locked away, and yet it always breaks free.]
<JEEB>
at least with any sane encoder like x264, yea
<FlorianBad>
ok
<furq>
it will just be on the bottom
<FlorianBad>
So then the only downsize of having a TRULY awkward resolution is when the aspect ratio can no longer be totally respected, right?
<FlorianBad>
like e.g. 16/9 is no longer even...
<furq>
that or you end up with an odd number
<furq>
especially if you're scaling
alexherbo2 has quit [Remote host closed the connection]
<FlorianBad>
For the context, I'm writing something that will choose the resolutions available for my custom Javascript front-end, but I want as many as possible so I will give the closest <= thing from the size of the canvas of the user
<FlorianBad>
So I have an original width:height of the video, then I want to pick A LOT of them so I'm never quite far from the actual pixels on their screen
<furq>
if i was using that i would prefer you give me the next one up than the next one down
<FlorianBad>
yes, that's what I said
<FlorianBad>
ah, well, depends how you interpret my "<=" :)
<FlorianBad>
I was putting that res on the right side and client on the left ;)
rv1sr has quit []
Muimi has joined #ffmpeg
<FlorianBad>
e.g. if original was 2560x1440 I will have maybe 10 different resolutions (let's say, not sure yet) and if the browser has a canvas of 1364x767 I will send a 1600x900 version maybe
<FlorianBad>
So now I'm coding the part of my script that will decide all these (10 e.g.) resolutions based on the input 2560x1440 e.g. (which maybe any ratio, like 16:9 16:10, 4:3, etc
<FlorianBad>
So in that case, the main rule is that: 1. both x and y are even, 2. Aspect ratio is perfectly respected. What else? Not 16 rule at all?
<FlorianBad>
what about width must be mod 16? (not height)
<furq>
the mod16 thing is handled internally
<furq>
you don't need to consider it at all
<FlorianBad>
ok, not even for width?
<furq>
no
<FlorianBad>
ok
<furq>
you can also encode anamorphic if you want more flexibility with aspect ratio
<FlorianBad>
So that would be the only 2 rules then? The third one would be simply to space them approximately equality apart
<furq>
browsers will respect that which is nice
<FlorianBad>
well, I will draw myself in canvas so I can really do whatever I want
<FlorianBad>
But I'd rather keep things closest to what they were originally
lolok has quit [Remote host closed the connection]
junaid_ has joined #ffmpeg
cosimone has joined #ffmpeg
alexherbo2 has joined #ffmpeg
epony has quit [Remote host closed the connection]
APic has quit [Ping timeout: 268 seconds]
alexherbo2 has quit [Remote host closed the connection]
Icedream has quit [Ping timeout: 252 seconds]
Icedream has joined #ffmpeg
NaviTheFairy has joined #ffmpeg
Blacker47 has quit [Quit: Life is short. Get a V.90 modem fast!]
nate has joined #ffmpeg
lavaball has joined #ffmpeg
cosimone has quit [Remote host closed the connection]
junaid_ has quit [Remote host closed the connection]
cosimone has joined #ffmpeg
Hackerpcs has quit [Quit: Hackerpcs]
MootPoot has joined #ffmpeg
Hackerpcs has joined #ffmpeg
Hackerpcs has quit [Max SendQ exceeded]
Hackerpcs has joined #ffmpeg
<bcn>
Is there a format for audio with subtities but no video?
<JEEB>
you can do that with plenty of containers
<JEEB>
I don't think most require you to mux video to be able to mux subs :D
five618480 has quit [Remote host closed the connection]
five618480 has joined #ffmpeg
<bcn>
I (think) I just made an mkv from a flac and an srt. but how do I play it.... vlc doesn't show any subs
<bcn>
ideally I'd like to see the subs in one big list on the side so I can click on one of them and skip to that time in the audio
<BtbN>
that's up to the player, not the container
<JEEB>
yea
<JEEB>
mpv for example will attempt to put the subs into the terminal :D
<JEEB>
if you don't have video
<bcn>
that would be swell
<JEEB>
(or at least I recall it working like that)
turlando has quit [Quit: No Ping reply in 180 seconds.]