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.1 has been released! | Please read ffmpeg.org/developer.html#Code-of-conduct
<Lynne>
lol, even github got hit by scrapers hard enough to care
jamrial has quit []
deeyes has quit [Ping timeout: 260 seconds]
deeyes has joined #ffmpeg-devel
mkver has joined #ffmpeg-devel
mkver has quit [Ping timeout: 245 seconds]
compnn has quit [Read error: Connection reset by peer]
deeyes has quit [Ping timeout: 276 seconds]
deeyes has joined #ffmpeg-devel
<fflogger>
[editedticket] rgr2: Ticket #979 ([swscale] Abnormal colorspace conversion of BGR -> YUV comparing the RGB variant) updated https://trac.ffmpeg.org/ticket/979#comment:28
<frankplow>
Has anyone found a way in forgejo to navigate from a commit merged into master to the PR (could be PRs I guess) it was a part of?
<frankplow>
GitHub and GitLab have links for this when you expand the commit details, but I don’t see any such link in Forgejo at first glance. It’s quite useful for quickly finding the discussion around a change
<frankplow>
It could be that it works when merged through forgejo rather than manually I suppose
LainIwakura has joined #ffmpeg-devel
secondcreek has quit [Remote host closed the connection]
secondcreek has joined #ffmpeg-devel
secondcreek has quit [Remote host closed the connection]
secondcreek has joined #ffmpeg-devel
kurosu has joined #ffmpeg-devel
desmond-netint has quit [Remote host closed the connection]
kasper93 has quit [Ping timeout: 276 seconds]
MisterMinister has quit [Remote host closed the connection]
<JEEB>
I like seeing in github that the commit lists the PR that it came out of. and since forgejo seems to support figuring out that a PR was merged by comparing against PR HEADs, it should be possible to then add that metadata
scat117 has joined #ffmpeg-devel
<haasn>
forgejo also does not seem to have merge trains yet
<haasn>
though admittedly, neither does gitlab unless you pay for the enterprise version
<scat117>
`-stream_loop -1 -framerate 60 -i $image` repeatedly decodes the image. this can be very slow. imagine an image with a huge height used with the `scroll` filter. is there a way for users to avoid this pitfall?
<scat117>
scat117: this is made worse by image decoders being single threaded of course.
<JEEB>
scat117: for usage questions #ffmpeg ; and yes, that looping is on the stream IO level (thus *stream* loop), so think of it just looping the same data over and over into the parser and then decoder etc :P
Guest85 has joined #ffmpeg-devel
Guest85 has quit [Client Quit]
<sfan5>
is it possible to generate a compile_commands.json for ffmpeg?
<llyyr>
intercept-build from clang
<JEEB>
oh so there's a clang built-in tool now, too?
<JEEB>
I just recall utilizing some other tool previously
<llyyr>
there's been for a while I just didn't know
<JEEB>
but in any case, yup. you can make that file so that clang based checkers can help you with your editing
LainIwakura has quit [Quit: Client closed]
<sfan5>
apparently that requires waiting through one run of make -j1
<sfan5>
wait nvm
indecisiveturtle has joined #ffmpeg-devel
indecisiveturtle has quit [Ping timeout: 252 seconds]
indecisiveturtle has joined #ffmpeg-devel
<frankplow>
JEEB sfan5: I think bear is the other tool you are thinking of. It does requiring compiling once (I don’t think parallelism is an issue though).
<JEEB>
right, that's the thing yes
<sfan5>
intercept-build worked for me
<sfan5>
would be nice to document this somewhere
<sfan5>
because writing C code "blind" is a bit annoying
<JEEB>
yea, definitely would wbe worth to document
LainIwakura has joined #ffmpeg-devel
<wbs>
in addition to intercept-build and bear, there's also a tool called "compiledb", that works roughly the same as the others. iirc it may have less annoying dependencies to install/build than bear
<haasn>
I noticed that a lot of filters with SIMD have no provisions for handling images whose linesize is not a clean multiple of the mmsize
<haasn>
is it fair to treat all such instances as a bug?
<haasn>
The documentation on AVFrame.linesize only states that it *should* be a multiple of the CPU's alignment preference
<haasn>
e.g. vf_yadif, vf_bwdif just to name two that I recently looked at
<haasn>
or rather, images whose width rounded up to mmsize is larger than the linesize
<haasn>
ah, this is documented elsewhere: "some filters may read up to 16 bytes after the image end"
<haasn>
but e.g. vf_bwdif will happily read 32 bytes (AVX2 impl)
<haasn>
so this documentation is just plain wrong; and especially with AVX512 it's starting to become a mess
<haasn>
I feel like the correct thing to do is to both 1) update the recommendation to 64 bytes and 2) ensure all filters don't segfault regardless of linesize
<JEEB>
yea, I think we've mostly just been saved by the fact that almost everyone is utilizing our allocators or something
<sfan5>
getting pinged for every edit seems unnecessary
<indecisiveturtle>
kierank: Did they specify sommewhere why the vulkan version are considered bad, cause getting more feedback would be nice. At least for the vulkan encoder I worked on, it is missing some features but it was decently faster than the cpu version iirc
<kurosu>
haasn: are writes from these filters SIMD, that would go into the padding/the next line, be overwritten by the next line processing or end up in the padding? Not caring about the line end isn't completely wrong there.
<kurosu>
And yes, by now, 64 extra bytes allocated for image buffers is warranted. For bitstream buffers, maybe less so
<kasper93>
av_log(NULL is only not nice in tihs file
<kasper93>
bro...
BradleyS has quit [Ping timeout: 260 seconds]
ccawley2011 has quit [Read error: Connection reset by peer]
<kasper93>
> promises that were made about a fullability to interact by mail
<kasper93>
hmm
<fjlogger>
[FFmpeg/FFmpeg] New comment on pull request #20055 BIGSLEEP-433502298 (dashdec) and BIGSLEEP-434637586 (sanm) and a unrelated issue in subfile i stumbled across while testing (https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/20055) by michaelni
<cone-144>
ffmpeg Michael Niedermayer master:3ccd7d8c8e85: avcodec/sanm: Check decoded_size for old_codec48
<cone-144>
ffmpeg Michael Niedermayer master:ebcdba4c6b34: avformat/subfile: Initialize end on all cases
<cone-144>
ffmpeg Michael Niedermayer master:f09c834a7d01: avcodec/cbs_apv_syntax_template: Check tile_data_size
<Traneptora>
kierank> I see nobody (except kasper93) has concerns about tls being vibe coded in ffmpeg
<kierank>
that's changed
<Traneptora>
fwiw, I think many of us do have concerns. I just have nothing to add to the discussion beyond "+1" or something else not interesting
<kierank>
I don't care that much if it was for some random filter or codec
<kierank>
But for TLS...
<Traneptora>
yea, I just didn't feel like responding and saying basically the same thing was unacceptable
<Traneptora>
not prolific enough of a contributor to feel like I want to parse a reply from someone typing misspelled lowercase incomplete sentences
<kierank>
LOL
minimal has quit [Quit: Leaving]
<llyyr>
if the vibe coded code got merged without any reviews, shouldnt the person pushing have their perms taken away or at least be put on ice
stevenliu has joined #ffmpeg-devel
<TheVibeCoder>
llyyr: agreed
<stevenliu>
I trust the student, and there have more than 95% code was written by.