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
zeezie23 has quit [Remote host closed the connection]
Martchus has joined #ffmpeg-devel
Martchus_ has quit [Ping timeout: 268 seconds]
sudden has quit [Ping timeout: 248 seconds]
rvalue has quit [Read error: Connection reset by peer]
rvalue has joined #ffmpeg-devel
sudden has joined #ffmpeg-devel
<compnn>
Lynne, says 403
System_Error has quit [Remote host closed the connection]
System_Error has joined #ffmpeg-devel
System_Error has quit [Remote host closed the connection]
System_Error has joined #ffmpeg-devel
cone-183 has quit [Quit: transmission timeout]
rvalue- has joined #ffmpeg-devel
rvalue has quit [Ping timeout: 252 seconds]
rvalue- is now known as rvalue
abdu has joined #ffmpeg-devel
abdu has quit [Quit: Client closed]
MaskedLeader has joined #ffmpeg-devel
<MaskedLeader>
are there fiiles for section5 input demuxer for dav1d that ffmpeg does not support?
System_Error has quit [Remote host closed the connection]
System_Error has joined #ffmpeg-devel
delewis has quit [Remote host closed the connection]
delewis has joined #ffmpeg-devel
sdc has quit [Quit: Connection closed for inactivity]
System_Error has quit [Remote host closed the connection]
System_Error has joined #ffmpeg-devel
^Neo has quit [Ping timeout: 244 seconds]
<fflogger>
[newticket] dkode: Ticket #11481 ([ffmpeg] Alpha decoding support in heic image using H/W) created https://trac.ffmpeg.org/ticket/11481
MaskedLeader has quit [Quit: Client closed]
MaskedLeader has joined #ffmpeg-devel
mkver has joined #ffmpeg-devel
<haasn>
ramiro: michaelni: maybe one of you knows; is there theory behind the optimal way to do ordered (bayer) dithering on images with more than one component (e.g. rgb)? obviously the naive way is to compute one NxN dither matrix and add it to all channels before flooring
<haasn>
but sws seems to do something special where it uses either a different dither matrix per channel, or possibly the same dither matrix but with a different offset/position per component
<haasn>
also, is there theory behind the optimal size of the matrix N?
<haasn>
some sizes seem to work better than others
<haasn>
e.g. 4x4 produces better results than 8x8 somehow
<haasn>
or wait, I fixed a bug in the dither calculation since I did that test, should redo it
<haasn>
yeah nvm, higher sizes clearly are better
<haasn>
but there is a consideration where using higher matrix sizes has diminishing returns at certain bit depths
<haasn>
for example dithering to 2 bits with a 32x32 matrix yields identical results to a 2x2 because there are only 4 intervals in the output range
<haasn>
so simply put, the dither matrix should never be larger than the output bit depth
Manouchehri has quit [Ping timeout: 260 seconds]
<kurosu>
The theory may be that the green has the most luma in it, and that's what the dithering would have the most impact? Highly theoretical, and you seem to have figured something else
<MaskedLeader>
debayering is art in itself
<MaskedLeader>
many ways to do it
Manouchehri has joined #ffmpeg-devel
jamrial has joined #ffmpeg-devel
ccawley2011 has joined #ffmpeg-devel
<Lynne>
I think the best way to debayer is to upscale by 2x with something that has good reversible downscaling properties, combine the pixels into xyz by treating them as offset chroma samples, then downsample by 2x
<Lynne>
every algorithm I've looked at seems to really want to avoid anything computationally expensive
<haasn>
ChatGPT suggests using prime offsets
<haasn>
i.e. shifting the 16x16 bayer matrix by a (P,Q) offset per channel where P, Q are different primes for each channels
<MaskedLeader>
that is sloooow
<haasn>
I mean the slowest part is loading a different dither bias value per component
<haasn>
that is slow no matter what indexing scheme you use
<haasn>
the only faster alternative would be to e.g. reflect the dither matrix, but I don't see how a negation is slower than an addition by a small immediate
<haasn>
faster*
<MaskedLeader>
"high quality" de-bayer can be separate filter
<haasn>
(I'm not talking about debayer)
<MaskedLeader>
whats wrong with current algorithm as used by sws?
<haasn>
well, I'm not sure what exactly it's doing, it seems to have slightly better results on very low bit depth dithering (e.g. rgb24 -> rgb8 or rgb4)
<haasn>
maybe it forces ordered dither?
<haasn>
error diffusion*
<MaskedLeader>
rgb8/rgb4 is cringe
<MaskedLeader>
yes, it is using some dithering, i think either fixed pattern or something better
<haasn>
nope it's not doing ED, but even with bayer dither I get MSE={ 2656 1502 1723 0} versus swscale MSE={ 1326 3056 2887 0}
<michaelni>
haasn, the rgb dither matrix differences where a result of trying different ones and looking with my eyes picking what looked best
<haasn>
but if I look at the output visually it looks okay, and imagemageck PSNR is almost identical
<haasn>
but somehow MSE is much higher
<haasn>
I don't get it
<MaskedLeader>
huh? why not use psnr filter?
<MaskedLeader>
or you comparing imagemagick dithering/conversion?
minimal has joined #ffmpeg-devel
<MaskedLeader>
jamrial: does ffmpeg have support for section5 demuxer (the one in dav1d) ?
<jamrial>
yeah
^Neo has joined #ffmpeg-devel
^Neo has joined #ffmpeg-devel
^Neo has quit [Changing host]
thardin has quit [Ping timeout: 272 seconds]
<BBB>
ffmpeg supports everything
<MaskedLeader>
section5 == obu ?
<BBB>
yes
<MaskedLeader>
strange naming
<BBB>
it's like concatenated nal units in h26x
<BBB>
whatever that was called, I forgot
<BBB>
it's described in section5 of the spec so we decided to call it "section5"
<MaskedLeader>
funny
<BBB>
annexb is the h26x one
<jamrial>
it's obu in lavf because the format is raw obus with no other container-like delimitation
<BBB>
there's also annexb in av1, but that's something else again
<BBB>
they're both called "obu" (extension), I think
<BBB>
so "section5" and "annexb" are distinct formats with the same extension in av1
<BBB>
but yes jamrial is right, section5 is raw obus, and annexb has a tiny header around it
<BBB>
which is the opposite of h26x, where annexb is the raw nals
<BBB>
what was that NIH container format in ffmpeg called again? the container-equivalent of snowsonic
<Lynne>
nut?
<MaskedLeader>
no, mxf
<Lynne>
right, that one
<jamrial>
BBB: my hope is that av2 will have something like h264 annexb startcode and emulation prevention bytes, so the raw obus can be assembled
<MaskedLeader>
do not put snow and sonic into same word ever ever again!
<MaskedLeader>
snow is usable
<MaskedLeader>
sonic is crap
<BBB>
jamrial: did you propose such a mechanism to codecWG?
<jamrial>
no, i have no idea how :p
<BBB>
well then it's unlikely to change, right?
<BBB>
(I don't know either, but I hear j-b leads an organization that is a member of aomedia)
<jamrial>
is the spec already finished, or frozen?
<BBB>
tag you're it
<BBB>
I don't believe it's finished or frozen yet
<MaskedLeader>
what is entry to such high command elite community?
<BBB>
wdym?
<BBB>
you mean "how do I get in?" or "how much does it cost?" or something else?
<MaskedLeader>
organization behind av2
<jamrial>
BBB: the other suggestion would be to report max amount of tile rows and cols in sequence header (same as max dimensions), so you know them in advance and can start threading accordingly
<MaskedLeader>
how to send request or suggestions
<BBB>
if you want to learn more about aomedia, I'd recommend chatting with our very own pal
<jamrial>
which is something dav1d could have benefited from if it was in av1
<MaskedLeader>
will av2 have something like lowres, scalable resolution decoding?
<haasn>
Y corr seems worse (using yuv444p instead of rgb24 to compare)
<haasn>
that might be a result of the correlated errors in RGB space
<haasn>
interesting
<haasn>
shifting the dither matrix around slightly does improve the result
<fflogger>
[newticket] nocpu: Ticket #11482 ([ffplay] Using the shortcut key "f" does not toggle fullscreen when using ffplay) created https://trac.ffmpeg.org/ticket/11482
<haasn>
hmm
<haasn>
almost to a detriment, now I get very low luma error but much higher chroma error
<haasn>
I guess this strategy does sort of intentionally introduce color noise as the cost of lowering the brightness error
<haasn>
however, since brightness error tends to be much worse than color error maybe that's a good thign
<haasn>
I think I should port the stupid test to use SSIM instead of MSE
<MaskedLeader>
best looking at natural content at higher distance
thardin has joined #ffmpeg-devel
<kurosu>
Maybe mpeg2 had lowres decoding, and that's because it's the simplest inter codec, and it's a hack with nothing in the specs provisioning for it
<kurosu>
Spatial scalability since SVC has been the only solution for all this, and there is/has to be an overhead
ccawley2011_ has joined #ffmpeg-devel
ccawley2011__ has joined #ffmpeg-devel
ccawley2011 has quit [Ping timeout: 252 seconds]
ccawley2011 has joined #ffmpeg-devel
bhaskar has joined #ffmpeg-devel
ccawley2011_ has quit [Ping timeout: 252 seconds]
ccawley2011__ has quit [Ping timeout: 272 seconds]
<haasn>
MaskedLeader: what should the cutoff be for when to consider a SSIM drop a regression?
<haasn>
should it be percentage based or absolute? e.g. if format A has 0.937082 and format B has 0.944319 compared to ground truth
<haasn>
should I be checking SSIMB - SSIMA or SSIMB/SSIMA
<MaskedLeader>
score inside ( ) is in log scale iirc
<haasn>
so probably checking an absolute difference makes more sense
<haasn>
well, I don't see any log in the calculation actually
<MaskedLeader>
ssim_db
<BBB>
haasn: run it on a set of samples and/or conditions, measure stddev/stderr and if you're outside the range that you'd consider noise, it's a regression. you can run more formal statistics on it but generally it's quite obvious
<MaskedLeader>
log10()
Tanay has quit [Ping timeout: 276 seconds]
MaskedLeader has quit [Quit: Client closed]
MaskedLeader has joined #ffmpeg-devel
<haasn>
I will set it to 1e-4 to warn and 1e-2 to fail for now
<haasn>
1e-4 is just sensitive enough to pick up the regressions from slightly worse dithering on monow/monob and rgb8 format
<haasn>
while not warning on dither noise at higher bit depths
zeezie23 has joined #ffmpeg-devel
<haasn>
damn, the pixel range for rgba128le does not fit into AVRational
<haasn>
this kinda messes up my whole design, unless we switch to AVRational64
<haasn>
to be fair, swscale also refuses to operate on rgba128le
<haasn>
I guess I'll just ignore it for now
<MaskedLeader>
its very advanced tech
<haasn>
but it would be nice to have a 64-bit AVRational at some point
<haasn>
or I could hack around it by using an AVRational plus an explicit shift factor
bhaskar has quit [Quit: Konversation terminated!]
bhaskar has joined #ffmpeg-devel
abdu has joined #ffmpeg-devel
<MaskedLeader>
what changes avctx->trellis ?
<MaskedLeader>
for adpcm_ima_wav
<MaskedLeader>
nvm
zeezie23 has quit [Ping timeout: 240 seconds]
MaskedLeader has quit [Quit: Client closed]
devinheitmueller has joined #ffmpeg-devel
zeezie23 has joined #ffmpeg-devel
jamrial has quit [Read error: Connection reset by peer]
jamrial_ has joined #ffmpeg-devel
devinheitmuell-1 has quit [Ping timeout: 252 seconds]
jamrial_ has quit [Read error: Connection reset by peer]
jamrial has joined #ffmpeg-devel
<haasn>
kurosu: for the record, I settled on offsetting dither rows by y only, but not by x; that way it's still just an aligned avx load on the row without needing to worry about overpadding or wrapping
<haasn>
and gives good enough results
<haasn>
so loading [y & mask][i] for r, [(y + 3) & mask] for g, and [(y + 5) & mask)] for b
<haasn>
perf is maybe 10% slower but probably worth it
<haasn>
now we should switch to blue noise dither
zeezie23_ has joined #ffmpeg-devel
minimal has quit [Quit: Leaving]
zeezie23_ has quit [Quit: WeeChat 4.5.2]
zeezie23_ has joined #ffmpeg-devel
zeezie23_ is now known as zeezie01
zeezie01 has quit [Changing host]
zeezie01 has joined #ffmpeg-devel
Marth64 has joined #ffmpeg-devel
zeezie23 has quit [Remote host closed the connection]
Traneptora has quit [Read error: Connection reset by peer]
Traneptora has joined #ffmpeg-devel
abdu46 has quit [Ping timeout: 240 seconds]
bhaskar has joined #ffmpeg-devel
IndecisiveTurtle has quit [Ping timeout: 248 seconds]
ccawley2011_ has joined #ffmpeg-devel
ccawley2011_ has quit [Remote host closed the connection]
ccawley2011 has quit [Ping timeout: 252 seconds]
Traneptora has quit [Quit: Quit]
Traneptora has joined #ffmpeg-devel
HarshK23 has quit [Quit: Connection closed for inactivity]
zeezie23 has quit [Ping timeout: 244 seconds]
marware has joined #ffmpeg-devel
System_Error has quit [Remote host closed the connection]
System_Error has joined #ffmpeg-devel
zeezie23 has joined #ffmpeg-devel
ccawley2011 has joined #ffmpeg-devel
abdu69 has quit [Ping timeout: 240 seconds]
marware has quit [Quit: Client closed]
sparsh-n has joined #ffmpeg-devel
ccawley2011_ has joined #ffmpeg-devel
ccawley2011 has quit [Ping timeout: 260 seconds]
cone-811 has joined #ffmpeg-devel
<cone-811>
ffmpeg James Almer master:8e6032990cda: fftools/ffmpeg_dec: don't try to copy side data from the decoder if it already exists in the output frame