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
iive has quit [Quit: They came for me...]
_whitelogger has joined #ffmpeg-devel
cone-598 has joined #ffmpeg-devel
<cone-598>
ffmpeg Frank Plowman master:0382291811ef: lavc/vvc: Fix divide-by-zero in LMCS param derivation
<cone-598>
ffmpeg Frank Plowman master:ae0f71a387f0: lavc/h2645_parse: More descriptive NALU header error
jamrial has quit []
Martchus has joined #ffmpeg-devel
Martchus_ has quit [Ping timeout: 276 seconds]
marcj has quit [Ping timeout: 244 seconds]
cone-598 has quit [Quit: transmission timeout]
System_Error has quit [Remote host closed the connection]
System_Error has joined #ffmpeg-devel
mkver has quit [Ping timeout: 244 seconds]
lexano has quit [Ping timeout: 268 seconds]
lexano has joined #ffmpeg-devel
_whitelogger has joined #ffmpeg-devel
kepstin has quit [Remote host closed the connection]
kepstin has joined #ffmpeg-devel
Anthony_ZO has joined #ffmpeg-devel
putacho has quit [Quit: There is no spoon!]
microchip_ has joined #ffmpeg-devel
microchip_ has quit [Client Quit]
microchip_ has joined #ffmpeg-devel
microchip_ has quit [Quit: There is no spoon!]
microchip_ has joined #ffmpeg-devel
mkver has joined #ffmpeg-devel
jamrial has joined #ffmpeg-devel
HarshK23 has joined #ffmpeg-devel
minimal has joined #ffmpeg-devel
DVedaa has quit [Ping timeout: 248 seconds]
Faeez has joined #ffmpeg-devel
<Faeez>
Hi all,
<Faeez>
I'm Faeez Kadiri. I've implemented a new stack_cuda filter for FFmpeg and submitted it for review:
<Faeez>
This complements the existing stack_qsv and stack_vaapi filters, and adds CUDA support for stacking.
<Faeez>
Would appreciate any feedback or suggestions. Thanks!
Anthony_ZO has quit [Ping timeout: 248 seconds]
steven-netint has quit [Quit: Connection closed for inactivity]
kunkku has quit [Ping timeout: 244 seconds]
kunkku has joined #ffmpeg-devel
<compn>
Faeez, nice. it might get more attention if you submit it to ffmpeg-devel mailing list
<compn>
or you may have already done that in which, ignore me
Faeez has quit [Quit: Ping timeout (120 seconds)]
Faeez has joined #ffmpeg-devel
IndecisiveTurtle has quit [Quit: IndecisiveTurtle]
<haasn>
how do we feel about VLAs in FFmpeg? (especially for cold setup functions)
<haasn>
I guess we ban them?
<Lynne>
C23 made them optional, which should tell you all you need to know about them
<jkqxz>
C11 made them optional.
<jkqxz>
But yes, avoid. (Also alloca() for the same thing.)
<Lynne>
wow, its been this long already
lemourin has joined #ffmpeg-devel
Flat has quit [Quit: Rip internet]
Flat has joined #ffmpeg-devel
Flat has quit [Quit: Rip internet]
Flat has joined #ffmpeg-devel
Flat has quit [Client Quit]
Flat has joined #ffmpeg-devel
tufei_ has joined #ffmpeg-devel
tufei has quit [Ping timeout: 264 seconds]
Faeez has quit [Ping timeout: 240 seconds]
kasper93 has quit [Remote host closed the connection]
kasper93 has joined #ffmpeg-devel
tufei__ has joined #ffmpeg-devel
tufei_ has quit [Ping timeout: 264 seconds]
<haasn>
I want to support dither sizes up to 256x256 in swscale; but generating a 256x256 dither texture takes ~5 seconds. I already tried all easy/obvious methods of speeding up the O(n^4) algorithm
<haasn>
the result is ~128 K
<haasn>
how do we feel about including this table unconditionally? I feel like 5 seconds is too long even for CONFIG_SMALL
<haasn>
or maybe we should limit the maximum dither size on CONFIG_SMALL
tufei__ has quit [Remote host closed the connection]
tufei__ has joined #ffmpeg-devel
<haasn>
(256x256 blue noise dither almost as high quality as error diffusion while being substantially cheaper)
<haasn>
maybe I can find a faster algorithm somewhere
<haasn>
seems like a better way to implement void and cluster is using an FFT for the blur step which makes it run at O(n^2 * log n)
<mkver>
haasn: 128K is IMO too big.
<haasn>
mkver: what about 32K? (for a 128x128 matrix)
<haasn>
this one takes only 122 ms to compute
<haasn>
or 9 ms for a 64x64 (= 8K size)
<haasn>
and then maybe we can up the size to 256x256 with a faster algorithm that uses an FFT for generation
<jamrial>
michaelni: this is not the way...
<mkver>
michaelni: Did you merge ordinary FFmpeg into Paul's fork instead of just his commits into FFmpeg? Looking at 69796910df4 the answer seems to be "yes".
<michaelni>
?
<michaelni>
it merges both branches together
<BtbN>
A merge does not really have a concept of "one into the other"
<BtbN>
it just merges two parents
<michaelni>
yes
<BtbN>
Of course it'll list a ton of FFmpeg commits on top of pauls ones, cause I doubt he merged from ffmpeg in a while
<michaelni>
mkver, the way ive done it is to merge 1 month at a time, we merge 2 branches, ffmpeg and pauls code, ive done these in 2 seperate merges that is 2 merges per month of code
<michaelni>
if you try to merge 2025-05 ffmpeg HEAD with 2024-01 of pauls branch it will be messy because these differ alot more than 2024-01 and 2024-01 of both branches
<michaelni>
I think the way i did it was the cleanest and easiest. But if theres a better way, nothing the new repository is in mainline it can all be redone if someone wants to redo it differently
minimal has quit [Quit: Leaving]
<fflogger>
[editedticket] malvinas2: Ticket #7337 ([avformat] FFmpeg not recognizing WebVTT subtitle stream from HLS playlist) updated https://trac.ffmpeg.org/ticket/7337#comment:6