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 has been released! | Please read ffmpeg.org/developer.html#Code-of-conduct
iive has quit [Quit: They came for me...]
Kei_N has joined #ffmpeg-devel
Kei_N_ has quit [Read error: Connection reset by peer]
minimal has quit [Quit: Leaving]
Mirarora has quit [Quit: Mirarora encountered a fatal error and needs to close]
Mirarora has joined #ffmpeg-devel
c1480 has quit [Read error: Connection reset by peer]
c1480_ has joined #ffmpeg-devel
thilo has quit [Ping timeout: 272 seconds]
thilo has joined #ffmpeg-devel
c1480_ has quit [Read error: Connection reset by peer]
c1480 has joined #ffmpeg-devel
c1480 has quit [Read error: Connection reset by peer]
c1480_ has joined #ffmpeg-devel
<ePirat>
jamrial, breaking API right after the bump is fine?
c1480_ has quit [Read error: Connection reset by peer]
c1480 has joined #ffmpeg-devel
c1480 has quit [Read error: Connection reset by peer]
c1480_ has joined #ffmpeg-devel
<jamrial>
ePirat: the only API that can be broken is the removal of deprecated fields, defines and symbols
c1480_ has quit [Read error: Connection reset by peer]
<jamrial>
the get_supported_config() stuff is too recent, so the AVCodec fields can't be removed just yet
<ePirat>
ok I will look into marking them deprecated except when compiling libav* stuff then
<jamrial>
"them" who?
<ePirat>
the AVCodec fields
<jamrial>
they are already deprecated
<ePirat>
yes I mean specifically the "except when compiling libav* stuff then" part
<ePirat>
so we do not get all these warnings when building
<jamrial>
oh, you mean just silencing the warnings
c1480 has joined #ffmpeg-devel
<jamrial>
what exactly is the problem with my sbc patch, anyway?
<ePirat>
it makes the code more complex for no gain
<jamrial>
the end result is that the AVCodec fields are still populated until they are effectively removed
<ePirat>
there is no point doing this for all codecs when after all they just have a fixed list of supported configs
<ePirat>
it makes sense for codecs where this is more complex, sure, but for most it would make things more complex for no gain…
<jamrial>
so you want to move the fields to FFCodec instead
<ePirat>
yeah, that also was what haasn had in mind IIUC
<ePirat>
but doing it now is not really feasible right now as it breaks API
<jamrial>
it can be done right now if the relevant AVCodec entries stop being const until the deprecation period ends
<ePirat>
could also do that but I wasnt sure it was acceptable to make so many of them non-const
c1480 has quit [Read error: Connection reset by peer]
c1480 has joined #ffmpeg-devel
<ePirat>
jamrial, I can submit a patch for that and see what others opinions are. Making them non-const would be easiest indeed.
<jamrial>
ePirat: eh, maybe just silence the warnings in sbc and wherever else for now, and do the porting/cleaning once we remove the deprecated fields
<jamrial>
no reason to do a set of huge changes now and then anoter in a year
<ePirat>
ok
c1480 has quit [Read error: Connection reset by peer]
c1480_ has joined #ffmpeg-devel
c1480_ has quit [Read error: Connection reset by peer]
System_Error has quit [Remote host closed the connection]
c1480 has joined #ffmpeg-devel
System_Error has joined #ffmpeg-devel
beastd has quit [Ping timeout: 252 seconds]
c1480 has quit [Read error: Connection reset by peer]
^Neo has quit [Ping timeout: 265 seconds]
c1480 has joined #ffmpeg-devel
Sean_McG has quit [Quit: leaving]
jamrial has quit []
beastd has joined #ffmpeg-devel
c1480 has quit [Read error: Connection reset by peer]
c1480 has joined #ffmpeg-devel
c1480 has quit [Read error: Connection reset by peer]
c1480_ has joined #ffmpeg-devel
c1480_ has quit [Read error: Connection reset by peer]
c1480 has joined #ffmpeg-devel
c1480 has quit [Read error: Connection reset by peer]
c1480 has joined #ffmpeg-devel
Martchus has joined #ffmpeg-devel
Martchus_ has quit [Ping timeout: 260 seconds]
bhaskar has joined #ffmpeg-devel
rvalue has quit [Read error: Connection reset by peer]
rvalue has joined #ffmpeg-devel
c1480 has quit [Read error: Connection reset by peer]
c1480_ has joined #ffmpeg-devel
c1480_ has quit [Read error: Connection reset by peer]
c1480 has joined #ffmpeg-devel
Guest59 has joined #ffmpeg-devel
Guest59 has quit [Client Quit]
c1480 has quit [Read error: Connection reset by peer]
c1480_ has joined #ffmpeg-devel
System_Error has quit [Remote host closed the connection]
c1480_ has quit [Read error: Connection reset by peer]
c1480 has joined #ffmpeg-devel
System_Error has joined #ffmpeg-devel
c1480 has quit [Read error: Connection reset by peer]
c1480 has joined #ffmpeg-devel
c1480 has quit [Read error: Connection reset by peer]
c1480 has joined #ffmpeg-devel
c1480_ has joined #ffmpeg-devel
c1480_ has quit [Read error: Connection reset by peer]
c1480 has quit [Read error: Connection reset by peer]
c1480 has joined #ffmpeg-devel
System_Error has quit [Remote host closed the connection]
System_Error has joined #ffmpeg-devel
c1480 has quit [Ping timeout: 245 seconds]
c1480 has joined #ffmpeg-devel
c1480 has quit [Read error: Connection reset by peer]
c1480 has joined #ffmpeg-devel
c1480 has quit [Read error: Connection reset by peer]
c1480 has joined #ffmpeg-devel
c1480 has quit [Read error: Connection reset by peer]
c1480 has joined #ffmpeg-devel
c1480 has quit [Read error: Connection reset by peer]
c1480 has joined #ffmpeg-devel
c1480 has quit [Read error: Connection reset by peer]
c1480 has joined #ffmpeg-devel
c1480 has quit [Read error: Connection reset by peer]
c1480 has joined #ffmpeg-devel
c1480 has quit [Read error: Connection reset by peer]
c1480 has joined #ffmpeg-devel
c1480 has quit [Read error: Connection reset by peer]
c1480 has joined #ffmpeg-devel
<JEEB>
kierank: you know what my feeling is when you literally quote me where I *first* mention event callbacks, and then for stuff where the stats or data or whatever is linked to the AVFrame, side data
<JEEB>
like seriously, WTF
System_Error has quit [Remote host closed the connection]
System_Error has joined #ffmpeg-devel
c1480 has quit [Read error: Connection reset by peer]
c1480 has joined #ffmpeg-devel
c1480 has quit [Read error: Connection reset by peer]
c1480 has joined #ffmpeg-devel
c1480 has quit [Read error: Connection reset by peer]
c1480 has joined #ffmpeg-devel
c1480 has quit [Read error: Connection reset by peer]
c1480 has joined #ffmpeg-devel
c1480 has quit [Read error: Connection reset by peer]
c1480 has joined #ffmpeg-devel
quietvoid has quit [Quit: No Ping reply in 180 seconds.]
quietvoid has joined #ffmpeg-devel
bhaskar has quit [Read error: Connection reset by peer]
bhaskar has joined #ffmpeg-devel
quietvoid has quit [Quit: No Ping reply in 210 seconds.]
quietvoid has joined #ffmpeg-devel
dionisis has quit [Quit: WeeChat 3.8]
Guest99 has joined #ffmpeg-devel
Guest99 has quit [Client Quit]
MetaNova has quit [Excess Flood]
MetaNova has joined #ffmpeg-devel
System_Error has quit [Remote host closed the connection]
System_Error has joined #ffmpeg-devel
j45_ 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
<kierank>
JEEB: sorry not meant to be personal
MetaNova has quit [Excess Flood]
MetaNova has joined #ffmpeg-devel
ccawley2011 has joined #ffmpeg-devel
chainik1 has joined #ffmpeg-devel
srikanth- has quit [Ping timeout: 276 seconds]
chainik has quit [Ping timeout: 276 seconds]
chainik1 is now known as chainik
srikanth has joined #ffmpeg-devel
michaelni has quit [Ping timeout: 276 seconds]
michaelni has joined #ffmpeg-devel
^Neo has joined #ffmpeg-devel
jamrial has joined #ffmpeg-devel
delewis has quit [Remote host closed the connection]
delewis has joined #ffmpeg-devel
DodoGTA has quit [Quit: DodoGTA]
DodoGTA has joined #ffmpeg-devel
DodoGTA has left #ffmpeg-devel [#ffmpeg-devel]
bhaskar has quit [Quit: Konversation terminated!]
bhaskar has joined #ffmpeg-devel
System_Error has quit [Remote host closed the connection]
System_Error has joined #ffmpeg-devel
DodoGTA has joined #ffmpeg-devel
DodoGTA has left #ffmpeg-devel [#ffmpeg-devel]
<haasn>
how is yuv and premultiplied alpha handled?
<haasn>
is that even a thing?
<haasn>
seems like vf_overlay handles it, for sure
<kepstin>
you premultiply only the y channel; the u/v are left untouched.
<kepstin>
at least, that's how i recall it being done...
<kepstin>
now i'm not sure :)
<kepstin>
(i'm probably wrong)
<haasn>
but does the y channel then get multiplied down to 0?
<haasn>
or down to 16?
<haasn>
I can't make head nor tails of the math inside vf_overlay tbh
<haasn>
Lynne: did you know that vf_overlay_vulkan is likely very broken in the case of alpha mixing?
<haasn>
check overlay_alpha_opaque(), it unconditionally overwrites its own output
<haasn>
oh, not broken, just redundant write
<haasn>
why does it set res.a to 1 anyway? shouldn't you be able to overlay a transparent image onto another transparent one?
<Lynne>
yeah, the filter needs a bit of love, I haven't touched it apart from keeping it working
<haasn>
fair
<Lynne>
like yourself, I couldn't really get the math in overlay either, so I did the best I could
<haasn>
so what I do know is that vf_overlay takes a special parameter to control whether or not the *overlay* is assumed to be premultiplied
<haasn>
but I'm not sure if it assumes the *base* layer is always premultiplied or not
<kepstin>
if you're doing alpha blending without converting to a linear color space, the range handling probably doesn't matter that much. that said, i'd expect that converting to full range (or offsetting so the black point is zero), premultiplying to 0, and then converting back to limited range would be best.
<haasn>
what's actually especially weird about vf_overlay unpremultiplies in some cases, shouldn't that never be needed for just overlaying stuff?
<kepstin>
hmm, the math might actually work out ok to leave the values in limited range, premultiplying to zero
ahmedhamed has joined #ffmpeg-devel
<kepstin>
you'd still end up with semi-transparent black composited over black ending up being a correct limited-range black
<haasn>
for starters why is it subtracting - mid, clamping to -mid, mid and then adding mid again
<haasn>
isn't that the wrong clamp range in any case
<haasn>
since it is clamping the high end to 128 + 128 = 256
<haasn>
the first part at least makes sense, dstUV * (1 - alpha) * srcUV * alpha
<haasn>
but then why is it adding *s a second time
<haasn>
I am.. concerned about this code, does it even produce the correct results at all?
<haasn>
and then the luma case is just as broken
<haasn>
so for bits > 8 it simplifies to dstY = dstY * (1 - alpha) + srcY * alpha + srcY - 16
<haasn>
again, the extra srcY - 16 term makes no sense
<haasn>
but in the bits == 8 case it instead outputs dstY = dstY * (1 - alpha) + srcY - 16
<haasn>
and this is all supposed to be the premultiplied src case
<haasn>
that last one is the only one that remotely makes sense and it would imply that you premultiply against 16
DodoGTA has joined #ffmpeg-devel
<haasn>
for the straight src alpha case it just does dst = dst * (1 - alpha) + src * alpha
<haasn>
for all channels including chroma
<haasn>
so we have three different behaviors none of which match each other and it seems it depends on the bit depth and alpha tagging which one is actually being used??
<haasn>
actually it's the extra src * alpha term in the premultiplied case that's not adding up here
<haasn>
what codecs even support yuva again? webp?
<JEEB>
VP8/9 with libvpx (I had a hack branch for avcodec VP8 which only worked with single thread)
<JEEB>
HEVC has a patch set I think
<JEEB>
vp6 I think had alpha implemented already?
<haasn>
ofc vf_overlay is bad in the sense also that it doesn't do linear light blending
<haasn>
pngdec.c has some interesting math also
<haasn>
for the handling of straight rgba -on- straight rgba
<haasn>
in libavif it seems that premul vs non-premul is done always in RGB space
<haasn>
before conversion to YUV
<haasn>
so that would imply that limited range YUV with alpha=0 would end up as (16, 128, 128)
<haasn>
that would align also with what you get during conversion from rgba to yuva using e.g. swscale
<haasn>
and would imply that direct compositing of premultiplied yuva overlays is not a thing one should do *ever*, since the premultiplication happens on RGB
<haasn>
the linearity would be destroyed after the conversion to YUV
<haasn>
actually nvm the math should cancel out since it's just a linear matrix, so it should still work.. hmm
<kepstin>
if the chroma channels are treated as signed (neutral chroma is 0) then it should be equivalent i guess.
minimal has joined #ffmpeg-devel
<thardin>
does texi2man really not support @headitem?
<thardin>
err or whatever command it is that makes manpages from .texi
<thardin>
pod2man even. seems all other @multitable do not use @headitem
<thardin>
oh yeah it's similarly broken for the "Audio Codecs" section in ffmpeg-all.1
<haasn>
kepstin: vf_premultiply also handles it in the way I just described
<haasn>
so if anything, we can test to see if vf_premultiply + vf_overlay (alpha=premultiply) commutes with vf_overlay (alpha=straight)
<kepstin>
JEEB: yeah, but that's an older core design which doesn't support vector extensions, making it a bit less interesting for multimedia dev
<JEEB>
oh right, didn't check that yet
<JEEB>
no vectors = meh
System_Error has quit [Remote host closed the connection]
System_Error has joined #ffmpeg-devel
ccawley2011 has quit [Ping timeout: 248 seconds]
<Lynne>
packets are guaranteed to be refcounted, right?
<Lynne>
ah, they aren't, but I can use av_packet_ref() to make one
Guest40 has joined #ffmpeg-devel
<Lynne>
(since I'm guessing decoders aren't allowed to modify packets, which includes calling av_packet_make_refcounted())
Guest40 is now known as srikanth-remote
<Lynne>
what would be the best way to give a hwaccel the avbufferref/avpacket of the decoder? leave a ref in the main decoder context, or hack it in the data ptr of start_frame, or make a new start_frame_ref callback?
srikanth-remote has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
Guest40 has joined #ffmpeg-devel
<fflogger>
[editedticket] mikey1959515: Ticket #11477 ([ffmpeg] "webvtt is not in allowed_extensions" by recent git master versions only) updated https://trac.ffmpeg.org/ticket/11477#comment:5
psykose has quit [Remote host closed the connection]
psykose has joined #ffmpeg-devel
<fflogger>
[editedticket] MasterQuestionable: Ticket #11477 ([ffmpeg] "webvtt is not in allowed_extensions" by recent git master versions only) updated https://trac.ffmpeg.org/ticket/11477#comment:6
<Guest40>
Can someone please review my patch [PATCH v3] libavformat/mov: fix seek issues for fragmented mp4 files? Is there a maintainer for mov/mp4?
Guest40 has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
Guest40 has joined #ffmpeg-devel
b50d has joined #ffmpeg-devel
IceLeader has joined #ffmpeg-devel
b50d has quit [Remote host closed the connection]
Mirarora has quit [Quit: Mirarora encountered a fatal error and needs to close]
c1480 has quit [Read error: Connection reset by peer]
c1480 has joined #ffmpeg-devel
c1480 has quit [Read error: Connection reset by peer]
c1480 has joined #ffmpeg-devel
Guest40 has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
rvalue- has joined #ffmpeg-devel
Mirarora has joined #ffmpeg-devel
rvalue has quit [Ping timeout: 260 seconds]
c1480 has quit [Read error: Connection reset by peer]
<IceLeader>
How to simplify this code: if (shiftbits & 1) delta += (step >> 3);
<IceLeader>
if (shiftbits & 2) delta += (step >> 2);
<IceLeader>
if (shiftbits & 4) delta += (step >> 1);
<IceLeader>
if (shiftbits & 8) delta += step;
<haasn>
isn't that just a multiplication with reverse bit order
<haasn>
(plus shift)
<IceLeader>
its part of 5bit adpcm ima wav expand nibble
<haasn>
if you can make shiftbits defined the other way around it could be just (step * shiftbits) >> 3
<IceLeader>
thing is ffmpeg lavc decoder is not correct
<haasn>
I think
<IceLeader>
how do you bitreverse fast 4bits ?
microchip_ has joined #ffmpeg-devel
<BtbN>
google says via lookup table
<IceLeader>
and AI ?
<BtbN>
It'll probably say to use Rust and NodeJS
<jkqxz>
The LUT fits in a 64-bit register. Reverse n as (0xf7...80 >> (n << 2) & 0xf).
System_Error has quit [Remote host closed the connection]
System_Error has joined #ffmpeg-devel
<kurosu>
Sounds like 2 pshufbs and 2 shifts ?
<kurosu>
(and 2 ands)
<IceLeader>
haasn: it doest work, its worse than current state in adpcm decoder: diff = ((2 * delta + 1) * step) >> shift;
<IceLeader>
the delta is shiftbits above
<haasn>
rather than using a lut to reverse the bits you might as well use a LUT to look up the correct multiplication value directly
<haasn>
actually, wait, why even reverse bits
<haasn>
I guess the problem either way is that bits in step >> 3 can leak into higher order bits if you do the summation before shifting
<haasn>
so nvm
<IceLeader>
the above code works correcly only for 2bit adpcm ima wav, for 3, 4, 5 it give 45dB in SDR, instead of inf when compared with reference (the one that check each bit)
<IceLeader>
so there is no short cut for bunch if if () checks?
<haasn>
you could probably do a multiplication minus a correction factor when the low order bits are all high
<IceLeader>
looks i will add lut of 16 entries for bps
<IceLeader>
so 2^(bps-1) entries
<haasn>
like, if too many bits are set in (shiftbits & step)
<haasn>
you probably need to subtract the error
<haasn>
a lut might be faster
<haasn>
is this a bottleneck?
<IceLeader>
89*16 LUT?
<IceLeader>
i search for alternative for if () cases
<haasn>
the problem rather is the opposite of what I said
<haasn>
delta += (step >> 3) * shiftbits /* this is the basic idea but too small */
<haasn>
so you need to add on also (step >> 2) & 1 if (shiftbits & 2)
<haasn>
and (step >> 1) & 1 if (shiftbits & 4)
<haasn>
maybe that second part can be done easier
<haasn>
it's something like popcount((shiftbits & step) >> 1)
<haasn>
dunno
<haasn>
try playing with that approach
Guest40 has joined #ffmpeg-devel
<frankplow>
coverage.ffmpeg.org seems to have an issue with its SSL certificate
<IceLeader>
8bit incomplete, as I need to copy bunch of lut tables
<jamrial>
IceLeader: that's a huge private context stored in heap. storing worst case scenario size is not a good idea
<jamrial>
consider using av_fast_realloc for input instead
<IceLeader>
lol, really?
<jamrial>
65kb
<IceLeader>
RAM is cheap
<jamrial>
we have gotten complains about big memory usage for way smaller contexts :p
<jamrial>
think about embedded
<IceLeader>
memory reallocations are not real-time safe
<jamrial>
how so?
<IceLeader>
it takes lot of time to reallocate memory
<haasn>
av_fast_realloc_or_use_fixed_size_buf()
<haasn>
IceLeader: it takes time to allocate more stack pages when you run out, too
<jamrial>
av_fast_realloc() allocates more than what you ask it for, so if a new packet needs only slightly more than the previous, there wont be a reallocation
pross has quit [Ping timeout: 260 seconds]
Guest40 has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
<IceLeader>
haasn: interesting, exr use premultiplied alpha
<haasn>
Next we need full avfilter negotiation for alpha mode and vf_(un)premultiply auto insertion
<haasn>
So we can ffmpeg -i foo.exr foo-png
<haasn>
Well, actually I should just add this to nuscale
<IceLeader>
but whole premultiply+alpha usage is so low, that its used only by pro consumers for various effects, which ffmpeg is not primary goal, but anyway if you find it funny and not daunting I will not "block" your fine work :)
ramiro has quit [Ping timeout: 244 seconds]
ramiro has joined #ffmpeg-devel
IceLeader has quit [Quit: Client closed]
_av500_ has quit [Ping timeout: 276 seconds]
_av500_ has joined #ffmpeg-devel
System_Error has quit [Remote host closed the connection]
System_Error has joined #ffmpeg-devel
ccawley2011 has quit [Read error: Connection reset by peer]
cone-842 has joined #ffmpeg-devel
<cone-842>
ffmpeg James Almer master:7e84865cff2d: avcodec/codec_internal: remove unnecessary avcodec.h include
<cone-842>
ffmpeg James Almer master:0526535cd584: avformat/iamf_parse: add missing constrains for num_parameters in audio_element_oub()
<cone-842>
ffmpeg James Almer master:5470d024e189: avformat/iamf_parse: ensure there's at most one of each parameter types in audio elements
<cone-842>
ffmpeg James Almer master:84d85e7ad4ac: avformat/oggenc: don't discard empty packets with no side data
<cone-842>
ffmpeg James Almer master:261ec6c35e30: avformat/mov: further ensure mov_build_index isn't run twice