michaelni changed the topic of #ffmpeg-devel to: Welcome to the FFmpeg development channel | Questions about using FFmpeg or developing with libav* libs should be asked in #ffmpeg | This channel is publicly logged | FFmpeg 6.1 has been released! | Please read ffmpeg.org/developer.html#Code-of-conduct
Owner__ is now known as Marth64
navi has quit [Quit: WeeChat 4.0.4]
cone-714 has quit [Quit: transmission timeout]
<Lynne>
ubitux: the mpeg rc system we have
<Lynne>
it was used as the basis for x264's single-pass rc system, so it's been tested in one form
<ubitux>
alright, let's add MpegEncContext to prores encoders
<Lynne>
:)
<Lynne>
it's a downside, I have a branch with daala's/rav1e's RC system which I plan to use for AAC one day
<Lynne>
so if it's too messy to use mpeg's rc feel free to just pick one and let it get replaced one day
Guest82 has joined #ffmpeg-devel
<ubitux>
from what i can tell prores_aw chooses an initial quant level per slice (1 slice is a strip of 1 to 8 MBs) which gets updated ±1 after each slice on the fly, while prores_ks seems to have an estimation pass where it tries out all kind of q params for each slice in advance
<ubitux>
prores_aw is definitely simpler, but i'm not sure how worst (or better?) it is compared to prores_ks
dellas has quit [Remote host closed the connection]
iive has quit [Quit: They came for me...]
<Lynne>
aw will look worse but keep a bitrate constant throughout a frame
<Lynne>
I think that's more important for prores
<Lynne>
just make sure that it does the right thing by calculating a budget for each frame, divides by the slice count, and tries to have each slice encoded in around that amount, possibly with heuristics or direct encoded size checks
<Marth64>
Hi, I've been having an issue for some time where genpts causes hanging during demuxing on certain input DVDs ("q"/interrupt doesn't work), which have a ton of DTS discontinuities. This got me digging and I found that by removing `next_pkt->pts == AV_NOPTS_VALUE` from this conditional, the process works normally and the hanging goes away. Is there a reason why when using +genpts, demux must expect the next packet to have a PTS? Isn't genpts "best
<Marth64>
genpts isn't ideal but I ran into this while experimenting so was just curious (unlikely, but maybe a bug?)
marcj has quit [Ping timeout: 260 seconds]
thilo has quit [Ping timeout: 255 seconds]
thilo has joined #ffmpeg-devel
MrZeus_ has quit [Ping timeout: 256 seconds]
marcj has joined #ffmpeg-devel
Guest82 has quit [Quit: Client closed]
mkver has joined #ffmpeg-devel
lemourin has quit [Read error: Connection reset by peer]
lemourin has joined #ffmpeg-devel
jamrial has quit []
jkqxz has quit [Ping timeout: 240 seconds]
jkqxz has joined #ffmpeg-devel
Guest8 has joined #ffmpeg-devel
Guest8 has quit [Client Quit]
fengdaolong has joined #ffmpeg-devel
tufei__ has joined #ffmpeg-devel
tufei_ has quit [Remote host closed the connection]
qeed has quit [Quit: Leaving]
fengdaolong has quit [Quit: WeeChat 4.1.2]
dellas has joined #ffmpeg-devel
Sk0tik has quit [Ping timeout: 256 seconds]
dellas has quit [Remote host closed the connection]
psykose has quit [Remote host closed the connection]
psykose has joined #ffmpeg-devel
MikhailAMD has quit [Ping timeout: 245 seconds]
AbleBacon has quit [Read error: Connection reset by peer]
Krowl has joined #ffmpeg-devel
clarkh_ has joined #ffmpeg-devel
Teukka has quit [Read error: Connection reset by peer]
Teukka has joined #ffmpeg-devel
Teukka has quit [Changing host]
Teukka has joined #ffmpeg-devel
clark_hung has joined #ffmpeg-devel
clark_hung68 has joined #ffmpeg-devel
clark_hung68 has quit [Client Quit]
clark_hung has quit [Quit: Client closed]
Krowl has quit [Read error: Connection reset by peer]
dellas has joined #ffmpeg-devel
clark_hung has joined #ffmpeg-devel
clark_hung has quit [Client Quit]
clark_hung has joined #ffmpeg-devel
ccawley2011 has joined #ffmpeg-devel
Krowl has joined #ffmpeg-devel
emersion has quit [Remote host closed the connection]
emersion has joined #ffmpeg-devel
dellas has quit [Ping timeout: 256 seconds]
dellas has joined #ffmpeg-devel
<elenril>
Marth64: genpts is evil
<elenril>
don't use it
xxpor has quit [Ping timeout: 252 seconds]
xxpor has joined #ffmpeg-devel
Krowl has quit [Read error: Connection reset by peer]
Krowl has joined #ffmpeg-devel
kurosu has joined #ffmpeg-devel
* elenril
stabs jdek
<jdek>
Im stabbed whats up
<elenril>
>lavd: Add SDL2 output device
<jdek>
disaster
<elenril>
for what purpose
<jdek>
was added to appease nicolas george so hed stop blocking my set
<elenril>
...oh
<elenril>
that's a plot twist
<jdek>
i don’t personally think it should exist
<elenril>
ah, good
<elenril>
carry on then
<jdek>
We have an opengl renderer too iirc
<jdek>
also shouldnt exist
<elenril>
we have way too many things that shouldn't exist
<jdek>
not wrong, but if you want to fight nicolas george on removing it be my guest
<jdek>
Youd have my blessing
<elenril>
i actually might
<jdek>
I just often don’t have the mental capacity for interacting with the mailing list in general, let alone fighting NG
<jdek>
I think at the time i decided that supporting sdl2 in general was the bigger win
<jdek>
because we were on sdl1 a few years after it was abandoned
<elenril>
that explains why he's so active in the thread
<elenril>
i thought it's just seething about threading
<elenril>
>The latency is obviously real and obviously unavoidable
<elenril>
lmao
<elenril>
I see he doesn't know much about computers or latency
<kierank>
the buffer in a pipe is quite small
<jdek>
I think the main reason he wants it was to inspect filtergraphs? but you can easily just create another output pipe and use an actual videoplayer to view it
<jdek>
ill check ML in a sec
<Lynne>
I just use -c:v rawvideo -f nut - | mpv - instead
aaabbb is now known as aaabbb_
aaabbb_ is now known as aaabbb
<jdek>
Exactly what I do too
aaabbb is now known as bbbaaa
bbbaaa is now known as aaabbb
<elenril>
yuv4mpeg allows you to avoid some memcpies
<elenril>
but that probably doesn't matter much in most cases
navi has joined #ffmpeg-devel
clarkh_ has quit [Quit: Connection closed for inactivity]
<jdek>
courmisch: riscv board just arrived c:
jamrial has joined #ffmpeg-devel
mkver has quit [Ping timeout: 256 seconds]
Guest82 has joined #ffmpeg-devel
mkver has joined #ffmpeg-devel
Guest82 has quit [Quit: Client closed]
Guest82 has joined #ffmpeg-devel
rvalue has quit [Ping timeout: 276 seconds]
rvalue has joined #ffmpeg-devel
Lypheo7 has joined #ffmpeg-devel
Lypheo has quit [Ping timeout: 245 seconds]
Lypheo7 is now known as Lypheo
qeed has joined #ffmpeg-devel
clarkh_ has joined #ffmpeg-devel
rvalue has quit [Ping timeout: 260 seconds]
rvalue has joined #ffmpeg-devel
<elenril>
michaelni: i'm seeing smtp delivery errors for cc@ forwarded to gmail
<elenril>
does the mailserver keep original envelope-from?
<elenril>
it probably shouldn't
Krowl has quit [Read error: Connection reset by peer]
<michaelni>
elenril, i dont know, cc/tc are just aliases, iam pretty sure nothing changed on how they are setup for many years. but i think you know more about mail setup stuff. So if you know how to fix this?
Krowl has joined #ffmpeg-devel
<elenril>
I don't know how would gmail or other big servers treat mismatching from header vs. envelope from
<elenril>
but it seems correct that the forwarded emails should have a @ffmpeg.org envelope-from
<elenril>
I can check how to do that in postfix if you want
lexano has quit [Ping timeout: 255 seconds]
<michaelni>
elenril, if we do it wrong and you can tell me how to make it right i can change it. But also consider that these addresses receive spam and that too can be forwarded sometimes. We dont want ffmpeg.org to end on spam blacklists
lexano has joined #ffmpeg-devel
MrZeus_ has joined #ffmpeg-devel
rvalue has quit [Ping timeout: 245 seconds]
<elenril>
I never got spam from tc@
rvalue has joined #ffmpeg-devel
<jamrial>
ffmpeg-devel-owner already gets a shitload of spam fwiw
<Daemon404>
i love how elenril replies 'absolutely not', followe by ng 10 mins later with lgtm
<Daemon404>
is the cc functional yet? can he be referre?
<Daemon404>
(not for that but, *points at entire ML*)
<jamrial>
Daemon404: that'd be the TCs job (referee), if it comes to it
<Daemon404>
no....
<Daemon404>
he has a sustained track record of CC violations
<Daemon404>
like, constant.
<Daemon404>
not just technical isagreements
<jamrial>
ah, you mean his attitude
<Daemon404>
yes
<jamrial>
yeah, CC then
<elenril>
the CC is on it
<Daemon404>
grrr too much vim has half-killed me 'd' key
<elenril>
you mean too much quake3
MrZeus__ has joined #ffmpeg-devel
MrZeus_ has quit [Ping timeout: 256 seconds]
clarkh_ has quit [Quit: Connection closed for inactivity]
Guest82 has quit [Quit: Client closed]
darkapex has quit [Remote host closed the connection]
darkapex has joined #ffmpeg-devel
Krowl has quit [Read error: Connection reset by peer]
<Marth64>
elenril: pt taken...moving on from genpts
jamrial has quit [Ping timeout: 268 seconds]
xxpor has quit [Ping timeout: 276 seconds]
xxpor has joined #ffmpeg-devel
Krowl has joined #ffmpeg-devel
<courmisch>
jdek: yes thanks for volunteering to write all remaining missing optimisations
<jdek>
courmisch: look forward to it
jamrial has joined #ffmpeg-devel
tufei__ has quit [Remote host closed the connection]
tufei__ has joined #ffmpeg-devel
clark_hung has quit [Quit: Client closed]
Marth64 has quit [Remote host closed the connection]
Marth64 has joined #ffmpeg-devel
rcctl has joined #ffmpeg-devel
mkver has quit [Ping timeout: 256 seconds]
<elenril>
JEEB: I just saw a random failure in fate-ffmpeg-fix_sub_duration_heartbeat
<elenril>
*ominous wind blowing*
<BBB>
quick, call the ghostbusters
cone-643 has joined #ffmpeg-devel
<cone-643>
ffmpeg Marton Balint master:1f721beeff06: avutil/tests/imgutils: add tests for av_image_fill_black()
<cone-643>
ffmpeg Marton Balint master:3c5e82316e70: avutil/tests/imgutils: factorize basic tests to new function
<cone-643>
ffmpeg Marton Balint master:32cb4504f384: avutil/imgutils: fix av_image_fill_black() for some pixel formats
<cone-643>
ffmpeg Marton Balint master:74a269c3ceac: avutil/imgutils: add support for 32bit pixel format for av_image_fill_black()
<cone-643>
ffmpeg Marton Balint master:5475f665f60e: avutil/imgutils: add new function av_image_fill_color()
<cone-643>
ffmpeg Marton Balint master:0ae8afffb40f: avutil/imgutils: factorize a fill color function
<JEEB>
I don't think anyone tested on ARM or RISC-V tho
<courmisch>
elenril: how is that not R? there's no mixing up memory accesses and calculations
<courmisch>
and the instruction encoding is very much within the norm for OP-IMM instructions
<elenril>
>Ubuntu’s long standing reputation for performance
<elenril>
seriously?
<elenril>
where can you go after starting your text with this
<courmisch>
you're just jealous that AMorDor64 does not have such wonder
<courmisch>
elenril: to OpenAI?
<elenril>
I guess
<kierank>
elenril: what's wrong with ubuntu performance
<courmisch>
frame pointers cost basically nothing on AArch64, since you can write the frame pointer with the return address that you need to spill anyway
<elenril>
kierank: most ubuntu installs I've had to deal with were very outdated
<courmisch>
but on register-deprived AMorDor64, you don't want to waste a register for FP
<elenril>
and I've never ever heard anyone praise it specifically for performance
<elenril>
gentoo, yes
<elenril>
never ubuntu
<courmisch>
how is Gentoo performant? you'll have a new kernel version before you're done compiling it
<JEEB>
recently the intel thing liked to show off optimizatins
<JEEB>
what was it again?
<JEEB>
clear linux
<courmisch>
does Clear Linux support Intel APX yet?
<JEEB>
they also do multi-binaries where they have binaries with multiple versions for different optimizations
<JEEB>
so that you can have AVX2 hereWeGoooo together with blander x86_64
rcctl has left #ffmpeg-devel [#ffmpeg-devel]
<courmisch>
funny how Intel pitched APX for JITs, but then they rushed to support it in GCC. Like uh?
<courmisch>
elenril: to be fair, their point is that retaining FP enables profiling, not that it makes things faster
<elenril>
that makes that first sentence even stranger