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.0.1 has been released! | Please read ffmpeg.org/developer.html#Code-of-conduct
compnn has joined #ffmpeg-devel
compn has quit [Read error: Connection reset by peer]
MrZeus has quit [Read error: Connection reset by peer]
MrZeus has joined #ffmpeg-devel
thilo has quit [Ping timeout: 264 seconds]
thilo has joined #ffmpeg-devel
haihao has quit [Ping timeout: 255 seconds]
haihao has joined #ffmpeg-devel
lemourin has quit [Quit: The Lounge - https://thelounge.chat]
tufei_ has quit [Quit: Leaving]
lemourin has joined #ffmpeg-devel
arch1t3cht3 has joined #ffmpeg-devel
arch1t3cht has quit [Ping timeout: 268 seconds]
arch1t3cht3 is now known as arch1t3cht
aphysically has joined #ffmpeg-devel
sgm has quit [Remote host closed the connection]
sgm has joined #ffmpeg-devel
jamrial has quit []
HarshK23 has joined #ffmpeg-devel
Martchus has joined #ffmpeg-devel
Martchus_ has quit [Ping timeout: 268 seconds]
Kei_N_ has joined #ffmpeg-devel
Kei_N has quit [Ping timeout: 252 seconds]
tufei has joined #ffmpeg-devel
MrZeus has quit [Ping timeout: 252 seconds]
_DuBPiRaTe_ has joined #ffmpeg-devel
tufei_ has joined #ffmpeg-devel
tufei has quit [Remote host closed the connection]
Kei_N has joined #ffmpeg-devel
Kei_N_ has quit [Ping timeout: 268 seconds]
AbleBacon has quit [Read error: Connection reset by peer]
_DuBPiRaTe_ has quit [Ping timeout: 256 seconds]
_DuBPiRaTe_ has joined #ffmpeg-devel
_DuBPiRaTe_ has quit [Ping timeout: 268 seconds]
_DuBPiRaTe_ has joined #ffmpeg-devel
_DuBPiRaTe_ has quit [Ping timeout: 268 seconds]
compnn has quit [Ping timeout: 252 seconds]
nevcairiel has quit [Quit: http://quassel-irc.org - Chat comfortably. Anywhere.]
nevcairiel has joined #ffmpeg-devel
compn has joined #ffmpeg-devel
compn has quit [Read error: Connection reset by peer]
compn has joined #ffmpeg-devel
darkapex has joined #ffmpeg-devel
rvalue- has joined #ffmpeg-devel
rvalue has quit [Ping timeout: 268 seconds]
rvalue- is now known as rvalue
Livio has joined #ffmpeg-devel
compn has quit [Read error: Connection reset by peer]
compn has joined #ffmpeg-devel
haihao has quit [Ping timeout: 256 seconds]
haihao has joined #ffmpeg-devel
Livio has quit [Ping timeout: 268 seconds]
mkver has joined #ffmpeg-devel
compn has quit [Read error: Connection reset by peer]
compn has joined #ffmpeg-devel
HarshK23 has quit [Quit: Connection closed for inactivity]
yigit has joined #ffmpeg-devel
ccawley2011 has joined #ffmpeg-devel
<haasn> yeah I was thinking the same
<haasn> converting *from* pal8 is not as useful as converting *to* pal8
<haasn> specifically with proper dithering (ED etc.)
<haasn> iirc swscale still is terribad at encoding gifs
<haasn> michaelni: how do we feel about breaking swscale output across versions of libswscale?
<haasn> it would break unit tests that rely on specific bitexact outputs
<haasn> it's not clear if "bitexact" is just meant to be stable across hardware, or if it's also meant to be stable across *time*
<haasn> I think that it might be okay to have the flag imply only the former, not the latter
<nevcairiel> stable over time is never a possible guarantee
<michaelni> it doesnt need to be stable across time but i really would prefer if the number of breaks are small and not one every month
<michaelni> if possible ...
<haasn> right
<haasn> michaelni: context on ML; but I was planning on adding an `int quality` for controlling the speed/quality tradeoff preset
<haasn> and I wonder if the semantics of BITEXACT would prevent us from ever changing e.g. the default settings
haihao has quit [Ping timeout: 255 seconds]
haihao has joined #ffmpeg-devel
yigit has quit [Ping timeout: 250 seconds]
jamrial has joined #ffmpeg-devel
sgm has quit [Quit: sgm]
sgm has joined #ffmpeg-devel
sgm has quit [Remote host closed the connection]
sgm has joined #ffmpeg-devel
ccawley2011 has quit [Read error: Connection reset by peer]
tufei_ has quit [Remote host closed the connection]
tufei_ has joined #ffmpeg-devel
rvalue has quit [Read error: Connection reset by peer]
rvalue has joined #ffmpeg-devel
Livio has joined #ffmpeg-devel
Livio has quit [Ping timeout: 252 seconds]
LaserEyess has quit [Quit: fugg]
LaserEyess has joined #ffmpeg-devel
<ePirat> michaelni, can I get access to the coverity reports please?
Livio has joined #ffmpeg-devel
Krowl has joined #ffmpeg-devel
meltq has quit [Quit: Connection closed for inactivity]
<BtbN> iirc you need to make an account and request access here: https://scan.coverity.com/projects/ffmpeg
<BtbN> ePirat:
elvis_a_presley has quit [Quit: smoke-bomb ; grapple-hook]
elvis_a_presley has joined #ffmpeg-devel
<michaelni> ePirat, approved coverity access
<ePirat> thanks
<Lynne> haasn: bitexact should not exist
<Lynne> CPUs don't play dice
<nevcairiel> random dither patterns are a thing
<BtbN> We also already had a situation where different CPUs disagree about intricacies of conversions to/from floats
<BtbN> none that matter, but they're not bit to bit identical
<courmisch> can I relocate to an isekai where checkasm is right and FATE and ITU-T spec don't matter?
<nevcairiel> only if it has a magical hovering cube that always spits out perfect checkasm tests
<courmisch> nevcairiel: would it be preferable to reverse-isekai the magical hovering cube to our plane? works for me either way
<Lynne> nevcairiel: sure, but if you run the same code twice, there should be no change
<nevcairiel> its not exactly a random pattern then
<courmisch> so my h264 loop filter passes checkasm but breaks FATE
<courmisch> surely that's a problem in FATE
cone-892 has joined #ffmpeg-devel
<cone-892> ffmpeg Rémi Denis-Courmont master:d5e603ddc072: lavu/lls: remove useless VSETVL
<jamrial> courmisch: alignment? overreliance on padding?
<courmisch> jamrial: code assumes 8-bit alignment and no padding
<courmisch> my money is on intermediate arithmetic overflow
<courmisch> FWIW, checkasm fails to test strictly negative TC values
<courmisch> pun unintended, but still funny
haihao has quit [Ping timeout: 268 seconds]
haihao has joined #ffmpeg-devel
unlord has quit [Changing host]
unlord has joined #ffmpeg-devel
Krowl has quit [Read error: Connection reset by peer]
<kurosu> courmisch: tc offsets, or final tc values (used for clipping and look up tables)? I don't think the later would be defined. Not even sure it would be legal for this to happen
<kurosu> anyway I guess the later is not much of a solace, and has to be handled anyway
<haasn> Lynne: Without bitexact we could for example reassociate operations
<haasn> Or enable SIMD paths that round differently from C
<Lynne> nevcairiel: in the time domain it is random, but predictable
<Lynne> quality settings can do that too
<courmisch> kurosu: I dunno, but Lorren Merrit added a check for negative TC values whilst adding MMX support
<courmisch> kurosu: it seems to me that the calling code forces negative values in "some cases", but I have zero knowledge of ffh264 insides
aphysically has quit [Ping timeout: 246 seconds]
Krowl has joined #ffmpeg-devel
jamrial has quit []
___nick___ has joined #ffmpeg-devel
Livio has quit [Ping timeout: 252 seconds]
Livio has joined #ffmpeg-devel
Krowl has quit [Read error: Connection reset by peer]
darkapex has quit [Remote host closed the connection]
darkapex has joined #ffmpeg-devel
Kwiboo has quit [Quit: .]
Kwiboo has joined #ffmpeg-devel
microchip__ has joined #ffmpeg-devel
microchip_ has quit [Ping timeout: 268 seconds]
microchip__ is now known as microchip_
___nick___ has quit [Ping timeout: 268 seconds]
compn has quit [Read error: Connection reset by peer]
compn has joined #ffmpeg-devel
<kurosu> ok, looks like a signalling trick. I think the code sets bS for an "edge" to 0 to indicate it doesn't need filtering. The 0 entry in the tc table is always -1: chroma adds 1 to it, luma does nothing. In all cases, the value is indeed <= 0
<kurosu> So the meaning of a <= 0 value is just a convenience to say "don't filter edge"
<kurosu> maybe that could be caught earlier than in the leaf function, but ok, makes more sense, and you do have to implement it
Livio has quit [Quit: Reconnecting]
Livio has joined #ffmpeg-devel
___nick___ has joined #ffmpeg-devel
___nick___ has quit [Client Quit]
IndecisiveTurtle has joined #ffmpeg-devel
___nick___ has joined #ffmpeg-devel
compnn has joined #ffmpeg-devel
compn has quit [Read error: Connection reset by peer]
compn has joined #ffmpeg-devel
compnn has quit [Ping timeout: 256 seconds]
AbleBacon has joined #ffmpeg-devel
cone-892 has quit [Quit: transmission timeout]
IndecisiveTurtle has quit [Remote host closed the connection]
___nick___ has quit [Ping timeout: 256 seconds]
mkver has quit [Ping timeout: 252 seconds]