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 6.1.1 has been released! | Please read ffmpeg.org/developer.html#Code-of-conduct
iive has quit [Quit: They came for me...]
elastic_dog has quit [Ping timeout: 260 seconds]
elastic_dog has joined #ffmpeg-devel
epony has quit [Ping timeout: 264 seconds]
lexano has quit [Ping timeout: 256 seconds]
rodeo has joined #ffmpeg-devel
thilo has quit [Ping timeout: 264 seconds]
thilo has joined #ffmpeg-devel
thilo has quit [Changing host]
thilo has joined #ffmpeg-devel
Goedix_ has quit [Quit: Leaving]
cone-885 has quit [Quit: transmission timeout]
navi has quit [Quit: WeeChat 4.0.4]
dellas has quit [Remote host closed the connection]
jamrial has quit []
lemourin has quit [Read error: Connection reset by peer]
lemourin6 has joined #ffmpeg-devel
lemourin6 is now known as lemourin
epony has joined #ffmpeg-devel
psykose has joined #ffmpeg-devel
Martchus_ has joined #ffmpeg-devel
Martchus has quit [Ping timeout: 256 seconds]
mkver has joined #ffmpeg-devel
kurosu has joined #ffmpeg-devel
<kurosu>
> FF_COPY_SWAP_ZERO_USES_MMX
<kurosu>
Huh. I'd thought in this time and age the compiler could do as well with uint64_t copies. I imagine this is the i686 build so movq and SSE registers are not possible?
<mkver>
kurosu: Yes, it is for 32bit only.
Teukka has quit [Read error: Connection reset by peer]
Teukka has joined #ffmpeg-devel
Teukka has quit [Changing host]
Teukka has joined #ffmpeg-devel
AbleBacon has quit [Read error: Connection reset by peer]
cone-986 has joined #ffmpeg-devel
<cone-986>
ffmpeg Anton Khirnov master:00013341dfd6: fftools/ffmpeg_sched: add filter API to signal EOF on input
<cone-986>
ffmpeg Anton Khirnov master:1ea2e757f7cb: fftools/ffmpeg_filter: do not end filtering when a graph input EOFs
<cone-986>
ffmpeg Anton Khirnov master:bab7f91c36ab: tests/fate/ffmpeg: add a test for the issue fixed in previous commit
kurosu has quit [Quit: Connection closed for inactivity]
kurosu has joined #ffmpeg-devel
jarthur has quit [Quit: jarthur]
jamrial has joined #ffmpeg-devel
cone-986 has quit [Quit: transmission timeout]
jessidhia has quit [Ping timeout: 246 seconds]
ccawley2011 has joined #ffmpeg-devel
jkkm has quit [Ping timeout: 256 seconds]
mindfreeze has quit [Ping timeout: 260 seconds]
jessidhia has joined #ffmpeg-devel
mindfreeze has joined #ffmpeg-devel
jkkm has joined #ffmpeg-devel
zsoltiv_ has quit [Ping timeout: 268 seconds]
kurosu has quit [Quit: Connection closed for inactivity]
dellas has joined #ffmpeg-devel
navi has joined #ffmpeg-devel
ccawley2011 has quit [Read error: Connection reset by peer]
<Lynne>
is it possible to run oss-fuzz locally?
<aaabbb>
i think they just run libfuzzer
aljazmc has joined #ffmpeg-devel
lexano has joined #ffmpeg-devel
<kasper93>
Lynne: `... --libfuzzer=-fsanitize=fuzzer --enable-ossfuzz --disable-asm` and then you can make one of the fuzzer binary, look at makefile in tools folder for available targets
<Lynne>
how does it compare to afl? afaik afl was the standard
<kasper93>
I don't know myself, don't have much experience with afl. For me it is ease of use of fsanitize=fuzzer, it just works.
<Lynne>
how does it work? when you launch a program with a source, does it somehow detect the input and modifies it?
dellas has quit [Remote host closed the connection]
<llyyr>
how likely is it that AV_FRAME_FLAG_INTERLACED may be set for a frame that is not interlaced? i.e. can it be used reliably for an "auto" deinterlacer that is allowed to have false negatives but not false positives?
<JEEB>
it should set that flag for output that was originally flagged/coded as interlaced
<JEEB>
what the actual coded content there was is not related
<JEEB>
so for example when blu-ray does a dum-dum and you can only have 25Hz by coding it as "fake interlaced", then it most likely will be flagged as interlaced
<Lynne>
yeah, you can't rely on it at all, I also have progressive 30fps content flagged as interlaced, with fields having the same timewise content
<llyyr>
I see
<JEEB>
you can think of it on the level that it is just the codec saying that this was flagged as such
<kasper93>
if it is flagged with wrong colorspace it will be wrong too
<kasper93>
I don't see the argument for ignoring it, wrongly tagged files are wrong
<JEEB>
at least with codecs like H.264 you have actual interlaced coding modes etc, so the flag kinda does things, but yea.
<JEEB>
generally the same kinda thing. the coding mode might not match the content
<kasper93>
I see, anyway madvr itself has filter based on fps and I don't think in practice anyone is complaining about it.
<kasper93>
either way, I don't care interlaced content is the past
<llyyr>
All the more reason to not bother with an auto setting that might produce false positives imo
Krowl has joined #ffmpeg-devel
Krowl has quit [Client Quit]
Krowl has joined #ffmpeg-devel
<kasper93>
thing is the false positives are in very small portion of content. I don't know where this focus on some obscure edge case is comming from.
<JEEB>
at least thankfully various filters don't really cause too bad artifacts. just extra CPU or GPU usage.
<JEEB>
yea, most of the broadcast etc content I have is interlaced. there's for sure the fake interlaced content, but at least for me that's the lesser part of things
dellas has joined #ffmpeg-devel
<kasper93>
same as in ass pr, "reeee you're breaking my usecase" -> "it never was supported" -> "ok". It is like hyper-focusing on some technicality that 99.9% users don't care. #offtopic sorry
<JEEB>
also the fun bit of interlacism is that you can have telecine and actual full interlacing :)
<JEEB>
which IMO is a much bigger thing, but I would not care about it for an automated setup
<JEEB>
since the main thing is that you go from interlacism to progressive
<kasper93>
of course
dellas has quit [Remote host closed the connection]
dellas has joined #ffmpeg-devel
dellas has quit [Remote host closed the connection]
<elenril>
* what is the extent of i'th subrectangle
<elenril>
* in what subrectangle does pixel x,y lie
<elenril>
at no point does the user care about any tile rows or columns
<jamrial>
ok
<jamrial>
will try to do it that way
<elenril>
I mean maybe I'm missing something and maybe the user does care
<elenril>
but so far I don't see the reason why
<jamrial>
there's the "coded" size (size of all the images in the grid), and the output size (size of the actual image data, to derive cropping values)
<jamrial>
"coded" size is, in my current design, derived from the sum of widths/heights of all images in a row/column
<Lynne>
I think row/columns are reasonable, since they don't allow for overlap unlike rectangles
<elenril>
it's a compression scheme, makes it harder to actually work with
<elenril>
that said, I'm fine with the struct containing these values and a set of helper functions that give you rectangles
<jamrial>
do we need that function if it's exclusively within the Stream Group API?
<jamrial>
the "tiles" are the streams in the group
<elenril>
there needs to be a simple and obvious way for the user to get answers to the 3 above bullet points
<jamrial>
* how many sub-rectangles are there <- AVStreamGroup->nb_streams
<jamrial>
* what is the extent of i'th subrectangle <- AVStreanGroup->streams[i]->{width,height}
<jamrial>
* in what subrectangle does pixel x,y lie <- this one would need a helper, i guess
<elenril>
I don't mean just width and height, but also the topleft corner
<elenril>
is that easily computable?
<jamrial>
topleft corner of the grid, or the tile?
<elenril>
of the tile
<elenril>
for the grid it's 0,0 I assume
<jamrial>
yes
Traneptora has quit [Quit: Quit]
<jamrial>
and the sum of widths of tiles to the left and sum of heights of tiles above the ith tile should give you the topleft corner offset
<jamrial>
look at dump.c in my latest patch to see how i calculated the coded dimensions of the grid