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
YuGiOhJCJ has joined #ffmpeg
iive has quit [Quit: They came for me...]
lavaball has quit [Remote host closed the connection]
theracermaster has joined #ffmpeg
Tano has quit [Ping timeout: 276 seconds]
Tano has joined #ffmpeg
five6184803391 has joined #ffmpeg
linext has joined #ffmpeg
linext has quit [Client Quit]
ewomer has quit [Read error: Connection reset by peer]
ewomer has joined #ffmpeg
ewomer has quit [Ping timeout: 265 seconds]
minimal has quit [Quit: Leaving]
emmanuelux has quit [Quit: au revoir]
System_Error has quit [Ping timeout: 260 seconds]
System_Error has joined #ffmpeg
five6184803391 has quit [Remote host closed the connection]
five6184803391 has joined #ffmpeg
vvulkanv has quit [Ping timeout: 244 seconds]
mven97 has quit [Quit: Goodbye.]
mven97 has joined #ffmpeg
oneforall2 has quit [Remote host closed the connection]
FH_thecat has quit [Quit: Leaving]
DauntlessOne has quit [Remote host closed the connection]
lusciouslover has quit [Read error: Connection reset by peer]
lusciouslover has joined #ffmpeg
FH_thecat has joined #ffmpeg
acovrig6012 has quit [Quit: The Lounge - https://thelounge.chat]
vvulkanv has joined #ffmpeg
acovrig6012 has joined #ffmpeg
acovrig6012 has quit [Quit: The Lounge - https://thelounge.chat]
vvulkanv has quit [Read error: Connection reset by peer]
Blacker47 has joined #ffmpeg
acovrig6012 has joined #ffmpeg
vvulkanv has joined #ffmpeg
iNKa is now known as Brocker
Suchiman has quit [Quit: Connection closed for inactivity]
arbitercoin has joined #ffmpeg
rv1sr has joined #ffmpeg
j45 has quit [Ping timeout: 260 seconds]
j45 has joined #ffmpeg
mark4o has joined #ffmpeg
markh has quit [Ping timeout: 264 seconds]
mark4o is now known as markh
<snoriman> When loading a MP4/h264, can I get the pixel format after opening the AVFormatContext? Or is the pixel format extracted by the codec context? If I'm correct the pixel format is stored in the container (right?)
HerbY_NL has joined #ffmpeg
x_x has joined #ffmpeg
HerbY_NL has quit [Ping timeout: 252 seconds]
HerbY_NL has joined #ffmpeg
down200 has quit [Ping timeout: 276 seconds]
lavaball has joined #ffmpeg
down200 has joined #ffmpeg
five6184803391 has quit [Remote host closed the connection]
five6184803391 has joined #ffmpeg
Suchiman has joined #ffmpeg
Dagger has quit [Ping timeout: 265 seconds]
Dagger has joined #ffmpeg
lexano has quit [Ping timeout: 252 seconds]
vvulkanv has quit [Quit: vvulkanv]
psykose has joined #ffmpeg
psykose has quit [Remote host closed the connection]
vvulkanv has joined #ffmpeg
vvulkanv has quit [Client Quit]
lexano has joined #ffmpeg
militantorc has joined #ffmpeg
minimal has joined #ffmpeg
arbitercoin has quit [Read error: Connection reset by peer]
txtsd has quit [Ping timeout: 276 seconds]
txtsd has joined #ffmpeg
vvulkanv has joined #ffmpeg
vvulkanv has quit [Client Quit]
HerbY_NL has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
ewomer has joined #ffmpeg
sentriz has quit [Ping timeout: 265 seconds]
Magissia has joined #ffmpeg
sentriz has joined #ffmpeg
EmleyMoor has quit [Ping timeout: 252 seconds]
<BtbN> The pixel format is decided by the encoder. Encoded content does not have an inherent pixel format.
<BtbN> Some encoders output nv12 style formats, other yuv420p, and so on
<BtbN> *by the decoder
<BtbN> The encoder obviously also prefers certain pixel formats, but the decoder decides what it decodes to
EmleyMoor has joined #ffmpeg
EmleyMoor has quit [Ping timeout: 265 seconds]
L29Ah has quit [Read error: Connection reset by peer]
<snoriman> BtbN: thanks, that's actually why I'm trying to get the pixel format after opening the input; I want to make sure that I'm opening a file that has been encoded using the correct pixel format. However after opening the input and checking the format of the video stream, the `format` member was not set to the value it uses
<BtbN> again, files aren't encoded in a specific pixel format
<BtbN> the decoder decides what pixel format it gets decoded to
<snoriman> ohhhh sorry
<BtbN> Of course the pixel format needs to match the properties of the content, like bit depth and subsampling
<BtbN> But other than that, the decoder can pick whatever it prefers
EmleyMoor has joined #ffmpeg
<snoriman> I've been using NV12 forever as from my experience this is what basically every encodeer, or at least decoder prefers, I automatically assumed that the "input format" was also the "output format" of the decoder.
EmleyMoor has quit [Ping timeout: 244 seconds]
militantorc has quit [Quit: Free ZNC ~ Powered by LunarBNC: https://LunarBNC.net]
RedShift has joined #ffmpeg
noobaroo has joined #ffmpeg
militantorc has joined #ffmpeg
<noobaroo> Nowadays when I encode stuff that I really want to store long term and delete original, I always use -r $fps as an input option and also -an . I found that it will adhere to the audio timestamps otherwise or use same keyframes unless I do this
<noobaroo> i think there is a way to stream copy the audio and encode the video with freshly regenerated timestamps using the -fps_mode drop or something like that, but i haven't gotten this to work
<noobaroo> whats the official solution, here? i know what i do is just a makeshift workaround
halloy1490 has joined #ffmpeg
halloy1490 has quit [Ping timeout: 265 seconds]
rv1sr has quit []
cmc has quit [Ping timeout: 260 seconds]
rv1sr has joined #ffmpeg
cmc has joined #ffmpeg
bip0pular has joined #ffmpeg
bip0pular has quit [Client Quit]
bip0pular has joined #ffmpeg
ewomer has quit [Remote host closed the connection]
ewomer has joined #ffmpeg
YuGiOhJCJ has quit [Quit: YuGiOhJCJ]
vvulkanv has joined #ffmpeg
bitblit has quit [Quit: WeeChat 4.1.1]
vvulkanv has quit [Client Quit]
dreamon has joined #ffmpeg
dv_ has joined #ffmpeg
<dv_> hi. I noticed that with test white noise data, and constant quantizer (quant param 50), I get ~72 kB per encoded frame. but when I instead use a low bitrate, I can go below these 72 kB. this means to me that x264 is doing rate control not simply by adjusting the quant param but also by doing some image preprocessing, perhaps a lowpass filter to get rid of high frequency content. is this correctß
bitblit has joined #ffmpeg
treefrob has quit [Read error: Connection reset by peer]
treefrob has joined #ffmpeg
<BtbN> noobaroo: no idea what you are reffering to
<BtbN> if you want to only transcode video, use -c:a/-c:v copy accordingly
vvulkanv has joined #ffmpeg
vvulkanv has quit [Remote host closed the connection]
sm1999 has joined #ffmpeg
JanC has quit [Ping timeout: 246 seconds]
JanC has joined #ffmpeg
vvulkanv has joined #ffmpeg
<noobaroo> BtbN If one stream is being stream copied then timestamps don't seem to regenerate
vvulkanv has quit [Quit: vvulkanv]
JanC has joined #ffmpeg
JanC is now known as Guest9494
Guest9494 has quit [Killed (molybdenum.libera.chat (Nickname regained by services))]
Unit640 has joined #ffmpeg
ppw has quit [Ping timeout: 265 seconds]
<kepstin> dv_: x264's rate control is pretty complex and makes decisions based on psychovisual analysis. I think it also will vary quantizer per block within frames. I think the only real "preprocessing" used is the deblocking filter.
travisghansen has quit [Quit: The Lounge - https://thelounge.github.io]
travisghansen has joined #ffmpeg
<dv_> kepstin: but if I use constant quantization, and set the maximum quantization param, shouldn't this then be the minimum possible frame size, if all that x264 can do is vary the quant param?
<kepstin> note that the actual max qp that x264 can use is .. 81 i think?
<kepstin> (x264 does have optional noise reduction pre-processing, but it's off by default)
Dagger has quit [Ping timeout: 265 seconds]
<dv_> yeah, but beyond 51 is only relevant for 10-bit
<dv_> and my test data uses 8 bit per channel
JanC_ has joined #ffmpeg
JanC has quit [Killed (lead.libera.chat (Nickname regained by services))]
JanC_ is now known as JanC
Dagger has joined #ffmpeg
<kepstin> anyways, the full rate control mechanism in x264 is more complicated than constant-qp, and can choose to do things which use less bits, such as not encoding some of the data that changed in a frame at all.
<dv_> but if I forcibly set a constant QP, then there is no rate control, since a constant QP and rate control are mutually exclusive
<kepstin> exactly.
<dv_> hrm
<kepstin> using crf mode instead of constant qp mode _does_ run the rate control.
<dv_> not encoding unchanged data probably isn't happening, since this is a white noise test signal
<kepstin> if needed to reach the target bitrate, the encoder is free to throw out data
<dv_> but maybe it is doing some sort of per-macroblock preprocessing
<dv_> even in constant quantizer mode
<dv_> errr, no, nevermind
<dv_> I meant when not in contant quantizer mode
<dv_> this is the only way I can see how in rate control mode the frames can get lower than in constant quantizer mode with qp=51
<kepstin> i can't remember exactly, but i think the psychovisual optimizations in the rate control will try to prioritize encoding information that it thinks will make the biggest difference to the visual quality of the final image. on white noise, that's effectively random tho.
<dv_> yeah precisely
<kepstin> i suspect if you frame-step through the encoded white noise at really low bitrate you'll see that some parts of the frame don't update on every frame.
<dv_> you mean it does some sort of analysis that detects that the only change is high frequency change and thus effectively ignores it at very low QP?
<dv_> err, bitrate
<dv_> darn
<kepstin> i think it actually prefers to keep changes with high frequency details since those are what people are more likely to notice
<dv_> or perhaps it somehow detects that post-encoding and post-quantization, certain macroblocks remain exactly the same, and based on _that_, it decides to not actually store them
<kepstin> so in real video at very low bitrate you'll sometimes see a sharp edge moving clearly while a flatter area isn't updating to keep up.
System_Error has quit [Ping timeout: 260 seconds]
<kepstin> specifically, i'm pretty sure it can decide to skip some blocks even if encoding them at min qp would result in them contributing to the video.
vulpine is now known as ghoulpine
HerbY_NL has joined #ffmpeg
System_Error has joined #ffmpeg
HerbY_NL has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
rv1sr has quit []
CounterPillow is now known as CountPumpkin
vvulkanv_ has joined #ffmpeg
blb has quit [Ping timeout: 260 seconds]
blb has joined #ffmpeg
vvulkanv_ has quit [Ping timeout: 265 seconds]
troyt has quit [Quit: AAAGH! IT BURNS!]
lavaball has quit [Remote host closed the connection]
rv1sr has joined #ffmpeg
rv1sr has quit [Client Quit]
rv1sr has joined #ffmpeg
ewomer has quit [Ping timeout: 260 seconds]
rv1sr has quit [Client Quit]
rv1sr has joined #ffmpeg
microlappy has joined #ffmpeg
microlappy has quit [Client Quit]
s55 has quit [Remote host closed the connection]
s55 has joined #ffmpeg
Sciencentistguy has quit [Quit: Ping timeout (120 seconds)]
Sciencentistguy has joined #ffmpeg
deus0ww has quit [Ping timeout: 248 seconds]
intrac has quit [Remote host closed the connection]
intrac has joined #ffmpeg
deus0ww has joined #ffmpeg
stolen has joined #ffmpeg
sm1999 has quit [Ping timeout: 244 seconds]
sentriz has quit [Ping timeout: 272 seconds]
dreamon has quit [Ping timeout: 252 seconds]
sentriz has joined #ffmpeg
ppw has joined #ffmpeg
beastd has joined #ffmpeg
coldfeet has joined #ffmpeg
JavaBean has quit [Remote host closed the connection]
JavaBean has joined #ffmpeg
beastd has quit [Ping timeout: 265 seconds]
iive has joined #ffmpeg
dreamon has joined #ffmpeg
five6184803391 has quit [Remote host closed the connection]
five6184803391 has joined #ffmpeg
acovrig6012 has quit [Quit: The Lounge - https://thelounge.chat]
acovrig6012 has joined #ffmpeg
coldfeet has quit [Remote host closed the connection]
dreamon has quit [Quit: Leaving]
coldfeet has joined #ffmpeg
lavaball has joined #ffmpeg
coldfeet has quit [Quit: Lost terminal]
five6184803391 has quit [Remote host closed the connection]
five6184803391 has joined #ffmpeg
Dagger has quit [Ping timeout: 265 seconds]
EmleyMoor has joined #ffmpeg
Dagger has joined #ffmpeg
<aaabbb> is x264's aq-mode=2 and aq-mode=3 as broken as i've heard?
Blacker47 has quit [Quit: Life is short. Get a V.90 modem fast!]
stolen has quit [Quit: Connection closed for inactivity]
emmanuelux has joined #ffmpeg
Haxxa has quit [Quit: Haxxa flies away.]
Haxxa has joined #ffmpeg
squeaktoy has quit [Quit: WeeChat 4.3.2]
squeaktoy has joined #ffmpeg
squeaktoy has quit [Client Quit]
squeaktoy has joined #ffmpeg
rv1sr has quit []
Traneptora has quit [Quit: Quit]
<kepstin> no idea what you mean by "broken". I've successfully encoded some stuff with aq-mode=3 which did seem to look better in dark scenes.
jtgd has quit [Quit: WeeChat 4.4.2]
<aaabbb> kepstin: i have heard that it is particularly broken compared to x265's, and that virtually no one has tuned it for a long time
<aaabbb> when you use mode 3, is that because you can't do 10-bit to help the dark scenes?
jtgd has joined #ffmpeg
Traneptora has joined #ffmpeg
<kepstin> hmm, i don't do much 10-bit encodes with h264 since i'm normally using it for compatibility reasons at this point
<kepstin> the aq-mode thing isn't just "pick one and your videos will look better", it's "depending on video content, different aq mode and different strength settings might improve things a bit", so :/
<aaabbb> sure, i'm familiar with using it for x265
<aaabbb> generally with x265, the default 2 is fine, and 3 or 4 are usually recommended for 8bit encodes, and for animation. but i kept hearing that it is not recommended to even use 2 for x264
<kepstin> i haven't had much reason to use x264's mode 2, just the default 1 - or 3 if it helps with specific content.
<aaabbb> in theory, there is no reason not to and it should almost always be better. at lesat is for x265
RedShift has quit [Quit: Client closed]
<kepstin> well, that's a different encoder which just happens to have a similar name.
Warcop has quit [Remote host closed the connection]
Juest has quit [Ping timeout: 248 seconds]
deus0ww has quit [Ping timeout: 265 seconds]
deus0ww has joined #ffmpeg
SuicideShow has quit [Ping timeout: 246 seconds]
SuicideShow has joined #ffmpeg
Unit640 has quit [Quit: Leaving]
ewomer has joined #ffmpeg
Juest has joined #ffmpeg
StephenLynx has joined #ffmpeg
<StephenLynx> hey, I'm trying to write a simple program that scales a gif to a different size using libffmpeg. anyone more experienced could broadly tell me which steps would you take for it? I'm reading the examples.
<StephenLynx> but there seem to be different ways to achieve things. some involve instantiating a new stream, some dont.
<StephenLynx> some decode packets
Warcop has joined #ffmpeg
Warcop has quit [Remote host closed the connection]
ewomer has quit [Ping timeout: 252 seconds]
ewomer has joined #ffmpeg