<Daemon404>
sounds like someone misnamed it but they csn never remove it
<Daemon404>
can*
<JEEB>
also I just worked with someone with regards to vaapi av1 encoding, and the logging for attribute check failures in that module is abhorrent. apparently there is a function to get the string of the attribute so I might just throw a patch for that so someone reading the warnings/errors actually could understand WTF is going on
<JEEB>
https://pastebin.com/wQGrv183 ctrl+F "Attribute type" and then the "Failed to query config attribute" one which has a classic case of "success (no error)" on error xD
<haasn>
and why does it set the V chroma loc to a different value than the U chroma loc?
ccawley2011 has joined #ffmpeg-devel
<haasn>
surely 4:2:0 U/V planes are identically sized and chroma samples are co-sited?
<haasn>
oh, nvm, I see, there's a conditional `break;` at the end of the loop
<haasn>
and it doesn't loop over planes, it loops over swscale configs
<haasn>
okay, my confusion is cleared up
Krowl has quit [Read error: Connection reset by peer]
<haasn>
I still feel like we should set these fields from the in->chroma_location
mkver has joined #ffmpeg-devel
<haasn>
kierank: given a value of in_v_chr_pos for luma, the first field should see in_v_chr_pos >> 1 and the second field should see (in_v_chr_pos >> 1) + 128?
<haasn>
s/for luma/for progressive/
<kierank>
haasn: honestly, it's swscale, it's only michaelni who can answer and at the time I asked him and he explained what to do
<haasn>
heh
<haasn>
I'm not sure how to extend this logic to cover other subsampling modes, like 4:2:2
<kierank>
iirc for mpeg progressive is cosited so this is not needed
<haasn>
but I can at the very least generalize it to 4:2:0 + other chroma location
<kierank>
the annoying part is the sample clip that is on the ticket is not there any more
<kierank>
because that showed the issue really clearly
<haasn>
I wonder if archive.org has it
navi has joined #ffmpeg-devel
<kierank>
I'm sure my old laptop backups have it somewhere
<kierank>
will look later
<haasn>
I want to clean this code up so much but it would amount to rewriting vf_sacle
<haasn>
ah, sadly, config_props doesn't see chroma location
<haasn>
so I guess this is something to do after filter negotiation is extended
<haasn>
probably we should apply this logic to all formats that have log2_chroma_h == 1
cone-796 has joined #ffmpeg-devel
<cone-796>
ffmpeg Andreas Rheinhardt master:8e1bb594fb36: avcodec/h264idct_template: Don't include h264dec.h
<cone-796>
ffmpeg Andreas Rheinhardt master:4e6cf5e52b4b: avcodec/h264dec: Constify H.264 decoder
<haasn>
michaelni: I'd appreciate it if you could take a quick look at https://0x0.st/H4JO.txt
<haasn>
and tell me if I'm on the right track here
Krowl has joined #ffmpeg-devel
<haasn>
hmm, it regresses fate-sws-yuv-range, because it now assumes the input is mpeg2 sited while it seems like rawvideo defaults to center siting when it's unspecified?
<nevcairiel>
if you can make a good argument for the change, its not necessarily a regression
<haasn>
or rather, y4m hard-codes C420jpeg for AVCHROMA_LOC_CENTER
<haasn>
AVCHROMA_LOC_UNSPECIFIED*
<haasn>
strange
<haasn>
mpv handles unspecified chroma loc as left/center based on signal range (full vs limited)
<haasn>
yuv4mpegenc handles unspecified chroma loc as center always
<haasn>
seems like swscale also handles unspecified chroma loc as center
<haasn>
and finally, libplacebo handles unspecified chroma loc as left always
<haasn>
....
<haasn>
vf_zscale handles unspecified as left always, too
<haasn>
god knows what scale_vulkan/vaapi do
<haasn>
probably the safest thing to do is to just not touch this logic and hope nobody ever finds out
<haasn>
no good deed goes unpunished
dellas has quit [Remote host closed the connection]
<haasn>
should conversion from rgb24 to yuv420p output tv or pc range by default?
<haasn>
I guess probably tv range
<haasn>
but an argument can be made for pc range because it reduces quality loss
<kierank>
you will not please everyone
<JEEB>
most YCbCr usage is limited range so the default for both ingest and output should probably be limited unless specified otherwise
Mikhail_AMD has joined #ffmpeg-devel
<haasn>
yeah gating out_range = in_range behind if (in->pixfmt == out->pixfmt) seems to work
<haasn>
and is probably the safest option
<haasn>
this does have the side effect that e.g. conversion from full range yuv444p to yuv420p will produce limited range output unless vf_scale is instructed otherwise
<haasn>
but that's the current status quo anyways
<Lynne>
whatever you think scale_vulkan does, it doesn't
<haasn>
huh.. VLC seems to ignore chroma location entirely and always sample centered?
<haasn>
that can't be right
<haasn>
wouldn't that result in wrong output for practically all content out there?
<Daemon404>
it'd be right for jpeg!
<haasn>
can confirm, vlc produces different output from mpv for basically all files
<haasn>
due to chroma shift from left->center
<elenril>
we don't have 10bit NV12, right?
<haasn>
j-b: this is an international incident!
<haasn>
elenril: P010
<elenril>
(not p010)
<Daemon404>
lol
<Lynne>
haasn: he can't hear you over the sound of jet engines in the troposphere
<haasn>
if you mean a format like p010 but with data in the low bits instead of the high bits, no
<kasper93>
haasn: not enough color autism were devoted to VLC it seems
<haasn>
afaict it doesn't exist
<elenril>
x264 uses it internally
<elenril>
and can output it in some cases
<elenril>
Lynne: another hwaccel framework?
<elenril>
seriously?
<kasper93>
haasn: Also for default conversion, I would expect to least quality degrading one, unless users requests, but I agree with current status quo of everything being limited in fact
<Lynne>
elenril: yyyup, if it turns out to use amf underneath I'd definitely belive it
<durandal_1707>
Lynne: tx status, please!
<Lynne>
writing channel layout and making a spec to C parser (in perl!), should finish it tonight
<Lynne>
after that I'll take a look at lavu/tx
<durandal_1707>
Lynne: of what layout?
<Lynne>
avtransport, for both
<Lynne>
of course, I'm just copying the lavu mechanism, it's good enough and defines plenty
<durandal_1707>
fixed-point linear equations minimization
<durandal_1707>
anybody knows about that stuff?
Krowl has quit [Read error: Connection reset by peer]
<durandal_1707>
well, TrueHD can at most put four normal channels in single substream
Mikhail_AMD has quit [Ping timeout: 258 seconds]
<kierank>
15:05:19 <BA1719• elenril> we don't have 10bit NV12, right?
<kierank>
We do
<kierank>
NV20 or something
<BtbN>
P010 iirc
<elenril>
NV20 is 422
<kierank>
ok
<Lynne>
yeah, it's p010
<elenril>
i wish you people would learn to read
<Daemon404>
you never explained why p010 isnt 'correct'
<elenril>
because i want to describe the thing x264 outputs
<Daemon404>
you never confirmed how it differs from p010
<elenril>
data in the low bits
<Daemon404>
then you need to add a new pix fmt, nothing else uses such a format
<kierank>
where is p010 defined as data in high bits
<BtbN>
What n venc does is just use P016 for that case
<elenril>
AV_PIX_FMT_P010LE, ///< like NV12, with 10bpp per component, data in the high bits, zeros in the low bits, little-endian