dellas has quit [Remote host closed the connection]
System_Error has quit [Remote host closed the connection]
System_Error has joined #ffmpeg-devel
lemourin has quit [Read error: Connection reset by peer]
lemourin0 has joined #ffmpeg-devel
lemourin0 is now known as lemourin
wangbin has joined #ffmpeg-devel
mkver has quit [Ping timeout: 255 seconds]
jamrial has quit []
paulk-bis has quit [Remote host closed the connection]
MisterMinister has quit [Remote host closed the connection]
ZeroWalker has joined #ffmpeg-devel
rvalue has quit [Read error: Connection reset by peer]
rvalue has joined #ffmpeg-devel
rooisnoek has joined #ffmpeg-devel
wangbin has quit [Quit: Connection closed]
MisterMinister has joined #ffmpeg-devel
wyatt8740 has joined #ffmpeg-devel
wyatt8750 has quit [Ping timeout: 255 seconds]
kurosu has joined #ffmpeg-devel
taniey has joined #ffmpeg-devel
rooisnoek has quit [Quit: Leaving]
MrZeus__ has quit [Ping timeout: 246 seconds]
MisterMinister has quit [Ping timeout: 258 seconds]
AbleBacon has quit [Read error: Connection reset by peer]
durandal_1707 has joined #ffmpeg-devel
sepro has joined #ffmpeg-devel
rvalue has quit [Read error: Connection reset by peer]
rvalue has joined #ffmpeg-devel
Krowl has joined #ffmpeg-devel
MrZeus__ has joined #ffmpeg-devel
wangbin has joined #ffmpeg-devel
taniey has quit [Ping timeout: 255 seconds]
taniey has joined #ffmpeg-devel
navi has joined #ffmpeg-devel
MrZeus_ has joined #ffmpeg-devel
MrZeus__ has quit [Ping timeout: 248 seconds]
Krowl has quit [Read error: Connection reset by peer]
Krowl has joined #ffmpeg-devel
ZeroWalker has quit [Quit: Leaving]
<haasn>
does anybody here know if there's a good current-ish-gen CPU not costing half a kidney with at least ~40 PCIe lanes?
Krowl has quit [Read error: Connection reset by peer]
<haasn>
seems like the AMD threadripper series is still the most affordable way to get this
<haasn>
but the current cheapest threadripper is priced at 2.5k+
<haasn>
when in the past these used to cost a much more reasonable <1k eurs
<JEEB>
even the most recently announced zen4 threadrippers?
<durandal_1707>
sell ffmpeg for kidney
<haasn>
ah, previous gen threadripper PRO is quite affordable
<haasn>
e.g. Zen 3 AMD Ryzen Threadripper PRO 5955WX listed for ~1k
<durandal_1707>
ffmpeg devs cant afford hw
<durandal_1707>
prices too high and paycheck still 0$
<nevcairiel>
AMD hasnt had consumer threadrippers for a while, so they got expensive, only the PRO series, and intel also got out of that segment
<nevcairiel>
new threadrippers were announced including consumer ones, but prices increased since Ryzen already goes up to 16 cores and all
<durandal_1707>
only 16 cores? 64 cores is minimum
<haasn>
cores aren't all that useful, I care more about latency and PCIe lanes
<haasn>
and of course ECC memory
mkver has joined #ffmpeg-devel
<haasn>
so I guess that pretty much locks me into waiting for affordable threadrippers
<JEEB>
yea, ECC memory at this point is also for me a "why would I not have that?" thing, given that the prices are sane and nowadays there are some faster sped sticks as well
<JEEB>
although 3200MHz was fine for me for DDR4
<Gramner>
the new zen4 tr 7960X with 24 cores, 48 pcie-lanes, and quad-channel ddr5 ecc rdimm is $1499. whether or not that is affordable is up to the buyer
<haasn>
I have 2734 MT/s apparently
<BtbN>
ECC RAM is still quite a bit slower than non-ECC
<BtbN>
And a lot of desktop boards don't support it
<haasn>
Gramner: 2.5k here in .de
<Gramner>
there is fast ddr5 ecc rdmimms available nowadays
<BtbN>
Pretty sure mine doesn't. It works with ECC RAM, but the ECC functionality is defunct
<haasn>
maybe I can buy one when I visit the US and take it back in my cargo
<BtbN>
DDR5-7200 fast?
<Gramner>
iirc 6800 exists at least, dunno if there are faster ones
<BtbN>
6800 is pretty decent. But that's not something you can plug into a desktop, given it's RDIMM, I assume?
jamrial has joined #ffmpeg-devel
<Gramner>
yeah, rdimm have different pinouts. they're used for intel and amd workstation platforms though
<nevcairiel>
TR Pro has 8 memory channels with RDIMM, the platform cost is already quite substantial
<BtbN>
I think RDIMM also has higher latency, so the preceived performance might go down with it
<nevcairiel>
it does have higher latency, but it supports much higher capacities, which is kind of the design goal of those platforms
<JEEB>
level1 techs thing went over some faster DDR5 ECC DIMMs, not sure if those were RDIMM or not
<nevcairiel>
you can get ECC UDIMMs working on some platforms
<nevcairiel>
but thats for Ryzen only, at least all the new Threadripper are RDIMM platforms
<nevcairiel>
both pro and non-pro
<JEEB>
yea
MrZeus__ has joined #ffmpeg-devel
MrZeus_ has quit [Ping timeout: 272 seconds]
Krowl has joined #ffmpeg-devel
MrZeus__ has quit [Ping timeout: 255 seconds]
Traneptora has quit [Quit: Quit]
Xaldafax has joined #ffmpeg-devel
lexano has joined #ffmpeg-devel
dellas has joined #ffmpeg-devel
durandal_1707 has quit [Remote host closed the connection]
dellas has quit [Remote host closed the connection]
cone-693 has joined #ffmpeg-devel
<cone-693>
ffmpeg James Almer master:3c5bceb75189: avformat/options: add missing disposition flag to AVStream class options
<haasn>
how should we handle AVCOL_RANGE_UNSPECIFIED in post-YUVJ world? in the past, UNSPECIFIED + yuv420p was treated as TV, UNSPECIFIED + yuvj420p was treated as PC range
<haasn>
the current behavior which I implemented is to treat unspecified as imposing no restriction at all, so an input frame with unspecified color space (e.g. rawvideo) would get treated as either tv or pc range depending on downstream filter requirements
<haasn>
this could be justified as expected behavior - if you input rawvideo without specifying color range, we make no assumption about color range and skip auto-converting
<haasn>
e.g. ffmpeg -f rawvideo -i input output.jpeg # should this insert auto-conversion from TV to PC range by default?
<haasn>
or should it assume the raw data is already in the correct yuv format, unless you specify -color_range before the input?
<JEEB>
I think there's two ways of interpreting that. just like video renderers also tend to make assumptions.
<JEEB>
unknown YCbCr -> limited, unknown RGB -> full. is a thing I've seen. this would require a warning IMO when the chain initializes.
<haasn>
a bit hard to find a good place to implement that logic
<haasn>
but it would probably be something fftools should be doing, not ffmpeg
<JEEB>
if it's just for conversion cases, you pass things through since it's unknown. but you should still warn about it.
<JEEB>
yea, it could be in fftools
<JEEB>
underlying library could be stricter
<JEEB>
I should check what zimg does if you feed it an unknown YCbCr frame and only set the matrix when you are doing a YCbCr to RGB conversion
tufei has quit [Remote host closed the connection]
<JEEB>
I just wouldn't be surprised if in such a conversion case it would be doing the limited -> full conversion
<JEEB>
if you put it before input it does affect the avctx
<haasn>
so the only way to do this currently is vf_format
<haasn>
oh
<JEEB>
and there is also a filter to set specifics
<JEEB>
vf_setparams
tufei 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]
<nevcairiel>
an encoder that has strict range requirements should probably expect it to be set, afterall it expected yuvj before, which someone must have set somewhere to indicate full range
<nevcairiel>
if the input is yuv unspecified, it should probably be assumed limited and converted by fftools
<nevcairiel>
its what would happen now, right?
<haasn>
that's what would happen right now, yes
<haasn>
I don't know, I have mixed feelings
<haasn>
what's the point of unspecified existing if it's functionally equivalent to tv
<haasn>
might as well just set all frames to tv by default
<nevcairiel>
it just maps the values from the specifications, want to be able to convey the difference about being explicit or not
<nevcairiel>
but you need to assume something for unspecific, and limited is just the right answer 99% of the time
AbleBacon has joined #ffmpeg-devel
<haasn>
what's the name of the ITU specification again that defines these values?
<haasn>
I would be surprised if AVColorRange is actually included in any spec as-is
<JEEB>
the limited/full range stuff?
<JEEB>
BT.2100
<JEEB>
that actually contains full range definition
<JEEB>
(I actually noted that in the AVColorRange doxy)
<JEEB>
xD
<JEEB>
H.273 aka CICP then contains all the matrix/primaries etc things
<JEEB>
(although range might be there as well, E_NOT_SURE)
<haasn>
wtf since when does the itu-r website require login to download pdfs
<JEEB>
only for pre-publishing
<JEEB>
so the first 6 months of publishing
<haasn>
" Locked Document restricted to TIES users [ITU-T] "
<JEEB>
yea, it's dumb but at least it becomes fully available
<haasn>
well, these specs confirm what I was saying
<haasn>
which is that AVCOL_RANGE_* values are arbitrary, in reality there is only a VideoFullRangeFlag or w/e that you have in various codecs
<haasn>
and it usually only applies to YUV
<haasn>
and AVCOL_RANGE_UNSPECIFIED should be -1, with TV being 0 and PC being 1 tbh
<haasn>
and these fields explicitly ignored for non-YUV (that's the behavior I'm implementing in my branch anyway, because csp/range fields have no meaning for non-yuv)
Krowl has joined #ffmpeg-devel
MrZeus has joined #ffmpeg-devel
<JEEB>
I don't think any of the ISO formats that have full range flag actually care which matrix is set? but I don't disagree with not wanting to deal with range flags and RGB since it's not really a thing outside of signals over the wire
mcfrdy has quit [Quit: quit]
mcfrdy has joined #ffmpeg-devel
<JEEB>
OK, as I kind of had a feeling in the back of my head, the mapping file causes the wrong e-mail get utilized since I just got the vote e-mail to the e-mail that is not "JEEB, part of the community e-mail"
<JEEB>
I guess either swapping that around, or removing. as anyways that specific email would never, ever commit anything :)
<nevcairiel>
I have seen RGB files with range, even if some people will tell you it doesnt exist, but it does :shrug:
<JEEB>
yea I try to waltz around that theme since there are people who are rather vocal about their opinion on the matter and thus as my care level for it is low enough. :)
durandal_1707 has joined #ffmpeg-devel
<haasn>
I really question whether AVCOL_*_UNSPECIFIED should be considered a valid value at all, inside the filter chain
<haasn>
but meh
<haasn>
probably more conservative to let it be valid
<nevcairiel>
many filters just dont care at all
<haasn>
so should we introduce AVCOL_SPC_NONE = -1 to terminate lists of AVColorSpace in a natural way
<haasn>
I previously used AVCOL_SPC_UNSPECIFIED as the terminator but if we make that be a "valid" value we need a new terminator
<haasn>
it really is annoying to have both AVCOL_SPC_NONE and AVCOL_SPC_UNSPECIFIED, but it is also really annoying to treat UNSPECIFIED as a valid value
<haasn>
to be honest my 2 cts here are that we should force all values to be specified
<haasn>
filters that don't care about the value can continue not caring, while filters that do care about the value shouldn't reinvent some sort of auto-guessing logic every time
<elenril>
force how and where?
<nevcairiel>
files can be unspecified, files can be explicit limited or full, i dont think its reaonable to lose that distinction
<nevcairiel>
it may not make a difference for filtering
<nevcairiel>
but does for other things
<elenril>
see lavf pts guessing code as a warning for what not to do
<nevcairiel>
avcodec should just export stream information as close to the original as possible
<nevcairiel>
interpretation can be done in other layers
<elenril>
sigh, once again I look at this garbage and once again I have no idea what it does or what it's for
<haasn>
elenril: inside avfilter, should we allow passing frames with unspecified colorimetry metadata if that colorimetry metadata becomes part of format negotiation
<elenril>
I'm fine with disallowing unspecified inside lavfi
Teukka has quit [Ping timeout: 258 seconds]
<elenril>
what I'm less fine with is losing the abilitity to represent it at all in AVFrame
<haasn>
fair
<haasn>
incidentally
<haasn>
in vf_scale.c: int frame_changed = in->width != link->w || ...
<haasn>
how can the frame passed to filter_frame possibly differ from the link width?
<haasn>
isn't the whole point of having the width and format explicitly configured on the link to avoid frames suddenly changing in size or format mid-stream?
<elenril>
there are some bits and pieces in random places anticipating the possibility of dynamic parameter changes
<elenril>
some of them make less sense than others
<durandal_1707>
stay away from code you do not understand!
<elenril>
durandal_1707: fix af_amix
<durandal_1707>
what?
<durandal_1707>
it works fine
<durandal_1707>
if it is broken by new hacks, its hacks problems.
<durandal_1707>
forward status back all - signals all filters receiving frames before current filter
<elenril>
first input closes at 88200, at that time the second input is at 88064 but is not closed yet
<elenril>
still the filtergraph terminates at 88064
<elenril>
plsfix kthx
<kurosu>
haasn: JEEB: are you missing the info from the document, or are you commenting it is now behind a paywall ?
MisterMinister has joined #ffmpeg-devel
<elenril>
16:38:15 durandal_1707 | forward status back all - signals all filters receiving frames before current filter
<elenril>
why does the filter need to do that
<kurosu>
(cont) And is there an expectation that the changes from the public 21/07 version are the things you would need to look at?
aljazmc has quit [Quit: Leaving]
<haasn>
half of the work of YUVJ removal is rewriting vf_scale
<haasn>
while preserving all the bugs^Wspecial cases
<durandal_1707>
elenril: because other filters know when to eof
<haasn>
such as the hilarious fact that we now pick BT.709 as default YUV matrix instead of BT.601 because the avfilter link negotiation code just picks the numerically first colorspace from the intersection of {all color spaces} x {all color spaces supported by swscale}
<haasn>
whereas swscale used to default to bt.601 for all conversions unless specified otherwwise
mkver has quit [Ping timeout: 255 seconds]
<durandal_1707>
why changing defaults helps at all?
<haasn>
hmm, I think explicit format tagging causes too many problems, better to allow unspecified to exist after all
<Lynne>
add a warning, we could fix places where it's unspec and it shouldn't be
dellas has joined #ffmpeg-devel
cone-693 has quit [Quit: transmission timeout]
<JEEB>
kurosu: in this specific case I know that it would just confirm some new values I've seen being drafted in JVET :)
<JEEB>
but I'm more or less fine with the 6 months case, it's just kinda dumb (in my humble opinion)
<JEEB>
if someone could tell me whether the values indeed ended up being published exactly like the last draft, that would technically be enough for me :P
<JEEB>
but yea, there's just a few new color values being defined
<JEEB>
and I'd like to understand if they indeed specified the ones listed in the drafts (since they already apparently reordered them during the draft process)
HarshK23 has quit [Quit: Connection closed for inactivity]
Krowl has quit [Read error: Connection reset by peer]
<Lynne>
elenril: do you have more comments about the vulkan_decode coded dimensions patch?
<haasn>
why does ff_yuv2rgb_coeffs[AVCOL_SPC_RGB] contain BT.709 yuv matrix
<haasn>
why does AVCOL_SPC_RGB even exist
<haasn>
why does setting swscale yuv2rgb and rgb2yuv matrix affect rgb->rgb output
<JEEB>
the latter is simpler to answer
<JEEB>
AVCOL_SPC_RGB exists because those things are H.273 values
<haasn>
why do I get non-lossless results from swscale scaling rgb to rgb when setting the coefficients to sws_getCoefficients(AVCOL_SPC_RGB) (as opposed to not touching them)
<JEEB>
even though we have RGB and XYZ pix_fmts
<JEEB>
8)
<haasn>
then ff_yuv2rgb_coeffs is clearly wrong
<JEEB>
I'm not surprised at all. I wonder how many people actually know what the swscale colorspace things are supposed to be. matrix? primaries? or both?
<DeHackEd>
I feel strange asking this but... since the MP4 (de)muxers support encryption, would a patch that adds "DRM" support to MP4 and/or DASH be accepted?
<DeHackEd>
there is a "DRM" scheme defined called ClearKey which is little more than a URL included in stream metadata specifying a HTTPS server that should give you the decryption key if you ask it
bcheng has joined #ffmpeg-devel
<JEEB>
DeHackEd: that's not DRM, that's clear key encryption. it's already supported in HLS so I wouldn't be opposed to it in DASH
<DeHackEd>
well, for my use case, the implementation would be vague enough that you could do encryption using other DRM providers, but clearkey would absolutely be supported in both directions
<DeHackEd>
cool
<Lynne>
why would anyone design such a monstrosity?
<haasn>
does anybody have even the slightest clue what the color range inside a pgmyuv file is supposed to be?
<haasn>
this is such a codec that currently returns unspecified
<haasn>
probably it's supposed to be limited range, given its historic hard-coding of yuv formats when yuvj was the only way to distinguish it from full range
<haasn>
Lynne: CDN, presumably
<haasn>
put encrypted file onto public CDN, put your access control logic on weak server
<JEEB>
yea, key is usually in some manner authenticated
jarthur has joined #ffmpeg-devel
<haasn>
huh
<haasn>
yuvj removal uncovered a "bug" in a fate test
<elenril>
of course it did
<haasn>
fate-flv-add_keyframe_index produced a frame that was somehow visually degraded compared to the result after yuvj removal
<haasn>
in hard-to-describe ways
<haasn>
I blame swscale
<JEEB>
\o/
wangbin has quit [Quit: Connection closed]
<haasn>
already at 24 patches :(
<elenril>
more commits - more adidas
<haasn>
more voting rights
<haasn>
securing my bid in the GA/TC
<durandal_1707>
more commits, less elenril
<quietvoid>
has anyone tried building docs with latest texinfo, 7.1
<quietvoid>
it appears to be broken for me
<JEEB>
quietvoid: if it's > makeinfo: warning: error loading ./src/doc/t2h.pm: Undefined subroutine &Texinfo::Config::set_from_init_file called at ./src/doc/t2h.pm line 24.
<quietvoid>
yea
<JEEB>
then that has been known to be broken for a while
<quietvoid>
ah ok
<JEEB>
not sure if there was a patch ever posted that would enable both the old and new interface to work
<elenril>
durandal_1707: no, does not fix the problem
<JEEB>
nor do I know how possible it would be
<quietvoid>
arch just updated so i guess i have to disable docs
<quietvoid>
JEEB: though for me it's not a warning so make stops
<JEEB>
oh, so /another/ change? :D
<JEEB>
because arch updated to the warning version quite a while ago
<quietvoid>
arch went from 7.0.3 to 7.1
<quietvoid>
i thought maybe master would work but it appears not, so for now i can --disable-htmlpages
<Lynne>
going to push the vulkan coded width patch and the two validation fixes in a few hours
<DeHackEd>
Lynne: by "monstrosity" you mean my DRM Thing ?
<Lynne>
it's not really DRM, but it's blurring the line
<Lynne>
I've ran into something like this on nicovideo, was wondering why the demuxers was complaining the key suddenly expired
<JEEB>
it's the DASH equivalent to EXT-X-KEY entry in a HLS playlist
<JEEB>
yea nicovideo has a keepalive system
<JEEB>
you need to periodically tell it you're still watching
<JEEB>
at least looking at the yt-dlp output
<Lynne>
yeah, they only provide the key only once to you, so you can't scrape it
<durandal_1707>
elenril: i can not reproduce it
<Lynne>
I had to open firefox's debug menu, set a very low speed limit, such that I'd have time to get the manifest with a good key, but not let the browser open it
<DeHackEd>
yeah, and I know of some actual, fully fledged DRM systems implemented as otherwise conforming HLS. Just that the key server might turn you away
<elenril>
durandal_1707: it's easier to trigger under load
<elenril>
but should happen often enough in any conditions
<durandal_1707>
thardin: the least squares solution using matrices is heavy on doubles and i prefer fixed numbers
<durandal_1707>
even though same least squares are used as part in IIR coefficients approximations
<durandal_1707>
but using least squares for IIR (and maybe even for rematrix case) is bloated, as in both cases coefficients are of very limited precision
<durandal_1707>
more compression gains may be done by writing IIR code, i may use few typical presets here too as max order of IIR filters used is 3 (nb numerators + nb denominators <= 8)
<thardin>
you don't need doubles
<durandal_1707>
need to use sqrt
<durandal_1707>
for normalizations
<thardin>
pretty sure you don't
<thardin>
lsq often reduces to a problem on the form A'Ax = b
<durandal_1707>
used QR decomposition
<thardin>
A'A here being a 2x2 matrix. so x is a rational number
<thardin>
might not fit in 64 bits though. might need gnu mp