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 has been released! | Please read ffmpeg.org/developer.html#Code-of-conduct
rvalue- has joined #ffmpeg-devel
rvalue has quit [Ping timeout: 272 seconds]
rvalue- is now known as rvalue
Kei_N has joined #ffmpeg-devel
Kei_N_ has quit [Ping timeout: 260 seconds]
iive has quit [Quit: They came for me...]
_whitelogger_ has quit [Remote host closed the connection]
Traneptora has quit [Quit: Quit]
Traneptora has joined #ffmpeg-devel
_whitelogger_ has joined #ffmpeg-devel
Traneptora has quit [Quit: Quit]
tufei_ has quit [Quit: Leaving]
IndecisiveTurtle has quit [Ping timeout: 260 seconds]
tufei has joined #ffmpeg-devel
_whitelogger_ has quit [Remote host closed the connection]
tufei has quit [Ping timeout: 260 seconds]
_whitelogger_ has joined #ffmpeg-devel
thilo has quit [Ping timeout: 245 seconds]
thilo has joined #ffmpeg-devel
arch1t3cht4 has joined #ffmpeg-devel
arch1t3cht has quit [Ping timeout: 272 seconds]
arch1t3cht4 is now known as arch1t3cht
cone-056 has joined #ffmpeg-devel
<cone-056> ffmpeg Marth64 master:7332b1700e3b: avformat/sapdec: check return value of avcodec_parameters_copy()
_whitelogger_ has quit [Remote host closed the connection]
_whitelogger_ has joined #ffmpeg-devel
<aaabbb> as part of https://fftrac-bg.ffmpeg.org/ticket/8343 i'm reading through h.261 specs about whether the freeze-picture release bit must be set for intraframes because if so, then the h261dec can be made to set AVFrame::key_frame whenever that bit is set (h261enc sets that bit when doing keyframes). basically i am trying to find out if michaelni's objections in
<aaabbb> i can tell so far that a fast-update request will cause the next frame to be a keyframe
<aaabbb> i'm looking for files encoded to h261 that were not encoded with ffmpeg's h261enc
<aaabbb> is mencoder's h261 encoder completely distinct from ffmpeg's?
<aaabbb> it doesn't help that h261dec barfs on many samples from https://samples.mplayerhq.hu/V-codecs/h261/
System_Error has joined #ffmpeg-devel
jamrial has quit []
_whitelogger_ has quit [Remote host closed the connection]
<aaabbb> it looks to me like there's no explicit way to signal an intraframe in h.261 although there are some signals that guarantee that the next frame is one. because of how simple h261 is, could it be enough to mark any frame with 100% intra-blocks as a keyframe, and have h261dec emit AVFrame:key_frame when the whole frame is all intra-blocks?
_whitelogger_ has joined #ffmpeg-devel
<compn> let h261 dieeeeeeeeeeeee /s
<compn> i think mencoder uses -ovc lavc and then -lavcopts vcodec=h261 so that would be ffmpeg's h261 encoder
<aaabbb> damn
<compn> or is it -lavencopts
<aaabbb> lots of illegal acs and macroblock errors
^Neo has quit [Ping timeout: 252 seconds]
Martchus has joined #ffmpeg-devel
Martchus_ has quit [Ping timeout: 252 seconds]
System_Error has quit [Remote host closed the connection]
System_Error has joined #ffmpeg-devel
\\Mr_C\\ has quit [Remote host closed the connection]
_whitelogger_ has quit [Remote host closed the connection]
_whitelogger_ has joined #ffmpeg-devel
_whitelogger_ has quit [Remote host closed the connection]
_whitelogger_ has joined #ffmpeg-devel
<fflogger> [newticket] kxxt: Ticket #11302 ([avcodec] RISCV: Properly set relocate parameter of const macro in libavcodec/riscv/h264dsp_rvv.S) created https://trac.ffmpeg.org/ticket/11302
cone-056 has quit [Quit: transmission timeout]
<fflogger> [editedticket] kxxt: Ticket #11302 ([avcodec] RISCV: Properly set relocate parameter of const macro in libavcodec/riscv/h264dsp_rvv.S) updated https://trac.ffmpeg.org/ticket/11302#comment:2
_whitelogger_ has quit [Remote host closed the connection]
_whitelogger_ has joined #ffmpeg-devel
System_Error has quit [Remote host closed the connection]
System_Error has joined #ffmpeg-devel
System_Error has quit [Remote host closed the connection]
System_Error has joined #ffmpeg-devel
HarshK23 has joined #ffmpeg-devel
_whitelogger_ has quit [Remote host closed the connection]
System_Error has quit [Ping timeout: 260 seconds]
cone-813 has joined #ffmpeg-devel
<cone-813> ffmpeg Peter Ross master:6ccd16dda2e1: configure: add rv60 decoder golomb dependency
<cone-813> ffmpeg Peter Ross master:f7e7d63cbcf3: avcodec/rv60: simplify fill_mv_skip_cand
<cone-813> ffmpeg Peter Ross master:566b737a7a7a: avcodec/rv60: loosen fill_mv_skip_cand top right and bottom left criteria
<cone-813> ffmpeg Peter Ross master:7b3bc4a45ba0: avcodec/rv60: consistent indentation
_whitelogger_ has joined #ffmpeg-devel
<fflogger> [editedticket] pross: Ticket #11293 ([undetermined] rv60: visible artefacts 2) updated https://trac.ffmpeg.org/ticket/11293#comment:4
System_Error has joined #ffmpeg-devel
_whitelogger_ has quit [Remote host closed the connection]
_whitelogger_ has joined #ffmpeg-devel
Traneptora has joined #ffmpeg-devel
mkver has joined #ffmpeg-devel
j45_ has joined #ffmpeg-devel
j45 has quit [Ping timeout: 248 seconds]
j45_ is now known as j45
j45 has quit [Changing host]
j45 has joined #ffmpeg-devel
<fflogger> [newticket] ff_tux: Ticket #11303 ([undetermined] AAC files are always reported as constant bitrate) created https://trac.ffmpeg.org/ticket/11303
cone-813 has quit [Quit: transmission timeout]
<fflogger> [editedticket] michael: Ticket #5548 ([avcodec] FFV1 encoder creates invalid stream with -level 3 if width or height is between 1 and 3) updated https://trac.ffmpeg.org/ticket/5548#comment:3
<fflogger> [editedticket] michael: Ticket #11128 ([avcodec] FFV1 encodes files that fail strict 3rd-party MediaConch validation when using 2-pass encoding) updated https://trac.ffmpeg.org/ticket/11128#comment:4
^Neo has joined #ffmpeg-devel
^Neo has quit [Changing host]
^Neo has joined #ffmpeg-devel
<BBB> elenril: I had the same reaction to that x265 post, btw. I still don't think we should delete it (or flag it experimental) but I agree with the "WTF" sentiment
<JEEB> now to recall where the heck picture crop was in HEVC parameter setds
<elenril> BBB: a codec of which you cannot have two instances should be _at least_ experimental
<elenril> and with a fat blinking runtime warning
jamrial has joined #ffmpeg-devel
cone-569 has joined #ffmpeg-devel
<cone-569> ffmpeg Michael Niedermayer master:967e5e8f6f6b: avcodec/ffv1: Support slice coding mode 1 with golomb rice
<cone-569> ffmpeg Michael Niedermayer master:a5c0ed2122a9: avcodec/ffv1: Support >8bit rice golomb
<cone-569> ffmpeg Michael Niedermayer master:0b8c9cf5b490: avformat/movenc: Fix ffv1 support
<fflogger> [editedticket] michael: Ticket #9975 ([avformat] Please support ffv1 in mp4 containers) updated https://trac.ffmpeg.org/ticket/9975#comment:2
novaphoenix has quit [Quit: i quit]
novaphoenix has joined #ffmpeg-devel
blb has quit [Ping timeout: 272 seconds]
blb has joined #ffmpeg-devel
lemourin has quit [Quit: The Lounge - https://thelounge.chat]
lemourin has joined #ffmpeg-devel
<BBB> elenril: I certainly agree with the sentiment that this is messed up
<JEEB> fun, vaapi hevc encoder outputs 1920x1088 if a 1920x1080 frame is received directly from vaapi decoder
<JEEB> but if I swdec and hwupload, it's properly output by the same encoder as 1080
<llyyr> JEEB: there was a patch to fix it
<JEEB> yea i just feel like it's really weird that the boog only happens when it's a decoded vaapi frame
<JEEB> and when you give the exact same encoder a VAAPI frame that was hwuploaded after swdec, that is JustFine
witchymary has quit [Remote host closed the connection]
<JEEB> llyyr: or is that fix actually for the *decoder* as it's outputting a weird surface/frame?
<JEEB> and then that fixes encoder
witchymary has joined #ffmpeg-devel
<llyyr> JEEB: the amd encoder asks for 64x16 alignment, it just needs to communicate that to the encoder from ffmpeg side that it's using 16x16
<llyyr> I don't know enough about this to say why it doesn't happen with swdec frames
<Lynne> for av1 we'll have to implement support for cropping via side data sadly
lemourin has quit [Quit: The Lounge - https://thelounge.chat]
<JEEB> llyyr: literally this made it output something that was flagged 1920x1080 -init_hw_device vaapi=foo -filter_hw_device foo -i INPUT -vf hwupload,format=vaapi
<jamrial> is that not already supported? for amd i mean
<JEEB> llyyr: then there's a separate boog where the result of that yuv420p into the encoder is lulzy pink, but it is 1920x1080 pink :D
<llyyr> :shrug:
<JEEB> (if you then add ,scale_vaapi=format=nv12 it's perfect)
<JEEB> thus for whatever goddamn reason it's dependent on the type of VAAPI surface the encoder is getting
lemourin has joined #ffmpeg-devel
<JEEB> I'll see if I can see anything interesting in that AVFrame
<JEEB> ah wait no, the vaapi scale one is 1088
<JEEB> OK, ignore me - how the heck did I believe I saw 1080
<JEEB> at least that means it's consistent
<llyyr> doesn't seem like it's been possible until recently
<JEEB> yea
<JEEB> so, uh, I thought at one point that autodetected libraries would be "system libraries", but then I see > sdl2
<JEEB> so what if I were to propose addition of dav1d into autodetect :D
<jamrial> JEEB: that one is because ffplay i suppose
<JEEB> I would expect that's where it has historically come from
Mirarora has joined #ffmpeg-devel
<fflogger> [editedticket] mkver: Ticket #11114 ([avcodec] fate-avid-meridian fails on ppc64{,el}) updated https://trac.ffmpeg.org/ticket/11114#comment:6
cone-569 has quit [Quit: transmission timeout]
elvis_a_presley has quit [Quit: smoke-bomb ; grapple-hook]
courmisch_ has joined #ffmpeg-devel
courmisch has quit [Ping timeout: 260 seconds]
AMM has quit [Quit: No Ping reply in 180 seconds.]
_whitelogger__ has joined #ffmpeg-devel
_whitelogger_ has quit [*.net *.split]
thilo has quit [*.net *.split]
wyatt8740 has quit [*.net *.split]
bilboed has quit [*.net *.split]
rodeo has quit [*.net *.split]
michaelni has quit [*.net *.split]
jess has quit [*.net *.split]
SuperFashi has quit [*.net *.split]
nitroxis has quit [*.net *.split]
sfan5 has quit [*.net *.split]
Gramner has quit [*.net *.split]
Guest7164 has quit [*.net *.split]
wbs has quit [*.net *.split]
ChanServ has quit [*.net *.split]
kekePower has joined #ffmpeg-devel
kekePower has quit [Quit: Ping timeout (120 seconds)]
llyyr has quit [Quit: Quit]
AMM has joined #ffmpeg-devel
nitroxis has joined #ffmpeg-devel
ChanServ has joined #ffmpeg-devel
thilo has joined #ffmpeg-devel
rodeo has joined #ffmpeg-devel
bilboed has joined #ffmpeg-devel
wyatt8740 has joined #ffmpeg-devel
michaelni has joined #ffmpeg-devel
jess has joined #ffmpeg-devel
SuperFashi has joined #ffmpeg-devel
Guest7164 has joined #ffmpeg-devel
wbs has joined #ffmpeg-devel
Gramner has joined #ffmpeg-devel
sfan5 has joined #ffmpeg-devel
thilo has quit [*.net *.split]
wyatt8740 has quit [*.net *.split]
bilboed has quit [*.net *.split]
rodeo has quit [*.net *.split]
michaelni has quit [*.net *.split]
jess has quit [*.net *.split]
SuperFashi has quit [*.net *.split]
nitroxis has quit [*.net *.split]
sfan5 has quit [*.net *.split]
Gramner has quit [*.net *.split]
Guest7164 has quit [*.net *.split]
wbs has quit [*.net *.split]
ChanServ has quit [*.net *.split]
System_Error has quit [*.net *.split]
HarshK23 has quit [*.net *.split]
mateo` has quit [*.net *.split]
Lynne has quit [*.net *.split]
averne has quit [*.net *.split]
signalhunter has quit [*.net *.split]
gnafu has quit [*.net *.split]
adema has quit [*.net *.split]
rajivharlalka1 has quit [*.net *.split]
jkhsjdhjs has quit [*.net *.split]
Son_Goku has quit [*.net *.split]
xvaclav has quit [*.net *.split]
RT|AO_ has quit [*.net *.split]
deus0ww_ has quit [*.net *.split]
BradleyS has quit [*.net *.split]
Daemon404 has quit [*.net *.split]
rom1v has quit [*.net *.split]
graphitemaster has quit [*.net *.split]
jkqxz has quit [*.net *.split]
skinkie has quit [*.net *.split]
marcj- has quit [*.net *.split]
kekePower has quit [*.net *.split]
_whitelogger__ has quit [*.net *.split]
^Neo has quit [*.net *.split]
arch1t3cht has quit [*.net *.split]
rvalue has quit [*.net *.split]
Marth64 has quit [*.net *.split]
MisterMinister has quit [*.net *.split]
kasper93 has quit [*.net *.split]
DauntlessOne has quit [*.net *.split]
compn has quit [*.net *.split]
darkdrgn2k has quit [*.net *.split]
sudden has quit [*.net *.split]
ocrete has quit [*.net *.split]
stazthebox has quit [*.net *.split]
aaabbb has quit [*.net *.split]
natto has quit [*.net *.split]
AMM has quit [*.net *.split]
courmisch_ has quit [*.net *.split]
novaphoenix has quit [*.net *.split]
mkver has quit [*.net *.split]
Martchus has quit [*.net *.split]
secondcreek has quit [*.net *.split]
beastd has quit [*.net *.split]
philipl has quit [*.net *.split]
klaxa has quit [*.net *.split]
quietvoid has quit [*.net *.split]
rix has quit [*.net *.split]
Venemo has quit [*.net *.split]
funman has quit [*.net *.split]
CoreX has quit [*.net *.split]
Manouchehri has quit [*.net *.split]
TD-Linux has quit [*.net *.split]
Rodn3y has quit [*.net *.split]
guest332 has quit [*.net *.split]
lexano has quit [*.net *.split]
sm2n has quit [*.net *.split]
psilokos has quit [*.net *.split]
witchymary has quit [*.net *.split]
Warcop has quit [*.net *.split]
Teukka has quit [*.net *.split]
BtbN has quit [*.net *.split]
any1 has quit [*.net *.split]
llrcombs has quit [*.net *.split]
pv has quit [*.net *.split]
s55 has quit [*.net *.split]
vjaquez has quit [*.net *.split]
names_are_hard has quit [*.net *.split]
j-b has quit [*.net *.split]
johnny__ has quit [*.net *.split]
markh has quit [*.net *.split]
ramiro has quit [*.net *.split]
JEEB has quit [*.net *.split]
pross has quit [*.net *.split]
BBB has quit [*.net *.split]
andrewrk has quit [*.net *.split]
KyleSiefring has quit [*.net *.split]
chainik has quit [*.net *.split]
unlord has quit [*.net *.split]
uau has quit [*.net *.split]
keith has quit [*.net *.split]
thardin has quit [*.net *.split]
kwizart has quit [*.net *.split]
rodgort has quit [*.net *.split]
bencoh has quit [*.net *.split]
kurufu has quit [*.net *.split]
dlb76 has quit [*.net *.split]
Arsen has quit [*.net *.split]
blb has quit [*.net *.split]
paulk-bis has quit [*.net *.split]
microchip_ has quit [*.net *.split]
av500 has quit [*.net *.split]
kmikita has quit [*.net *.split]
another| has quit [*.net *.split]
rossy has quit [*.net *.split]
zip6como has quit [*.net *.split]
acryo has quit [*.net *.split]
q66 has quit [*.net *.split]
LaserEyess has quit [*.net *.split]
bpmedley has quit [*.net *.split]
jdek has quit [*.net *.split]
ringo has quit [*.net *.split]
jessidhia has quit [*.net *.split]
nto has quit [*.net *.split]
Fenrir has quit [*.net *.split]
jamrial has quit [*.net *.split]
Traneptora has quit [*.net *.split]
Sebastinas has quit [*.net *.split]
Sirtsu55 has quit [*.net *.split]
pengvado has quit [*.net *.split]
bbbccc has quit [*.net *.split]
frankplow has quit [*.net *.split]
Labnan has quit [*.net *.split]
kurosu has quit [*.net *.split]
sumoon has quit [*.net *.split]
cosminaught has quit [*.net *.split]
auri has quit [*.net *.split]
englishm has quit [*.net *.split]
APic has quit [*.net *.split]
termos has quit [*.net *.split]
mindfreeze has quit [*.net *.split]
jdarnley has quit [*.net *.split]
elenril has quit [*.net *.split]
psykose has quit [*.net *.split]
pal has quit [*.net *.split]
c_14 has quit [*.net *.split]
haxar has quit [*.net *.split]
Mirarora has quit [Quit: Mirarora encountered a fatal error and needs to close]
ringo has joined #ffmpeg-devel
jdarnley has joined #ffmpeg-devel
haxar has joined #ffmpeg-devel
AMM has joined #ffmpeg-devel
mindfreeze has joined #ffmpeg-devel
Fenrir has joined #ffmpeg-devel
nto has joined #ffmpeg-devel
jessidhia has joined #ffmpeg-devel
termos has joined #ffmpeg-devel
c_14 has joined #ffmpeg-devel
chainik has joined #ffmpeg-devel
andrewrk has joined #ffmpeg-devel
englishm has joined #ffmpeg-devel
KyleSiefring has joined #ffmpeg-devel
APic has joined #ffmpeg-devel
ChanServ has joined #ffmpeg-devel
nitroxis has joined #ffmpeg-devel
jdek has joined #ffmpeg-devel
BBB has joined #ffmpeg-devel
bpmedley has joined #ffmpeg-devel
LaserEyess has joined #ffmpeg-devel
Venemo has joined #ffmpeg-devel
auri has joined #ffmpeg-devel
funman has joined #ffmpeg-devel
CoreX has joined #ffmpeg-devel
cosminaught has joined #ffmpeg-devel
q66 has joined #ffmpeg-devel
pross has joined #ffmpeg-devel
j-b has joined #ffmpeg-devel
natto has joined #ffmpeg-devel
pal has joined #ffmpeg-devel
names_are_hard has joined #ffmpeg-devel
vjaquez has joined #ffmpeg-devel
acryo has joined #ffmpeg-devel
psilokos has joined #ffmpeg-devel
sm2n has joined #ffmpeg-devel
kurosu has joined #ffmpeg-devel
s55 has joined #ffmpeg-devel
pv has joined #ffmpeg-devel
Labnan has joined #ffmpeg-devel
frankplow has joined #ffmpeg-devel
bbbccc has joined #ffmpeg-devel
pengvado has joined #ffmpeg-devel
llrcombs has joined #ffmpeg-devel
any1 has joined #ffmpeg-devel
rix has joined #ffmpeg-devel
lexano has joined #ffmpeg-devel
aaabbb has joined #ffmpeg-devel
quietvoid has joined #ffmpeg-devel
zip6como has joined #ffmpeg-devel
sumoon has joined #ffmpeg-devel
rossy has joined #ffmpeg-devel
stazthebox has joined #ffmpeg-devel
klaxa has joined #ffmpeg-devel
graphitemaster has joined #ffmpeg-devel
jkqxz has joined #ffmpeg-devel
marcj- has joined #ffmpeg-devel
guest332 has joined #ffmpeg-devel
Rodn3y has joined #ffmpeg-devel
skinkie has joined #ffmpeg-devel
TD-Linux has joined #ffmpeg-devel
ocrete has joined #ffmpeg-devel
Manouchehri has joined #ffmpeg-devel
kmikita has joined #ffmpeg-devel
another| has joined #ffmpeg-devel
sudden has joined #ffmpeg-devel
BtbN has joined #ffmpeg-devel
darkdrgn2k has joined #ffmpeg-devel
JEEB has joined #ffmpeg-devel
Sirtsu55 has joined #ffmpeg-devel
microchip_ has joined #ffmpeg-devel
av500 has joined #ffmpeg-devel
Teukka has joined #ffmpeg-devel
compn has joined #ffmpeg-devel
DauntlessOne has joined #ffmpeg-devel
philipl has joined #ffmpeg-devel
psykose has joined #ffmpeg-devel
ramiro has joined #ffmpeg-devel
Daemon404 has joined #ffmpeg-devel
rom1v has joined #ffmpeg-devel
Sebastinas has joined #ffmpeg-devel
kasper93 has joined #ffmpeg-devel
BradleyS has joined #ffmpeg-devel
markh has joined #ffmpeg-devel
MisterMinister has joined #ffmpeg-devel
Warcop has joined #ffmpeg-devel
beastd has joined #ffmpeg-devel
johnny__ has joined #ffmpeg-devel
paulk-bis has joined #ffmpeg-devel
elenril has joined #ffmpeg-devel
Marth64 has joined #ffmpeg-devel
deus0ww_ has joined #ffmpeg-devel
rvalue has joined #ffmpeg-devel
secondcreek has joined #ffmpeg-devel
arch1t3cht has joined #ffmpeg-devel
System_Error has joined #ffmpeg-devel
Martchus has joined #ffmpeg-devel
Traneptora has joined #ffmpeg-devel
mkver has joined #ffmpeg-devel
^Neo has joined #ffmpeg-devel
novaphoenix has joined #ffmpeg-devel
jamrial has joined #ffmpeg-devel
blb has joined #ffmpeg-devel
witchymary has joined #ffmpeg-devel
courmisch_ has joined #ffmpeg-devel
_whitelogger__ has joined #ffmpeg-devel
thilo has joined #ffmpeg-devel
kekePower has joined #ffmpeg-devel
wyatt8740 has joined #ffmpeg-devel
bilboed has joined #ffmpeg-devel
rodeo has joined #ffmpeg-devel
michaelni has joined #ffmpeg-devel
jess has joined #ffmpeg-devel
Guest7164 has joined #ffmpeg-devel
wbs has joined #ffmpeg-devel
SuperFashi has joined #ffmpeg-devel
Gramner has joined #ffmpeg-devel
sfan5 has joined #ffmpeg-devel
Mirarora has joined #ffmpeg-devel
Manouchehri has quit [*.net *.split]
TD-Linux has quit [*.net *.split]
Rodn3y has quit [*.net *.split]
guest332 has quit [*.net *.split]
lexano has quit [*.net *.split]
sm2n has quit [*.net *.split]
psilokos has quit [*.net *.split]
Rodn3y has joined #ffmpeg-devel
guest332 has joined #ffmpeg-devel
Manouchehri has joined #ffmpeg-devel
TD-Linux has joined #ffmpeg-devel
lexano has joined #ffmpeg-devel
psilokos has joined #ffmpeg-devel
sm2n has joined #ffmpeg-devel
Manouchehri has quit [Max SendQ exceeded]
Arsen has joined #ffmpeg-devel
llyyr has joined #ffmpeg-devel
HarshK23 has joined #ffmpeg-devel
mateo` has joined #ffmpeg-devel
Lynne has joined #ffmpeg-devel
averne has joined #ffmpeg-devel
signalhunter has joined #ffmpeg-devel
adema has joined #ffmpeg-devel
jkhsjdhjs has joined #ffmpeg-devel
rajivharlalka1 has joined #ffmpeg-devel
gnafu has joined #ffmpeg-devel
Son_Goku has joined #ffmpeg-devel
xvaclav has joined #ffmpeg-devel
RT|AO_ has joined #ffmpeg-devel
blb has quit [*.net *.split]
paulk-bis has quit [*.net *.split]
av500 has quit [*.net *.split]
microchip_ has quit [*.net *.split]
kmikita has quit [*.net *.split]
another| has quit [*.net *.split]
zip6como has quit [*.net *.split]
rossy has quit [*.net *.split]
acryo has quit [*.net *.split]
q66 has quit [*.net *.split]
LaserEyess has quit [*.net *.split]
bpmedley has quit [*.net *.split]
jdek has quit [*.net *.split]
ringo has quit [*.net *.split]
jessidhia has quit [*.net *.split]
Fenrir has quit [*.net *.split]
nto has quit [*.net *.split]
blb has joined #ffmpeg-devel
paulk-bis has joined #ffmpeg-devel
microchip_ has joined #ffmpeg-devel
av500 has joined #ffmpeg-devel
another| has joined #ffmpeg-devel
kmikita has joined #ffmpeg-devel
rossy has joined #ffmpeg-devel
zip6como has joined #ffmpeg-devel
acryo has joined #ffmpeg-devel
LaserEyess has joined #ffmpeg-devel
q66 has joined #ffmpeg-devel
bpmedley has joined #ffmpeg-devel
nto has joined #ffmpeg-devel
jdek has joined #ffmpeg-devel
jessidhia has joined #ffmpeg-devel
ringo has joined #ffmpeg-devel
Fenrir has joined #ffmpeg-devel
unlord has joined #ffmpeg-devel
keith has joined #ffmpeg-devel
uau has joined #ffmpeg-devel
thardin has joined #ffmpeg-devel
kwizart has joined #ffmpeg-devel
bencoh has joined #ffmpeg-devel
rodgort has joined #ffmpeg-devel
kurufu has joined #ffmpeg-devel
dlb76 has joined #ffmpeg-devel
dlb76 has quit [Max SendQ exceeded]
jamrial has quit [*.net *.split]
Traneptora has quit [*.net *.split]
Sebastinas has quit [*.net *.split]
Sirtsu55 has quit [*.net *.split]
pengvado has quit [*.net *.split]
bbbccc has quit [*.net *.split]
frankplow has quit [*.net *.split]
Labnan has quit [*.net *.split]
kurosu has quit [*.net *.split]
sumoon has quit [*.net *.split]
cosminaught has quit [*.net *.split]
auri has quit [*.net *.split]
englishm has quit [*.net *.split]
APic has quit [*.net *.split]
termos has quit [*.net *.split]
mindfreeze has quit [*.net *.split]
jdarnley has quit [*.net *.split]
englishm has joined #ffmpeg-devel
Traneptora has joined #ffmpeg-devel
sumoon has joined #ffmpeg-devel
Sirtsu55 has joined #ffmpeg-devel
pengvado has joined #ffmpeg-devel
frankplow has joined #ffmpeg-devel
bbbccc has joined #ffmpeg-devel
auri has joined #ffmpeg-devel
jamrial has joined #ffmpeg-devel
Sebastinas has joined #ffmpeg-devel
Labnan has joined #ffmpeg-devel
APic has joined #ffmpeg-devel
cosminaught has joined #ffmpeg-devel
kurosu has joined #ffmpeg-devel
jdarnley has joined #ffmpeg-devel
mindfreeze has joined #ffmpeg-devel
termos has joined #ffmpeg-devel
Arsen has quit [*.net *.split]
johnny__ has quit [*.net *.split]
markh has quit [*.net *.split]
ramiro has quit [*.net *.split]
JEEB has quit [*.net *.split]
pross has quit [*.net *.split]
BBB has quit [*.net *.split]
andrewrk has quit [*.net *.split]
KyleSiefring has quit [*.net *.split]
chainik has quit [*.net *.split]
rossy has quit [Ping timeout: 244 seconds]
Manouchehri has joined #ffmpeg-devel
ramiro has joined #ffmpeg-devel
markh has joined #ffmpeg-devel
johnny__ has joined #ffmpeg-devel
Arsen has joined #ffmpeg-devel
JEEB has joined #ffmpeg-devel
BBB has joined #ffmpeg-devel
pross has joined #ffmpeg-devel
andrewrk has joined #ffmpeg-devel
KyleSiefring has joined #ffmpeg-devel
chainik has joined #ffmpeg-devel
witchymary has quit [*.net *.split]
Warcop has quit [*.net *.split]
Teukka has quit [*.net *.split]
BtbN has quit [*.net *.split]
any1 has quit [*.net *.split]
llrcombs has quit [*.net *.split]
pv has quit [*.net *.split]
s55 has quit [*.net *.split]
vjaquez has quit [*.net *.split]
names_are_hard has quit [*.net *.split]
j-b has quit [*.net *.split]
courmisch_ has quit [Excess Flood]
mkver has quit [Remote host closed the connection]
courmisch has joined #ffmpeg-devel
mkver has joined #ffmpeg-devel
witchymary has joined #ffmpeg-devel
j-b has joined #ffmpeg-devel
Teukka has joined #ffmpeg-devel
any1 has joined #ffmpeg-devel
llrcombs has joined #ffmpeg-devel
pv has joined #ffmpeg-devel
names_are_hard has joined #ffmpeg-devel
Warcop has joined #ffmpeg-devel
BtbN has joined #ffmpeg-devel
s55 has joined #ffmpeg-devel
vjaquez has joined #ffmpeg-devel
dlb76 has joined #ffmpeg-devel
Arsen has quit [Ping timeout: 260 seconds]
Arsen has joined #ffmpeg-devel
rossy has joined #ffmpeg-devel
System_Error has quit [*.net *.split]
dlb76 has quit [Read error: Connection reset by peer]
System_Error has joined #ffmpeg-devel
Manouchehri has quit [*.net *.split]
deus0ww_ has quit [*.net *.split]
BradleyS has quit [*.net *.split]
Daemon404 has quit [*.net *.split]
rom1v has quit [*.net *.split]
graphitemaster has quit [*.net *.split]
jkqxz has quit [*.net *.split]
skinkie has quit [*.net *.split]
marcj- has quit [*.net *.split]
Manouchehri has joined #ffmpeg-devel
rom1v has joined #ffmpeg-devel
Daemon404 has joined #ffmpeg-devel
graphitemaster has joined #ffmpeg-devel
jkqxz has joined #ffmpeg-devel
skinkie has joined #ffmpeg-devel
BradleyS has joined #ffmpeg-devel
marcj- has joined #ffmpeg-devel
deus0ww_ has joined #ffmpeg-devel
dlb76 has joined #ffmpeg-devel
dlb76 has quit [*.net *.split]
elenril has quit [*.net *.split]
psykose has quit [*.net *.split]
pal has quit [*.net *.split]
c_14 has quit [*.net *.split]
haxar has quit [*.net *.split]
Manouchehri has quit [Ping timeout: 248 seconds]
haxar has joined #ffmpeg-devel
elenril has joined #ffmpeg-devel
psykose has joined #ffmpeg-devel
dlb76 has joined #ffmpeg-devel
pal has joined #ffmpeg-devel
c_14 has joined #ffmpeg-devel
Manouchehri has joined #ffmpeg-devel
Manouchehri has quit [*.net *.split]
AMM has quit [*.net *.split]
novaphoenix has quit [*.net *.split]
Martchus has quit [*.net *.split]
secondcreek has quit [*.net *.split]
beastd has quit [*.net *.split]
philipl has quit [*.net *.split]
klaxa has quit [*.net *.split]
quietvoid has quit [*.net *.split]
rix has quit [*.net *.split]
Venemo has quit [*.net *.split]
funman has quit [*.net *.split]
CoreX has quit [*.net *.split]
novaphoenix has joined #ffmpeg-devel
Manouchehri has joined #ffmpeg-devel
Martchus has joined #ffmpeg-devel
AMM has joined #ffmpeg-devel
secondcreek has joined #ffmpeg-devel
philipl has joined #ffmpeg-devel
beastd has joined #ffmpeg-devel
klaxa has joined #ffmpeg-devel
quietvoid has joined #ffmpeg-devel
rix has joined #ffmpeg-devel
Venemo has joined #ffmpeg-devel
funman has joined #ffmpeg-devel
CoreX has joined #ffmpeg-devel
Arsen has quit [*.net *.split]
mkver has quit [*.net *.split]
_whitelogger__ has quit [*.net *.split]
kekePower has quit [*.net *.split]
^Neo has quit [*.net *.split]
arch1t3cht has quit [*.net *.split]
rvalue has quit [*.net *.split]
Marth64 has quit [*.net *.split]
MisterMinister has quit [*.net *.split]
kasper93 has quit [*.net *.split]
DauntlessOne has quit [*.net *.split]
compn has quit [*.net *.split]
darkdrgn2k has quit [*.net *.split]
sudden has quit [*.net *.split]
ocrete has quit [*.net *.split]
stazthebox has quit [*.net *.split]
aaabbb has quit [*.net *.split]
natto has quit [*.net *.split]
Arsen has joined #ffmpeg-devel
mkver has joined #ffmpeg-devel
kekePower has joined #ffmpeg-devel
_whitelogger__ has joined #ffmpeg-devel
arch1t3cht has joined #ffmpeg-devel
^Neo has joined #ffmpeg-devel
rvalue has joined #ffmpeg-devel
Marth64 has joined #ffmpeg-devel
MisterMinister has joined #ffmpeg-devel
DauntlessOne has joined #ffmpeg-devel
kasper93 has joined #ffmpeg-devel
compn has joined #ffmpeg-devel
darkdrgn2k has joined #ffmpeg-devel
ocrete has joined #ffmpeg-devel
natto has joined #ffmpeg-devel
sudden has joined #ffmpeg-devel
stazthebox has joined #ffmpeg-devel
aaabbb has joined #ffmpeg-devel
compnn has joined #ffmpeg-devel
mkver has quit [Remote host closed the connection]
compn has quit [Remote host closed the connection]
Marth64 has quit [Remote host closed the connection]
Marth64[m] has joined #ffmpeg-devel
mkver has joined #ffmpeg-devel
<kurosu> JEEB: I guess you got it much sooner, but that the conditional conf_win_*_offset in the SPS
Krowl has joined #ffmpeg-devel
_whitelogger__ has quit [Remote host closed the connection]
witchymary has quit [Remote host closed the connection]
witchymary has joined #ffmpeg-devel
_whitelogger_ has joined #ffmpeg-devel
Workl has joined #ffmpeg-devel
Krowl has quit [Ping timeout: 260 seconds]
Krowl has joined #ffmpeg-devel
Workl has quit [Ping timeout: 260 seconds]
MajorBiscuit has joined #ffmpeg-devel
MajorBiscuit has quit [Client Quit]
MajorBiscuit has joined #ffmpeg-devel
wbs has quit [Ping timeout: 252 seconds]
Krowl has quit [Read error: Connection reset by peer]
AMM has quit [Quit: S'on moro]
AMM has joined #ffmpeg-devel
cone-089 has joined #ffmpeg-devel
<cone-089> ffmpeg Rémi Denis-Courmont master:c3051d94a793: lavc/h264dsp: move RISC-V fn pointers to .data.rel.ro
<cone-089> ffmpeg Rémi Denis-Courmont release/7.1:4ea558152f05: lavc/h264dsp: move RISC-V fn pointers to .data.rel.ro
wbs has joined #ffmpeg-devel
MajorBiscuit has quit [Ping timeout: 252 seconds]
iive has joined #ffmpeg-devel
Krowl has joined #ffmpeg-devel
Workl has joined #ffmpeg-devel
Krowl has quit [Ping timeout: 255 seconds]
Krowl has joined #ffmpeg-devel
Workl has quit [Ping timeout: 252 seconds]
<cone-089> ffmpeg Marton Balint master:e9af7b7b5d38: avutil/opt: do no rely on av_d2q returning higher num/den than allowed when parsing rational opts
<cone-089> ffmpeg Marton Balint master:25efe34e6f13: avutil/parseutils: do no rely on av_d2q returning higher num/den than allowed in av_parse_video_rate
<cone-089> ffmpeg Marton Balint master:d884606ce0f4: avutil/rational: never return greater num/den than the maximum allowed in av_d2q
Everything has joined #ffmpeg-devel
Krowl has quit [Read error: Connection reset by peer]
<cone-089> ffmpeg Marth64 master:3ad96243d756: avformat/dvdvideodec: remove unused headers
<cone-089> ffmpeg Marth64 master:94346edbbfef: avformat/dvdvideodec: fix menu PGC number off-by-one in state
<cone-089> ffmpeg Marth64 master:39c662f54125: avformat/dvdvideodec: measure duration of the current menu VOBU in state
<cone-089> ffmpeg Marth64 master:e1ace1d31467: avformat/dvdvideodec: remove "auto" value for -pg option, default to 1
<cone-089> ffmpeg Marth64 master:6bbaa7db49de: avformat/dvdvideodec: move memcpy below missed NAV packet warning
<cone-089> ffmpeg Marth64 master:b38ca20bf254: avformat/dvdvideodec: standardize the NAV packet event signal
<cone-089> ffmpeg Marth64 master:c1e4b6c676c4: avformat/dvdvideodec: enable chapter calculation for menus
<cone-089> ffmpeg Marth64 master:1964faa568c2: avformat/dvdvideodec: simplify dvdvideo_read_packet()
<cone-089> ffmpeg Marth64 master:a1ae66c82737: avformat/dvdvideodec: reset the subdemuxer on discontinuity instead of flushing
<cone-089> ffmpeg Marth64 master:afc152f564fb: avformat/dvdvideodec: check the length of a NAV packet when reading titles
<cone-089> ffmpeg Marth64 master:4a03e95ff4c3: avformat/dvdvideodec: default menu_vts option to 1 and clarify description
<cone-089> ffmpeg Marth64 master:60434b483c54: avformat/dvdvideodec: remove auto value for menu_lu option
<cone-089> ffmpeg Marth64 master:a2c57e27d6bb: avformat/dvdvideodec: open subdemuxer after initializing IFO headers
<cone-089> ffmpeg Marth64 master:3656379d9225: avformat/dvdvideodec: remove unnecessary need_parsing argument
<cone-089> ffmpeg Marth64 master:f2f238c3a485: avformat/dvdvideodec: drop packets with unset PTS or DTS
<cone-089> ffmpeg Marth64 master:0912407b9de4: avformat/dvdvideodec: discard duplicate or partial AC3 samples
<cone-089> ffmpeg Marth64 master:1d55f5484665: avformat/dvdvideodec: don't allow seeking beyond dvdnav reported duration
<names_are_hard> Should idctSparseColPut() check for null pointer before access of dest, or is there some earlier guarantee?
<names_are_hard> Specifically: dest[0] = av_clip_pixel((int)(a0 + b0) >> COL_SHIFT);
<names_are_hard> It's a write through null so is plausibly exploitable on platforms with a mapped 0 page
<BtbN> That's deep within the template system of the idct stuff. A null check should happen much much earlier.
<names_are_hard> Well, I have a sample that seg faults there, so...
<BtbN> So a check is missing somewhere earlier.
<names_are_hard> Why don't we want to check at point of use? That's generally the saner design
<BtbN> Cause that stuff gets called A LOT
IndecisiveTurtle has joined #ffmpeg-devel
<names_are_hard> The cost of a null check is less than the cost of the write you're going to do immediately afterwards...
<names_are_hard> dest is null, and you want to do dest[0] = av_clip_pixel((int)(a0 + b0) >> COL_SHIFT);
<BtbN> The cost of a couple million extra null checks adds up
<names_are_hard> There should be no additional cost
<BtbN> If dest is null there, something went very wrong much earlier
<names_are_hard> You have to get the value of dest in order to write through it
<BtbN> Yes, even just checking for null has a cost
<BtbN> it's neglicible in normal circumstances, but functions called a ton of times per frame are a whole other story
<names_are_hard> But you're already going to deref it in *all* later paths
<names_are_hard> And the memory write cost will dominate, anyway
<BtbN> The entire thing is written with the assumption of intact buffers. If it gets this far with a null buffer, something already went wrong.
<BtbN> So the check has to happen in the place where it's not happening a bazillion times
<names_are_hard> Well, up to you I guess - personally I prefer not to write code that can write through null pointers
<names_are_hard> So, where's the "correct" place to fix this, if not at point of use?
<BtbN> Then you'd have to add thousands and thousands of checks everywhere through assembly, and other hot paths
<BtbN> Well, you are looking at the backtrace, not me
<names_are_hard> To me that sounds like "you'd have to write secure code"
<BtbN> You realize that this is a media decoder?
<names_are_hard> What's the relevance?
<BtbN> Performance matters. And null checks are not free is you mass up enough of them, that all check the same variable for null
<names_are_hard> People own iphones all the time through media decoders, most people believe security matters more
<names_are_hard> Also: I am 99% confident that this check would not impact performance, since you immediately *write through* the pointer in all paths
<BtbN> Go join the rustbros then. Last time they tried to re-invent ffmpeg it was, shocker, slow as hell.
<names_are_hard> Wouldn't that memory write dominate the cost?
<BtbN> No idea what you mean with "memory write dominate the cost"
<BtbN> you are adding potentially millions of null checks to each frame. All checking the same buffer for null
<BtbN> instead of checking it once initially
<names_are_hard> Memory writes are typically more expensive than reads, yes?
<BtbN> Also, that specific function has no way to signal an error anyway
<BtbN> so it'd just crash one step later
<BtbN> Your point being?
<BtbN> checks aren't free
<BtbN> add enough of them, and stuff gets slower
<names_are_hard> If you add a fast read check before a slow write, the cost of the write dominates
<BtbN> And?
<BtbN> The cost of the check is still there. Making the whole thing slower
<names_are_hard> In this code path, the write always occurs
<BtbN> So does the check, making stuff slower.
<names_are_hard> Adding a fast check to avoid *a security bug* feels sensible to me
<BtbN> And there is no good way to act when it's null anyway
<BtbN> Are you trolling or something?
<BtbN> It shouldn't ever get this far if the buffer is NULL
<BtbN> the actual bug is much earlier
<names_are_hard> But it does
<names_are_hard> I have a sample which hits it
<BBB> can you file a bug for the sample please?
<BBB> on trac.ffmpeg.org
<names_are_hard> The obvious fix would be add a null check before use *and* fix the earlier problem
<BBB> BtbN is correct that we do not want a null check
<BBB> this is not debatable and will not be considered
<BtbN> No, that would just shift the crash somewhere else
<BBB> if you don't know how to fix it differently, file a bug and leave us to do our job
<BtbN> it should never ever enter this codepath at all with the data buffer being null
<names_are_hard> BtbN: I very clearly said *and* fix the earlier problem
<BBB> there is no and here. we will *only* fix the problem earlier
<BtbN> By that logic, we'd have to add literal thousands of null checks EVERYWHERE, and yes, that is slow
<names_are_hard> But sure, if you want a reachable write through a null pointer, that's up to you
<BtbN> This is a media code. Performance matters there
<BtbN> It gets called A LOT
<names_are_hard> And security doesn't matter?
<BtbN> even tiny things matter there
<BBB> names_are_hard: https://trac.ffmpeg.org/
<names_are_hard> Yeah, I'll file it
<BBB> thank you
<BtbN> Like I said, at least one person or group tried to re-invent ffmpeg in rust. And found it to be too slow to be useable, cause of all the checks.
<names_are_hard> Currently I don't have the root cause diagnosed, I'm in the middle of a fuzzing run. I don't want to file an incomplete bug and you don't want to read it, so it'll happen later
<BtbN> FFmpeg is as fast as it is because of optimized code like this. And hand-written assembly. That also doesn't do null checks and assumed valid input.
<names_are_hard> Yeah, sure, I get it
<BtbN> If you have a sample that reproducably crashes, you got one whole bug right there.
<names_are_hard> You want to do hyper optimised stuff and don't care about security, it's your choice
<BBB> it is ok to file a sample that crashes
<BtbN> Stuff _is_ checked
<BBB> we get a fair number of them and we try to fix them asap
<BtbN> it just needs to be done in the right place
<BBB> we really care about security
<BtbN> not in the middle of what is effectively a dsp
<BBB> exactly
<BBB> there is design to this stuff. we're not a bunch of newbies here :)
<names_are_hard> Well, this sample relates to the actual feature change I want to make, and I haven't tested that the code is reachable without my changes (logically, it should be, but weirder things have happened)
<BtbN> If the sample crashes vanilla ffmpeg, it's a valid bug all on its own
<BBB> ah, so this is not on git/master?
<BBB> right, that complicates things ... a bit :)
<names_are_hard> It doesn't, but I would guess lossless jpeg shopuld also be able to hit it. Currently unproven, I will investigate, since you (sensibly!) won't take my feature with outstanding crash bugs
<names_are_hard> That's why I asked about where to fix it
<names_are_hard> And was told I was an idiot for even wanting to fix it at the point of use. Good old reliable internet
<BBB> there's a few practical concerns about doing it in the idct
<names_are_hard> Yeah, want to make the change and profile it?
<names_are_hard> Because I bet it isn't noticeable
<BBB> no, we don't want you to profile it
<BBB> it's bad design
<names_are_hard> Checking for null pointer before usage is good design
<BBB> no
<names_are_hard> There are multiple ways to do that
<BBB> second, it means the check has to be reproduced in *every* simd implementation
<BtbN> We won't be adding one random null check in dsp code to work around a bug
<BBB> that is really dumb design
<BtbN> You could argue adding A TON of null checks, but not just one random one
<names_are_hard> *if* you can guarantee that all paths into the func in question already checked for nulls, then you *are* checking for null before usage
<BBB> for (int y = 0; y < h; y++) { for (int x = 0; x < w; x++) { idct( -- do NULL check here? --); } }
<BBB> or
<BBB> do null chck here; for (int y = 0; y < h; y++) { for (int x = 0; x < w; x++) { idct(); } }
<BBB> which is better design
<BtbN> static null checks would be interesting, but I don't think C can offer that
<BBB> names_are_hard: would you like your patch to be accepted in this project?
<BBB> names_are_hard: if the answer is yes, then my suggestion is to not add a null check in a simd function
<names_are_hard> I have never suggested I will be adding that check
<BBB> good :)
<BBB> second, we'd want a way to reproduce anyway
<names_are_hard> I am going to do the absolute minimum of effort to meet what I'm told is required
<names_are_hard> I'm trying to make a 6 line change to improve support for a existing supported file format, and it's taken me over a month so far
<names_are_hard> This isn't an easy project to work with
<names_are_hard> (which is what I expected: it's a large, complex project)
<BBB> I don't know how feasible this suggestion is, but it's usually easier to get help if you show code or something like that
<BtbN> You can post patches as RFC, yeah
<BtbN> specially if you aren't sure about stuff someone who is familiar with the code could probably answer near instantly
<names_are_hard> I posted patches, I was told I needed to fuzz inputs to test code before they could be accepted
<names_are_hard> And it took several weeks to get replies on the list
<BtbN> We don't have that requirement. Fuzzing every patch would be insane
<BtbN> well, it seems like he was right, and you found one?
<BtbN> So post it as an answer, and ask for advice
<BtbN> With the sample ideally, if it's not too large/legally problematic
<names_are_hard> I don't yet know if this is sample demonstrates a bug with my changes, or with earlier LJ92 code, or with something else
<BtbN> Well, there's people who might. But if you don't share it and what you found, you won't find out
<names_are_hard> I will find out, because I will diagnose it
<names_are_hard> I'm an experienced C dev with a lot of experience with fuzzers
<BtbN> It's definitely a nieche thing to work on. So it's normal that there's no huge response
<names_are_hard> I'd rather understand the sample before posting it (maybe it's a mistake, or maybe it's a serious vuln; in either case you don't want me posting it to a public list)
<BtbN> If it doesn't crash with vanilla ffmpeg, I see no reason not to share it publicly
<names_are_hard> There's a good reason it might not
<names_are_hard> I'm forcing the header bytes in the file to be MLV format, and vanilla doesn't parse LJ92 compressed MLV (that's what my changes are)
<BtbN> Yeah, so that's absolutely safe to share then
<names_are_hard> No, it isn't
<names_are_hard> The underlying bug may be in LJ92 parsing, which other files can hit
<names_are_hard> But vanilla won't get to those paths with MLV, without my changes
<names_are_hard> The ideal testcase would be LJ92 jpeg
<names_are_hard> Assuming it's not a bug with my changes
<BtbN> Send the sample privately then and refer to it.
<BtbN> Bumping your head against a wall for a long time seems just needlessly frustrating
<names_are_hard> I'm not doing that
<names_are_hard> I was asking where the right place to fix the null pointer deref was. Which you have answered, even though I find the answer surprising
<BtbN> You fix it as early as possible, yeah
<BtbN> not in the middle of ultra-hot code
<BtbN> That stuff is often benchmarked in "cpu cycle count"
<names_are_hard> Or, crazy idea: fix it in both places if the profiler says you can afford it
<BtbN> so of course extra checks will be moved out of it
<BtbN> Again, by that logic, we'd need to add literal thousands of tens of thousands of checks everywhere. Which then would hurt performance significancly.
<names_are_hard> Would it though? Have you measured this?
<names_are_hard> Anyway, really, I don't care about that
<BtbN> Yes, those functions are extensively benchmarked all the time
<names_are_hard> With the checks?
<BtbN> By counting single CPU cycles
<BtbN> Also, most of those functions have mulitple implementations. The C one is just the basic fallback
<BtbN> there's potentially dozens of handwritten assembly variants of them
<names_are_hard> It's fine, I value correct core more than fast code, you don't - but it's your code so do whatever
<BtbN> You simply don't realize the magnitudes here
<BtbN> this stuff is called A LOT
<names_are_hard> Sure, call me an idiot again, that'll help
System_Error has quit [Ping timeout: 260 seconds]
<BtbN> No idea where you are reading anyone calling you an idiot here
<names_are_hard> I'm saying *there is a tradeoff*
<BtbN> And I'm saying you are hugely underestimating the magnitude of that tradeoff
<names_are_hard> No
<names_are_hard> I'm valuing correctness more than performance, compared to you
<names_are_hard> Which is fine! It's allowed to choose anywhere on the line!
<BtbN> Checking the same pointer for null trillions of times does nothing for correctness
<names_are_hard> I was never asking to do that
<BtbN> You are though, by suggesting to add null checks in the deep middle of dsp code
<names_are_hard> Prove it's never null and the job is done, I don't mind how
<BtbN> You can't prove that nobody will ever write a bug that calls it with an invalid value
<BtbN> The functions are written under the assumption that the caller took all neccesary precautions
<names_are_hard> Which is a trade off for performance at the cost of correctness
<names_are_hard> Because people make mistakes
<BtbN> If you want to write a useable decoder, those are neccessities
<names_are_hard> That's your claim; I don't believe it
<BtbN> It easily means the difference between being comfortably real time capable, or crawling along with a handful of FPS
<names_are_hard> I don't believe this claim
<names_are_hard> It also doesn't matter whether I do or not
<BtbN> Those function can be easily called literally tens of thousands of times or more per frame.
<BtbN> So while one null check might not yet make a huge difference (though you can probably already measure or even see it), adding all of them to make it follow your idea, would grind it to a halt
<names_are_hard> I think you're wrong
<BtbN> And you base that on what?
<names_are_hard> Years of experience
<names_are_hard> I'm not saying I'm confident, I'm just expressing my opinion
<BtbN> In dealing with media processing?
<names_are_hard> Here's how to prove me wrong: add the null checks and profile it
<names_are_hard> I don't care enough to bother, it's not my code
<BtbN> I'm not gonna waste potentially multiple days of my time to prove a point.
<names_are_hard> Sure, that's reasonable
<BtbN> I'd also have to learn assembly first
<names_are_hard> This is a C function
<BtbN> You are still not getting the point
<BtbN> It's not about adding that one random null check
<names_are_hard> I never said it was
<BtbN> You just said "this is a C function".
<names_are_hard> It seems to me you're arguing against a point I never made?
<BtbN> I'm saying that doing null and range checks in dsp code is slow. Since it's called a hell of a lot of times per frame.
<names_are_hard> And I said this was a C function because you said you'd have to learn asm; you would not, for profiling this one specific change. If you want to profile more, sure, maybe you have to learn more. That's up to you
<BtbN> You still don't get it. It's not about this one random null check.
<BtbN> It's about the whole principle of performing checks in this kind of code
<names_are_hard> I have never, and am not at this time, saying it is about a single null check
<BtbN> Are you trolling? You just contradicted yourself within two messages oO
<names_are_hard> Sorry, I don't understand what you mean
<another|> names_are_hard: Then what are you saying? It's about ALL of the check that would need to be addede?
<names_are_hard> No, BtbN is saying it's about all checks. But checks I'm not talking about
<another|> Then what _are_ you talking about?
<BradleyS> checking the incorrect assumptions in this argument is about as expensive as checking null in dsp code
<BtbN> You just said "It's just about this one check" and "I have never said it's about a single null check" back to back. So what is it?
<another|> BradleyS: lul
<names_are_hard> Where did I say "It's just about this one check"?
<BtbN> The literal message before
<names_are_hard> What's the timestamp?
<BtbN> The literal same minute
<another|> BtbN: I don't see it either
<BtbN> "And I said this was a C function because you said you'd have to learn asm; you would not, for profiling this one specific change."
<names_are_hard> Thanks. I'm not sure how you're interpreting that, but quoting me saying something else didn't help me understand
<BBB> why are we still discussing this :-/
<names_are_hard> Hell if I know
<BtbN> I've told you repeatedly that it's not about one singular null check
<BBB> it's ok to share the sample. really, it is
<names_are_hard> Yeah, I will, that's not changed
<BBB> point to the github repo (or whatever) if you can't repro on git/master
<BtbN> One single null check is going to be hard to measure. But adding one random null check to work around an issue elsewhere is, again, just silly and not going to happen.
<BBB> and if there is a bug in upstream lj92 that is not accessible through this format (yet) but is-still-a-bug, then it's ok
<another|> names_are_hard: the change in C would have to be replicated across several asm implementations
<names_are_hard> Do you have existing lossless jpeg samples? That would save me some time
<names_are_hard> I've got FATE working locally so I did the sample sync step
<BBB> fate-suite//jpegls/* has a bunch of files in it
<BBB> they are lossless jpeg?
<names_are_hard> Should be, thanks
<BBB> make fate-suite-rsync in your git repo to download it
<BBB> make sure you have the fate samples path set
<BBB> (configure --samples=/path/to/samples)
<names_are_hard> It's late here, I'll kill this fuzz run, roll back to vanilla and try that on the jpegs
<BBB> sounds good, tnx
System_Error has joined #ffmpeg-devel
mkver has quit [Ping timeout: 276 seconds]
<elenril> >23:37 <names_are_hard> Why don't we want to check at point of use? That's generally the saner design
<elenril> I disagree about that
<elenril> and not even because of any perofrmance concerns
<names_are_hard> I could easily be biased, my background involves writing fairly paranoid code
<elenril> overzealous do-not-crash checks hid ebugs
<BtbN> specially in a function that has no way to signal error
<BtbN> it'd just create even more invalid state
<names_are_hard> I suppose the middle ground would be something like ASSERT(some_ptr != NULL), you don't pay any cost on non-debug builds
<elenril> as BtbN said, if you get there with a NULL buffer, something went wrong much, much earlier
<elenril> the right solution is to find where and fix it there
<names_are_hard> Sure, I agree with that - but don't you want to find that?
<elenril> of course
<BtbN> And how would hiding the crash help with that?
<BtbN> You don't even get a backtrace then, just potentially random runtime behaviour
<elenril> my point is just that sprinkling random checks in random places does not address the issues, it just hides it
<names_are_hard> Why are you assuming I want to hide a crash?
<elenril> because that's what you said above
<names_are_hard> Did I?
<elenril> at least that's how multiple people here read it
<names_are_hard> You can make ASSERT do whatever you want. I was arguing for checking null pointers before usage; what you do if the check fails I didn't give an opinion on
MajorBiscuit has joined #ffmpeg-devel
<names_are_hard> And of course; writing through a null pointer may not crash. Which is my real point. And what your code does currently
<BtbN> They are checked before usage. Just not as granular as you are asking for here.
<names_are_hard> They're *sometimes* checked before usage, but clearly not always
cone-089 has quit [Quit: transmission timeout]
Everything has quit [Quit: leaving]
MajorBiscuit has quit [Quit: WeeChat 4.4.3]