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 7.1.1 has been released! | Please read ffmpeg.org/developer.html#Code-of-conduct
iive has quit [Quit: They came for me...]
IndecisiveTurtle has quit [Ping timeout: 265 seconds]
<cone-833>
ffmpeg Dmitrii Ovchinnikov master:64fce7202cfc: acvodec/amfenc: Enable use of AMF Surface in multiple encoders
Thulinma has joined #ffmpeg-devel
Son_Goku has quit [Read error: Connection reset by peer]
Son_Goku has joined #ffmpeg-devel
Thul has quit [Ping timeout: 276 seconds]
jamrial has joined #ffmpeg-devel
odrling has quit [Remote host closed the connection]
odrling has joined #ffmpeg-devel
rvalue has quit [Ping timeout: 265 seconds]
sepro has quit [Ping timeout: 272 seconds]
rvalue has joined #ffmpeg-devel
sepro has joined #ffmpeg-devel
System_Error has quit [Remote host closed the connection]
System_Error has joined #ffmpeg-devel
mkver has quit [Remote host closed the connection]
mkver has joined #ffmpeg-devel
mkver has quit [Read error: Connection reset by peer]
mkver has joined #ffmpeg-devel
bsFFFFFF has quit [Ping timeout: 260 seconds]
cone-833 has quit [Quit: transmission timeout]
<BtbN>
Why does this dtls thing the whip patch added even differentiate between tcp and udp URLContext?
<BtbN>
It seems to just litter a lot of extra-if's throughout the code, while tcp and udp could just have one urlcontext?
MisterMinister has joined #ffmpeg-devel
Richardcavell_ has quit [Ping timeout: 245 seconds]
<fflogger>
[newticket] luiscastro193: Ticket #11648 ([avutil] mpv cannot use vulkan decoder since ReBAR check) created https://trac.ffmpeg.org/ticket/11648
<kasper93>
ok, av_fast_padded_malloc vs av_fast_padded_mallocz breaks my brain
<TheVibeCoder>
why?
<kasper93>
what is the difference?
<kasper93>
I guess, the code is clear, but the doc string is weird, no?
<TheVibeCoder>
one of them memset to 0 allways?
<kasper93>
av_fast_padded_malloc <= In addition the whole buffer will initially and after resizes be 0-initialized so that no uninitialized data will ever appear.
<kasper93>
I don't understand this doc line
<TheVibeCoder>
but mallocz will mesmet again whole buffer in every call
<TheVibeCoder>
fast_padded_malloc() only memset grown bytes
<kasper93>
I see, zeroed "initially and after resizes", but not when no resize happens
Richardcavell_ has quit [Ping timeout: 265 seconds]
<BtbN>
wtf is up with ff_ssl_read_key_cert. Why does this function take _urls_ to keys? huh?
<JEEB>
:D
gnafu has quit [Quit: Rebooting for kernel update...]
<BtbN>
it reads like it's designed to do exactly what whip needs, while being utterly useless for anything else
<BtbN>
if whip needs to download keys via http, it should bloody do so itself
gnafu has joined #ffmpeg-devel
<BtbN>
I've successfully implemented DTLS via schannel now, but apparently whip has offloaded a bunch of its code into tls_openssl.c like that
<fflogger>
[editedticket] Balling: Ticket #11307 ([avcodec] [truehd_core] Application provided invalid, non monotonically increasing dts to muxer in stream 0) updated https://trac.ffmpeg.org/ticket/11307#comment:8
<JEEB>
I am totally not surprised :P
<BtbN>
ff_ssl_gen_key_cert I can kinda get behind
<BtbN>
but ff_ssl_read_key_cert is stupid
<BtbN>
ff_ssl_read_key_cert seems to be "download a key and a cert from arbitrary urls, write them to buffers in pem format, and calculate their fingerprint"
<ePirat>
BtbN, yeah some whip specific seems to just have been put in the tls file...
<BtbN>
it's not _technically_ whip specific, but its usecase is so hyper specific, I don't see anything else using it, ever
<BtbN>
tls.c did gain a log message that claims the generic tls code is WHIP though...
<BtbN>
Something random I just noticed as well... our udp.c has no way to find out who sent what was just read, does it?
<fflogger>
[editedticket] microchip: Ticket #11307 ([avcodec] [truehd_core] Application provided invalid, non monotonically increasing dts to muxer in stream 0) updated https://trac.ffmpeg.org/ticket/11307#comment:9
<cone-657>
ffmpeg Steven Liu master:f8a9d9473b0a: avformat/whip: check the exchange sdp url is start with http
<ePirat>
BtbN, now that its associated with my account it seems it even merged the submitter IDs, as i see all patches with either of them now.
<kasper93>
BtbN: is patchwork reset password should work? I think everytime I try it never send anything
<BtbN>
It does send it, it just gets insta-trashed as spam by Google and the likes
<kasper93>
I don't even see it in spam folder, you say it is droped even before?
<fflogger>
[editedticket] Balling: Ticket #11646 ([swscale] Full range RGB to YUV conversion using swscale has a slight green tint.) updated https://trac.ffmpeg.org/ticket/11646#comment:1
lemourin has quit [Read error: Connection reset by peer]
lemourin has joined #ffmpeg-devel
<BtbN>
Yes, Google just straight up rejects it
<BtbN>
didn't check other big providers
<kasper93>
sad
lemourin2 has joined #ffmpeg-devel
lemourin has quit [Killed (zirconium.libera.chat (Nickname regained by services))]
lemourin2 is now known as lemourin
HarshK23 has quit [Quit: Connection closed for inactivity]
<BtbN>
ah, no. It does actually seem to be an internal issue in patchwork
<BtbN>
Though I have no idea how to fix it
<BtbN>
it connected to the mailserver, and then instantly cleanly disconnects again, without ever sending any mails
lemourin1 has joined #ffmpeg-devel
lemourin is now known as Guest3103
Guest3103 has quit [Killed (osmium.libera.chat (Nickname regained by services))]
lemourin1 is now known as lemourin
<cone-657>
ffmpeg Frank Plowman master:540a2497d238: lavc/vvc: Fix condition for using default scaling factor
lemourin8 has joined #ffmpeg-devel
lemourin is now known as Guest5561
lemourin8 is now known as lemourin
Guest5561 has quit [Ping timeout: 248 seconds]
<cone-657>
ffmpeg Marvin Scholz master:0578d4ad2f85: fftools/textformat: exit early in mermaid_print_value
<fflogger>
[editedticket] kasper93: Ticket #11646 ([swscale] Full range RGB to YUV conversion using swscale has a slight green tint.) updated https://trac.ffmpeg.org/ticket/11646#comment:2