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
c1480 has quit [Ping timeout: 268 seconds]
thilo has quit [Ping timeout: 256 seconds]
thilo has joined #ffmpeg-devel
aaabbb has joined #ffmpeg-devel
IndecisiveTurtle has quit [Ping timeout: 256 seconds]
<Lynne>
wbs: patch sent, untested, but I took a look over it and it should be fine
<Lynne>
or would you rather see it removed as well? I have no opinion
<Lynne>
also, look who figured out self-hosting an email
<Lynne>
this took a number of hours on and off trying to get postfix, dovecot, cyrus and courier to cooperate, in the end, I just scrapped everything and went with stalwart
wellsakus has quit [Ping timeout: 255 seconds]
rvalue has quit [Read error: Connection reset by peer]
rvalue has joined #ffmpeg-devel
ramiro has quit [Ping timeout: 264 seconds]
sepro8 has joined #ffmpeg-devel
ramiro has joined #ffmpeg-devel
sepro has quit [Ping timeout: 268 seconds]
sepro8 is now known as sepro
sepro has quit [Ping timeout: 268 seconds]
ramiro has quit [Ping timeout: 268 seconds]
sepro has joined #ffmpeg-devel
ramiro has joined #ffmpeg-devel
MisterMinister has quit [Ping timeout: 246 seconds]
sepro has quit [Ping timeout: 256 seconds]
Teukka has quit [Read error: Connection reset by peer]
sepro has joined #ffmpeg-devel
Teukka has joined #ffmpeg-devel
Teukka has quit [Changing host]
Teukka has joined #ffmpeg-devel
cone-448 has joined #ffmpeg-devel
<cone-448>
ffmpeg Haihao Xiang master:0bdf71ada71c: lavc/vaapi_encode_av1: Insert HDR_MDCV metadata if have
SystemError has quit [Remote host closed the connection]
SystemError has joined #ffmpeg-devel
ramiro has joined #ffmpeg-devel
<cone-448>
ffmpeg Ramiro Polla master:250c0defa237: checkasm: add test for fdct
<cone-448>
ffmpeg sunyuechi master:11f689317d66: checkasm: Fix h264chroma test name
<courmisch>
how to calculate CTZ or log2 in a constant-safe manner?
<courmisch>
I mean, we don't have a macro for that, do we?
___nick___ has joined #ffmpeg-devel
kurosu has quit [Quit: Connection closed for inactivity]
j45_ has joined #ffmpeg-devel
ccawley2011 has joined #ffmpeg-devel
j45 has quit [Ping timeout: 260 seconds]
j45_ is now known as j45
j45 has quit [Changing host]
j45 has joined #ffmpeg-devel
aaabbb has quit [Remote host closed the connection]
aaabbb has joined #ffmpeg-devel
wellsakus has joined #ffmpeg-devel
<kasper93>
I've heard that pinging on IRC is super effective. I've sent some patches, trivial fixes, would be cool if someone look at them before they disappear in the ML abyss. (rtp timeout patches are not critical, because I decided to disable this protocol from oss-fuzz for now, too much trouble)
mkver has joined #ffmpeg-devel
cone-448 has quit [Quit: transmission timeout]
<mkver>
haasn: Who said that? You are actually supposed to send all your patches to the ML. There used to be a maintainer exception to this, but you are not the maintainer of libaomenc anyway, so it wouldn't apply either.
<courmisch>
mkver: I think they meant that they want someone reviewing their patches on ML, not to bypass the ML
<mkver>
kasper93: Do your oss-fuzz tickets emanate from fuzzing a tool that uses our libraries or is it from our own fuzzers (in tools/target_*_fuzzer.c)?
Krowl has joined #ffmpeg-devel
<kasper93>
I use your libraries as it is required to build mpv.
jamrial has joined #ffmpeg-devel
antonlyap has quit [Read error: Connection reset by peer]
antonlyap has joined #ffmpeg-devel
<mkver>
courmisch: I couldn't find what he referred to in the (new) IRC archive.
antonlyap1 has joined #ffmpeg-devel
antonlyap has quit [Ping timeout: 252 seconds]
antonlyap1 is now known as antonlyap
antonlyap1 has joined #ffmpeg-devel
antonlyap has quit [Read error: Connection reset by peer]
antonlyap1 is now known as antonlyap
antonlyap1 has joined #ffmpeg-devel
antonlyap has quit [Read error: Connection reset by peer]
antonlyap1 is now known as antonlyap
Krowl has quit [Read error: Connection reset by peer]
HarshK23 has quit [Quit: Connection closed for inactivity]
HarshK23 has joined #ffmpeg-devel
<kasper93>
according to oss-fuzz FAQ, I should be able to add someone on CC to the issues. Do you know how to do that? I don't see anywhere an option for that
<kasper93>
I'd like to forward relevant issues to upstream (ffmpeg)
ccawley2011 has quit [Ping timeout: 246 seconds]
rvalue has quit [Read error: Connection reset by peer]
IndecisiveTurtle has joined #ffmpeg-devel
rvalue has joined #ffmpeg-devel
Krowl has quit [Read error: Connection reset by peer]
<mkver>
jamrial: Does what Paul said about the frame pool and writability make sense to you?
<jamrial>
mkver: not really. but i don't know how ff_null_get_video_buffer() works
Krowl has joined #ffmpeg-devel
<BtbN>
Even the HEVC reference decoder/analyzer just goes "Warning: found NAL unit with nuh_layer_id equal to 1. Ignoring."
<JEEB>
for the bpaste for ffmpeg generated, at least it has the vps_extension_flag, but why is it 2? :D and yea, don't see the scalability mask flag which should be 3 for AuxId, of which alpha is one
<JEEB>
right, yea. so it also used the alpha SEI message. which just defines how the alpha should be interpreted
<JEEB>
anyways, let me grab that macbook...
<JEEB>
ah the FFmpeg default HEVC tag in mp4 bites
Sean_McG has quit [Quit: leaving]
<JEEB>
with AVC Apple supported avc1 but with HEVC they stopped supporting the one that matches it more or less, and only support hvc1
<galad>
isn't hvc1 the one that matches avc1?
<thardin>
TIL melt (and therefore kdenlive) supports GIMP's .xcf format
<galad>
and avc3 the one that matches hev1
<JEEB>
not sure as much if you mention it like that, but in any case QuickTime with patching the identifier doesn't play it :) (although it could be it might require another identifier for multilayer?)
<galad>
Are all the sps and pps in the hvcC atom?
<BtbN>
I can't even find where that stuff is parsed in ffmpeg
<JEEB>
for hevc it's duplicated, once in the decoder and once in CBS (utilized in bsfs [and VVC started using CBS for decoding])
tufei_ has quit [Quit: Leaving]
<BtbN>
Yeah, it's extremely confusing all in all
<BtbN>
The cbs thing seems to parse it
<BtbN>
But the decoder seems to completely ignore it
tufei has joined #ffmpeg-devel
cone-199 has quit [Quit: transmission timeout]
AbleBacon has joined #ffmpeg-devel
MisterMinister has joined #ffmpeg-devel
ccawley2011 has quit [Read error: Connection reset by peer]
ccawley2011 has joined #ffmpeg-devel
ccawley2011 has quit [Read error: Connection reset by peer]
unlord has quit [Ping timeout: 252 seconds]
HarshK23 has quit [Quit: Connection closed for inactivity]
Krowl has quit [Read error: Connection reset by peer]
<courmisch>
err, is it just me or avpriv_find_start_code() is UB?
kurosu has joined #ffmpeg-devel
<courmisch>
p can go up to end + 2, but end + 1 and end + 2 are generally speaking undefined expressions, since they may be beyond object bondaries
<courmisch>
well, yes
<courmisch>
seems there is an implied assumption that end is no less than 3 bytes from the end, but yikes
<mkver>
courmisch: Really? There is a p == end check in the for loop.
<courmisch>
mkver: there is p += 3 in that loop
<courmisch>
but judging from the initialisation loop, it's assumed that end is at least 3 bytes from the end anyway
<courmisch>
because why not call end something that's not the end
<mkver>
It is presumed that the buffer is padded.
<mkver>
But I do not get the "judging from the initialisation loop" part.
<mkver>
The initialization loop does not rely on padding.
<mkver>
And most users don't want it anyway; we should remove it.
<courmisch>
the first loop reads 4 bytes from p on the sole condition that end - p >= 1
<courmisch>
so already there, if p == end + 1, then that loop will read 3 bytes after end
<mkver>
The first loop has a check for p == end.
<courmisch>
yes, that's the point
MisterMinister has quit [Ping timeout: 255 seconds]
<courmisch>
the first loop is only defined if there are three bytes after end
<courmisch>
as is the main loop
<mkver>
No.
<courmisch>
yes
<courmisch>
in any case, the give away is the final return p + 4, which only makes sense if there are at least 4 bytes padding
<mkver>
If this function is called with p + 1 == end, then the first loop will be executed once and will return in its first iteration.
<mkver>
This function only relies on end + 2 to be a valid pointer expression and it does not read values >= end.
mkver has quit [Ping timeout: 256 seconds]
mkver has joined #ffmpeg-devel
BtbN has quit [Remote host closed the connection]
BtbN has joined #ffmpeg-devel
tufei_ has joined #ffmpeg-devel
tufei has quit [Ping timeout: 260 seconds]
BtbN has quit [Ping timeout: 260 seconds]
BtbN has joined #ffmpeg-devel
___nick___ has quit [Ping timeout: 240 seconds]
<Lynne>
michaelni: the ML is using a self-signed SSL cert for email rather than letsencrypt and caused some issues for me until I disabled validation