darkapex has quit [Remote host closed the connection]
darkapex has joined #ffmpeg-devel
thilo has quit [Ping timeout: 260 seconds]
thilo has joined #ffmpeg-devel
thilo has quit [Changing host]
thilo has joined #ffmpeg-devel
cone-230 has joined #ffmpeg-devel
<cone-230>
ffmpeg James Almer master:ef01ab262713: ffprobe: print the non-diegetic stream disposition flag
<Lynne>
philipl: not again
jarthur has quit [Quit: jarthur]
wangbin has joined #ffmpeg-devel
lexano has quit [Ping timeout: 255 seconds]
lemourin is now known as Guest9946
lemourin has joined #ffmpeg-devel
Guest9946 has quit [Killed (erbium.libera.chat (Nickname regained by services))]
<philipl>
Lynne: the eternal struggle. I'll test the revert in a bit.
SystemError has joined #ffmpeg-devel
System_Error has quit [Ping timeout: 256 seconds]
tufei_ has joined #ffmpeg-devel
tufei has quit [Remote host closed the connection]
rvalue has quit [Ping timeout: 245 seconds]
rvalue has joined #ffmpeg-devel
mkver has quit [Ping timeout: 260 seconds]
<philipl>
Lynne: I've tested. The mpv revert is the right thing to do
jamrial has quit []
<Lynne>
thanks
<Lynne>
I'll have to fix chromaber_vulkan, and wonder whether to scrap using imageSize in lavfi
<Lynne>
it doesn't really hurt to say, deinterlace the padding
<philipl>
Only harmless if the deinterlacing algorithm doesn't reach into the padded area. ie: bwdif needs to use the presentation size to decide where the borders are
<Lynne>
ah, right
cone-230 has quit [Quit: transmission timeout]
MisterMinister has joined #ffmpeg-devel
qeed__ has joined #ffmpeg-devel
qeed_ has quit [Ping timeout: 240 seconds]
zsoltiv_ has quit [Ping timeout: 258 seconds]
Xaldafax has quit [Quit: Bye...]
AbleBacon has quit [Read error: Connection reset by peer]
darkapex has quit [Remote host closed the connection]
darkapex has joined #ffmpeg-devel
MrZeus_ has quit [Ping timeout: 272 seconds]
Dariusz has quit [Remote host closed the connection]
tufei__ has joined #ffmpeg-devel
tufei_ has quit [Remote host closed the connection]
durandal_1707 has quit [Ping timeout: 240 seconds]
MisterMinister has quit [Ping timeout: 260 seconds]
_av500_ has joined #ffmpeg-devel
av500 has quit [Ping timeout: 245 seconds]
_av500_ is now known as av500
dellas has joined #ffmpeg-devel
Krowl has joined #ffmpeg-devel
philipl has quit [Remote host closed the connection]
philipl has joined #ffmpeg-devel
durandal_1707 has joined #ffmpeg-devel
elastic_dog has quit [Ping timeout: 240 seconds]
elastic_dog has joined #ffmpeg-devel
tufei__ has quit [Remote host closed the connection]
tufei__ has joined #ffmpeg-devel
Krowl has quit [Read error: Connection reset by peer]
wangbin has quit [Ping timeout: 240 seconds]
qeed_ has joined #ffmpeg-devel
Krowl has joined #ffmpeg-devel
qeed__ has quit [Ping timeout: 260 seconds]
durandal_1707 has quit [Ping timeout: 248 seconds]
tufei__ has quit [Remote host closed the connection]
tufei__ has joined #ffmpeg-devel
tufei__ has quit [Remote host closed the connection]
tufei__ has joined #ffmpeg-devel
wangbin has joined #ffmpeg-devel
durandal_1707 has joined #ffmpeg-devel
cone-983 has joined #ffmpeg-devel
<cone-983>
ffmpeg Gyan Doshi master:2b300eb533a4: avfilter/vidstab: add option for file format specification
mkver has joined #ffmpeg-devel
navi has joined #ffmpeg-devel
<thardin>
durandal_1707: another thing is that rm and lm fall out of either side depending on which channel is being optimized
kurosu has joined #ffmpeg-devel
<thardin>
that is, lt or rt respectively don't change when v[0] or v[1] changes
MrZeus_ has joined #ffmpeg-devel
<thardin>
wait a sec.. won't v[0] = v[1] = 0 always minimize the problem?
durandal_1707 has quit [Ping timeout: 258 seconds]
durandal_1707 has joined #ffmpeg-devel
<durandal_1707>
thardin: so no fixed point PCA?
<thardin>
i'm just trying to understand what it tries to do
<thardin>
e needs to be invertible of course
<thardin>
so just [1 0;0 0] won't work
<thardin>
and mlp tries to predict one channel based on the other, yes?
durandal_1707 has quit [Ping timeout: 245 seconds]
<thardin>
yet afaict your code doesn't compute any residual between the predicted and actual value
tufei_ has joined #ffmpeg-devel
tufei__ has quit [Ping timeout: 256 seconds]
dellas has quit [Remote host closed the connection]
elastic_dog has quit [Ping timeout: 255 seconds]
<thardin>
the fact that it does one channel then the other makes it look like a lifting scheme
elastic_dog has joined #ffmpeg-devel
durandal_1707 has joined #ffmpeg-devel
jamrial has joined #ffmpeg-devel
<haasn>
AVCOL_SPC_RGB existing really is a nightmare
<haasn>
can we deprecate it
<haasn>
or rather
<haasn>
change its semantics
<haasn>
i.e. deprecate the usage of AVCOL_SPC_RGB for rgb pixel formats
<haasn>
in favor of this field being entirely ignored for RGB images
<haasn>
and AVCOL_SPC_RGB + yuv420p would imply a full-res G plane and two half-res R/B planes
<haasn>
as it stands AVCOL_SPC_RGB is not handled correctly by swscale or any downstream consumer I'm awre of; mpv/libplacebo just strips it
<haasn>
i.e. it assumes that yuv + AVCOL_SPC_RGB is a bug and just resets it back to UNSPECIFIED
<haasn>
afaict vf_scale does the same
<haasn>
so the proper resolution here really would be to make avcol_spc_rgb only apply identity matrix coefficients to yuv formats, not affect rgb at all, and then fix libswscale and downstream clients to treat it as such
<haasn>
and then you can also have limited range RGB by setting yuv444p + avcol_spc_rgb + avcol_range_mpeg
<haasn>
but avcol_range_* would never affect rgb pixel formats
<cone-983>
ffmpeg Andreas Rheinhardt master:ba6a5e7a3d4c: avcodec/hevcdec: Move collocated_ref to HEVCContext
<Traneptora>
mkver: how does my strlcpy patch make truncation worse?
<Traneptora>
you mentioned that on the ML, but the only time it does anything different is *if* the last byte of the buffer would be non-null
<Traneptora>
if that can't happen, then the change is semantically the same, and just suppresses a warning
<mkver>
The old code did not use the full buffer in the strncpy call, it only used one byte less so that the buffer stays \0-terminated (even on truncation).
<Traneptora>
oh, right that's the - 2 instead of - 1
<Traneptora>
so in that case the proper fix is to use av_strlcpy and change the -2 to a -1?
<mkver>
In case of truncation, av_strlcpy() would put a \0 at the end of the part of the buffer that av_strlcpy() knows about and this would then be followed by the final \0, so one less byte is actually used for the char.
<Traneptora>
I see what you mean
<mkver>
No. Your patch does not fix anything, it merely hides a warning by using a function that the compiler doesn't know.
<Traneptora>
well, if I changed the -2 to a -1 and then used av_strlcpy, it would have identical sematics but without a compiler warning
<Traneptora>
the problem is the compiler doesn't seem to realize that it's fine to use strncpy here
<mkver>
But if the warning is legitimate, then it should not be silenced.
<Traneptora>
the warning is not legitimate
<Traneptora>
the warning triggers whenever you use strncpy as it's not safe
<mkver>
So you can prove that no truncation can happen?
<Traneptora>
the warning is not that truncation occurs, but that the string wont' be null-terminated if truncation occurs
<Traneptora>
that's the lack of safety with truncation
<Traneptora>
and strncpy
<mkver>
The code is not fine just because the buffer is always zero-terminated; it is fine if no truncation can happen on valid input.
<mkver>
(And if the string is always zero-terminated even on invalid input.)
novaphoenix has quit [Quit: i quit]
<mkver>
Apart from that: This discussion should be on the ML for everyone to see.
<Traneptora>
ye, I just wanted to make sure I understood your objection
novaphoenix has joined #ffmpeg-devel
dellas has joined #ffmpeg-devel
<haasn>
wow, would you know it, adding AV_PIX_FMT_FLAG_XYZ fixed a bug
<haasn>
filters using drawutils were incorrectly accepting xyz despite putting a whitelist on flags
<JEEB>
\o/
<haasn>
because XYZ masqueraded itself as ordinary yuv
termos has joined #ffmpeg-devel
lexano has joined #ffmpeg-devel
dellas has quit [Remote host closed the connection]
<ePirat>
haasn, also drawutils iirc just explodes when init'ed with hwframes instead of failing in a predictable way…
<haasn>
heh
tufei_ has quit [Remote host closed the connection]
tufei_ has joined #ffmpeg-devel
<haasn>
we currently auto-convert from tv to pc range when converting from e.g. tv yuv420p to pc yuv420p
<haasn>
one of the consequences of range negotiation inside filters is that this logic is instead changed to preserve input range by default
<haasn>
I guess this is expected/desired
<haasn>
err, when converting from tv yuv420p to gray8
Krowl has quit [Read error: Connection reset by peer]
<haasn>
so -color_range mpeg -vf format=yuv420p,scale,format=gray8 # will now produce tv gray8 instead of pc gray8
<haasn>
but -color_range jpeg -vf format=yuv420p,scale,format=gray8 will produce pc gray8
<nevcairiel>
isnt gray considered a rgb format and thus should be full range?
<haasn>
that check seems to imply gray can have its own color range
<haasn>
but :shrug:
<haasn>
I'm torn on what the right behavior is but I think forcing gray and rgb to be color range unspecified will avoid these issues for the time being
<haasn>
and we can fix it later on, this series is already too incomprehensible
<haasn>
because of piles of such minor issues
<durandal_1707>
you are working on pile of hacks
mix_vim has quit [Quit: Leaving]
<durandal_1707>
improving it by iteratively small patches will take forever
<jamrial>
comes with the territory
<haasn>
I'm more than happy to throw away everything and redesign AVFrame metadata from the bottom up
<haasn>
can I redirect angry downstream clients your way?
<durandal_1707>
i see nothing wrong with AVFrame meatadata
<durandal_1707>
and when i say full rewrite I mean full rewrite but with compatible/same API
<durandal_1707>
currently you are just changing bikeshed color of sinking ship full of holes everywhere
<haasn>
as I explained multiple times, AVCOL_SPC_RGB is handled completely wrong/stupidly, AVCOL_RANGE_UNSPECIFIED shouldn't exist, and gray needs to be clearly documented whether it should be pc always, or respect these fields (different places in the code disagree)
<durandal_1707>
sure
<durandal_1707>
that are some of small to moderate holes in this vastly huge ship
<Lynne>
haasn: do it
<Lynne>
we can't directly rm -rf yuvj yet anyway
<Lynne>
it's been deprecated for too long while having no replacement
<haasn>
it has had a replacement always, yuv + setting color range
<nevcairiel>
which didnt work with most of the things
<nevcairiel>
its not a replacement if it doesnt replace the functionality
<haasn>
what things didn't it work with?
<nevcairiel>
if everything worked, why do you have so much work to do? :)
<haasn>
because writing new filter negotiation code from scratch is hard? I already fixed every filter to respect these tags ages ago, that was the easy part
<haasn>
in ffmpeg 6.0 every filter respects color ranges + yuv, yuvj is not strictly needed anymore for anything
<nevcairiel>
except apparently getting filters to do the right thing automatically
<nevcairiel>
hence negotiation
<haasn>
right, but the new negotiation API replaces the need for yuvj to negotiate color range conversions
<haasn>
anyway, half the work is that I insisted on adding AVColorSpace to the same negotiation API
<haasn>
because really they belong together
kekePower has joined #ffmpeg-devel
<haasn>
and now I'm met with "fun" bugs like the fact that vf_scale hard-coded "smpte170m" as AVCOL_SPC_BT470BG instead of AVCOL_SPC_SMPTE170M
<haasn>
ah
<haasn>
they are functionally equivalent, great
<haasn>
which means conversion between AVCOL_SPC_SMPTE170M and AVCOL_SPC_BT470BG will now introduce a vf_scale filter, unless I hack around it by making the negotiation code understand them to be the same thing somehow
dellas has joined #ffmpeg-devel
<haasn>
nevcairiel: also, the real thing that doesn't work is AV_PIX_FMT_GRAY*, not YUVJ
HarshK23 has quit [Quit: Connection closed for inactivity]
<haasn>
I've spent now close to 10 hours debugging issues related to range conversion between gray and yuv, which is more insane than yuvj ever was
<haasn>
but nobody documents what this format should even mean
<haasn>
so its semantics are "whatever the implementer wanted"
<Lynne>
I remember something about gray always being full-range
<haasn>
I remember something like that also but if you force gray to be full range you break half of related tests, if you force it to be limited range you break the other half
<haasn>
if you force it to respect tags, you break a third group of tests
<haasn>
if you force it to be unspecified always, it mostly works
<haasn>
for example there is a filter alphaextract which dumps alpha plane (always full range) as gray8
<haasn>
this filter should always output full range, but it doesn't
<haasn>
it's a rabbit hole
<durandal_1707>
lies
aljazmc has joined #ffmpeg-devel
<durandal_1707>
gray8 can be any range
<haasn>
I agree, so we should avoid forcing any range
<haasn>
maybe I should bite the bullet and fix all of the filters that handle gray8 first
<durandal_1707>
what filters does it wrong?
<durandal_1707>
many filters do not care and others assume limited range
<durandal_1707>
like most filter assumy yuv is limited
<durandal_1707>
and there is no special case for full ones
aljazmc has quit [Remote host closed the connection]
cone-983 has quit [Quit: transmission timeout]
HarshK23 has joined #ffmpeg-devel
Mikhail_AMD has quit [Quit: Konversation terminated!]
dellas has quit [Remote host closed the connection]
tufei_ has quit [Remote host closed the connection]
tufei_ has joined #ffmpeg-devel
SystemError has quit [Remote host closed the connection]
SystemError has joined #ffmpeg-devel
___nick___ has joined #ffmpeg-devel
mkver has quit [Ping timeout: 255 seconds]
<Lynne>
haasn: if you force it to respect tags?
<Lynne>
colorspace/matrix/prims?
dellas has joined #ffmpeg-devel
MrZeus_ has quit [Ping timeout: 245 seconds]
dellas has quit [Remote host closed the connection]
<durandal_1707>
Many developers no longer live with their parents.
<durandal_1707>
this means sometime in past, many developers indeed lived with their parents.
<haasn>
well, it boils down to vf_scale resetting color range on any conversion between yuv and gray
dellas has joined #ffmpeg-devel
<haasn>
it's not so much that filters break, but that test cases break, because they all encode the existing behavior
<haasn>
I think the first step is to make vf_scale not convert color range for yuv->yuv conversions
<haasn>
and then update all tests
<haasn>
and then add filter negotiation when the behavior is sane and consistent
mkver has joined #ffmpeg-devel
Krowl has quit [Read error: Connection reset by peer]
MrZeus_ has joined #ffmpeg-devel
taniey has quit [Ping timeout: 258 seconds]
taniey has joined #ffmpeg-devel
AbleBacon has joined #ffmpeg-devel
averne has quit [Ping timeout: 240 seconds]
qeed_ has quit [Quit: qeed_]
qeed has joined #ffmpeg-devel
<haasn>
the "Remove YUVJ" series has turned into the "Fix grayscale formats" series...
<haasn>
the only fate tests I keep breaking are all of the grayscale ones, everything yuvj related was 5 seconds
<Lynne>
I do agree that grayscale can be limited range though, because extracting a plane from yuv as grayscale should be possible
<haasn>
exactly
<haasn>
extractplanes is actually the perfect poster child of why we need range negotiation for grayscale as well
<haasn>
because we want to extract the alpha plane as full range gray and the y/u/v planes as limited gran gray (or full range, depending on the src)
<haasn>
so we set the main outputs to the same avfilterformats list as the input, while setting the alpha plane output specifically to only full range
<courmisch>
Lynne: [RVV board] has departed from the country of origin
<courmisch>
hopefully it doesn't get lost in Mordorland on the way
<haasn>
swscale forces gray to be full range in sws_init_context though
<haasn>
needs fixing also.. grr
mkver has quit [Ping timeout: 252 seconds]
<haasn>
how do we feel about regressing individual fate tests temporarily as part of a refactor series?
<haasn>
it's almost impossible to commute these commits into an order that will make fate pass on every commit, without squashing the whole thing into an uberpatch
<haasn>
because of cyclic dependencies
<haasn>
I could just commit the individual fate failures into the relevant commits, to be cleaned up later
<haasn>
or I could just ignore them and deal with fate breaking if somebody's bisect happens to land on exactly that commit
MrZeus has joined #ffmpeg-devel
MrZeus_ has quit [Ping timeout: 264 seconds]
<Lynne>
courmisch: what do you mean?
<Lynne>
oh, a development board, I read that as risc-v consortium/board/whatever
<courmisch>
I suppose it'll go via some stan country then central Europe then Lithuania so it's still a while
SystemError has quit [Remote host closed the connection]
<Lynne>
wonder how hacked up their kernel is
<Lynne>
wonder if the mainline kernel will even support it, given that it doesn't yet have support for different CPUs having different extension ISAs
<Lynne>
I take mainline kernel support for granted these days, but I remember back when the odroid c2, let alone all RPI versions were stuck on 2.6+patches
<courmisch>
it's entirely possible that they didn't enable V in the kernel or that they just turned off the second core with some hack
<Lynne>
I'd want my money back if that is the case, but I'm guessing they either don't report rvv support, but if you pin to core 0 and give it rvv instructions, it'll run them
<courmisch>
this is nothing but a stop gap
<courmisch>
the worst part isn't even the CPU but the RAM
<Lynne>
is it? 512mb is enough to open nvim these days, and enough to compile C
<courmisch>
it's not enough to do multimedia
<Lynne>
but yeah, on an SoC, these days, that's not a lot, even the very first RPI came with 512 more than 10 years ago
<courmisch>
I ain't running FATE on that one
<Lynne>
should be enough to run it on a single core?
<Lynne>
ah, maybe not, 16 ref h264 1080p plus filtering will probably OOM it
<elenril>
haasn: i wouldn't object to a commit temporarily disabling a test
<elenril>
just comment it out in its .mak, that's better than having it outright broken
<haasn>
Good idea
<haasn>
And easier to verify
mkver has joined #ffmpeg-devel
wangbin has quit [Quit: Ping timeout (120 seconds)]