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 has been released! | Please read ffmpeg.org/developer.html#Code-of-conduct
thilo has quit [Ping timeout: 260 seconds]
thilo has joined #ffmpeg-devel
paulk has quit [Ping timeout: 260 seconds]
paulk has joined #ffmpeg-devel
paulk has joined #ffmpeg-devel
paulk has quit [Changing host]
SystemError has quit [Ping timeout: 260 seconds]
SystemError has joined #ffmpeg-devel
iive has quit [Quit: They came for me...]
TheSashmo has quit [Quit: Leaving...]
SystemError has quit [Remote host closed the connection]
TheSashmo has joined #ffmpeg-devel
TheSashmo has quit [Remote host closed the connection]
TheSashmo has joined #ffmpeg-devel
System_Error has joined #ffmpeg-devel
Martchus_ has quit [Ping timeout: 268 seconds]
TheSashm_ has joined #ffmpeg-devel
TheSashm_ has quit [Remote host closed the connection]
TheSashmo has quit [Read error: Connection reset by peer]
<JEEB>
also I love how INT32_MAX is just written 0x7FFFFFFF there
<JEEB>
looking at read_fps, which breaks when it finds a too large value, read_int just goes on :V
MrZeus has quit [Ping timeout: 260 seconds]
<JEEB>
yea, it's the same check but for INT64_MAX instead (-9) / 10
<JEEB>
but yea, since this function has a separate error var and the function is clearly is ignoring anything not between '0' and '9', it clearly was not meant to output negative numbers :D
<JEEB>
so fixing that (INT32_MAX - 9) / 10 thing is probably the correct way to handle it
<JEEB>
(also while I was checking the git blame, that code had changed surprisingly little since being first merged in 2008)
<kasper93>
how does negative sample rate make sense?
<JEEB>
it doesn't. and the function is clearly not made to parse negative values since it only continues for [0,9]
<JEEB>
it clearly has a check for a too large value (I have no idea if `result > (INT32_MAX - 9) / 10` is actually correct, but if it is - it would just be enough to stick a break there in addition to the *error = -1; (something something why isn't this just llrint or something?)
<JEEB>
and yea, if the largest value is 9 and you do a 10x, then I guess that checks the value? it just doesn't stop at it at the moment.
<JEEB>
thank goodness, there's some samples for this forsaken format in FATE apparently :D
<JEEB>
> 1996 Eidos plc.
<JEEB>
fun
<JEEB>
anyways, the codec tags seem to be something like 0x007C or 0x0082 so nowhere close to int32 levels
<JEEB>
(it's possible this function needs to just skip until the end of numbers instead, but ┐(´д｀)┌ with valid files in FATE this seems to be working.
<JEEB>
&41
Livio has joined #ffmpeg-devel
<cone-505>
ffmpeg Marton Balint master:77fc047bd91e: avfilter/vsrc_testsrc: do not round down width and height for color src
<cone-505>
ffmpeg Marton Balint master:a69a0b689c3c: avfilter/blend: put slice parameters to a single struct
<cone-505>
ffmpeg Marton Balint master:64330e365b97: avfilter/blend: use a per-thread AVExpr
<kasper93>
JEEB: yep, alternative would we to just read error value
<kasper93>
but still should return AVERROR_INVALIDDATA
<kasper93>
now you read part of the value and saturate it, while it also should just reject those invalid values
<JEEB>
yea, in theory you should just make that stuff error out etc, but the saturation check was already there for the other stuff so we are just fixing that funky logic from 2008. making it so that we don't have to have N spots where we have to check for the result, but just not returning too large values to begin with.
<JEEB>
basically I care enough to figure out that the function was never supposed to give out negative values (even has the saturation check there from original commit), but then I don't care enough to start a full rewrite :P
<kasper93>
the function cleary sets the error flag
<kasper93>
the logic is correct, not correct is not checking the error flag
<kasper93>
but w/e I don't care how it is fixed
<kasper93>
just stupid values will likely break something further
<JEEB>
well then you have read_fps which doesn't even set the error flag
<JEEB>
unless it's a zero in num
<JEEB>
and yes, it seems to just expect that rpl_read_header can just keep on doing stuff and then at the end it once checks error
<JEEB>
which is completely against the whole idea of early exit
<JEEB>
so the author originally assumed that the functions would be OK to just be utilized, and that checking once at the end was supposedly OK (classic)
Livio has quit [Ping timeout: 268 seconds]
Krowl has quit [Read error: Connection reset by peer]
TheSashmo has quit [Ping timeout: 268 seconds]
kasper93_ has joined #ffmpeg-devel
kasper93 has quit [Ping timeout: 260 seconds]
b50d has quit [Remote host closed the connection]
TheSashmo 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
haihao has quit [Ping timeout: 252 seconds]
haihao has joined #ffmpeg-devel
feiwan12 has quit [Ping timeout: 260 seconds]
feiwan12 has joined #ffmpeg-devel
kasper93_ is now known as kasper93
MrZeus__ has joined #ffmpeg-devel
MrZeus has joined #ffmpeg-devel
MrZeus_ has quit [Ping timeout: 264 seconds]
MrZeus__ has quit [Ping timeout: 252 seconds]
cone-505 has quit [Quit: transmission timeout]
MrZeus_ has joined #ffmpeg-devel
MrZeus__ has joined #ffmpeg-devel
MrZeus has quit [Ping timeout: 252 seconds]
MrZeus_ has quit [Ping timeout: 252 seconds]
MrZeus has joined #ffmpeg-devel
MrZeus__ has quit [Ping timeout: 252 seconds]
ccawley2011 has quit [Read error: Connection reset by peer]