Krowl has quit [Read error: Connection reset by peer]
SystemError has quit [Remote host closed the connection]
SystemError has joined #ffmpeg-devel
Krowl has joined #ffmpeg-devel
wangbin has joined #ffmpeg-devel
Xafg has joined #ffmpeg-devel
MrZeus_ has joined #ffmpeg-devel
wangbin has quit [Quit: Connection closed]
MrZeus__ has joined #ffmpeg-devel
MrZeus_ has quit [Ping timeout: 252 seconds]
Krowl has quit [Read error: Connection reset by peer]
ccawley2011 has quit [Read error: Connection reset by peer]
ccawley2011 has joined #ffmpeg-devel
jamrial has joined #ffmpeg-devel
<thardin>
can streams have side data?
<thardin>
why is metadata not typed?
<durandal_1707>
effort
<JEEB>
thardin: streams had side data
<JEEB>
I think it was now moved to stream->codecpar
<JEEB>
(both are probably still in repo)
<haasn>
how are hevc_update_thread_context (specifically, ff_h2645_sei_ctx_replace) and ff_hevc_decode_nal_sei (specifically, ff_h2645_sei_message_decode) synchronized?
<thardin>
JEEB: context helps perhaps: this is for timecode
<haasn>
can I assume that all ff_hevc_decode_nal_sei will be called in order with no race conditions, with hevc_update_thread_context propagating H2645SEI to all other threads?
<haasn>
elenril: I mean, how do they execute in relation to each other when using threads
<haasn>
elenril: I specifically need to decode a SEI that requires access to previous frames' state
<haasn>
(stateful SEI, gotta love 'em)
<elenril>
hevc_update_thread_context() may run concurrently with the owner of the source context
<haasn>
so I'm wondering if I can just stick this state into H2645SEI and rely on it being correctly synchronized so that sei_message_decode will always see the updated state from previous frames
mkver has joined #ffmpeg-devel
<haasn>
I could alternatively thread the state into ff_h2645_sei_to_frame, but at that point in time at the latest I need the finalized values to synthesize the correct AVFrame side data
<haasn>
that seems to be run from hevc_frame_start
<nevcairiel>
assuming the SEIs are in front of slices in the packet, then they should get handled in the setup phase and be synchronized
Xaldafax has joined #ffmpeg-devel
<elenril>
When any prefix SEI NAL units are present, they shall not follow the last VCL NAL unit of the access unit.
<elenril>
NAL units having nal_unit_type equal [...] SUFFIX_SEI_NUT, [...] shall not precede the first VCL NAL unit of the coded picture.
<elenril>
our handlig seems broken then
<haasn>
nevcairiel: yeah I'm pretty sure the metadata comes at the beginning of the frame (prefix, I guess?)
<haasn>
because hevc_frame_start already sees the finalized values
<nevcairiel>
hevc_frame_start is when the setup phase ends and the parallelism starts
<haasn>
but then I don't understand why ff_h2645_sei_ctx_replace exists
<haasn>
how can anything update H2645SEI from a different thread if SEI is parsed before parallelism starts
<haasn>
ah it just copies over unregistered SEI
<nevcairiel>
thread 0 parses SEI, reaches slice data and starts working on it, at that point thread 1 starts working, copies SEI data from thread 0, parses its own stuff, reaches slice, goes working, thread 2 starts, repeat..
<haasn>
I see
<nevcairiel>
only one thread is always in the setup phase, parsing the headers of the frame, many threads can be in slice decoding of course
<nevcairiel>
so the setup is done in order and synchronized, and thread n+1 uses update_thread_context to inherit the state from thread n
dellas has joined #ffmpeg-devel
<nevcairiel>
the SEI stuff in hevc_update_thread_context is not very organized tbh, its split into so many different parts
<elenril>
that whole code seems like it will break horribly in unusual cases
<haasn>
I was wondering why hevc_sei.c copies over most SEI data but h264_sei does not
<haasn>
maybe that copying should be handled by ff_h2645_sei_ctx_replace also
Krowl has joined #ffmpeg-devel
MrZeus has joined #ffmpeg-devel
MrZeus__ has quit [Ping timeout: 272 seconds]
derpydoo has joined #ffmpeg-devel
SystemError has quit [Remote host closed the connection]
<Xafg>
Good morning, I don't know if this is the right place but I would need your help, as you know, we have many types of resolutions and aspect ratios, how can we make sure that ffpmeg converts well regardless of what type of resolution and aspect ratio?
<Xafg>
this is currently my setting but it doesn't work well if the aspect ratio is 2:40:1
<Daemon404>
also i rederived it from scratch in a talk/slies
<Daemon404>
slides*
<Daemon404>
but also the *new* CICP has my new codepoints
<Traneptora>
what are your new codepoints?
<Daemon404>
which contains a chroma-shifted ycgo-r
<Traneptora>
and what's the new CICP?
<Daemon404>
allowng it to be used in AV1 and VVC
<Daemon404>
the old CICP codepoint for ycgco-r requires different luma and chroma depths
<Daemon404>
Traneptora, ISO equivalent of 273
<Traneptora>
Daemon404: H.273 version 07/2021 mentions two formulas for YCgCo, one for same-depth and one for different
<Daemon404>
yes the latter is reversible
<Daemon404>
the former is lossy
<Daemon404>
they gated it that confusing way
<Daemon404>
the new ycgco-r codepoints are always reversible and same-depth
<Daemon404>
(theyre still draft)
<Traneptora>
wait the same-depth YCgCo transform is lossy?
<Traneptora>
do you lose a bit of precision?
<Traneptora>
that's not at all obvious
<Daemon404>
no i mean it is lossy
<Daemon404>
it doesnt have the lifting scheme applied
<Daemon404>
ycgco and ycgco-r are different transforms
<Traneptora>
oh, I see
<Traneptora>
I'm referring to YCgCo in CICP 8
<Daemon404>
but they put them under the same codepoint in a stupid way
<Traneptora>
what is the "lifting scheme?" and how is it lossy
<Daemon404>
yes the codepoint is /both/ transforms
<Traneptora>
only way an invertible linear transform is lossy is loss of precision
<Daemon404>
and it in fact it does.
<Daemon404>
thats why the reversible one needs an extra luma bit.
<Traneptora>
ah, so you go from 8bit RGB to 9bit Y 8bit CgCo?
<Daemon404>
yes
<Traneptora>
is ycgco-r, the R stands for reversible?
<Daemon404>
one sec, i will link you my talk/slides
<Daemon404>
yes.
<Traneptora>
does AV1 and VVC et. al. support different luma and chroma depth?
<Daemon404>
nope.
<Daemon404>
thats why i added those new codepoints
<Daemon404>
which are in draft atm
<Traneptora>
oh, but the new ones are reversible and same-depth, I see
<Daemon404>
it shifts the chroma up by 1 bit
<Daemon404>
yes
<Traneptora>
that's cool, I'm guessing you make it so the parity works out on reverse?
<Daemon404>
of course
<Traneptora>
noice
<Daemon404>
the main reason i wanted it was to allow avif to be less shit at rgb lossless :P
<Lynne>
oh no, different chroma bit depth
<Traneptora>
I tried encoding AVIF files by tagging planar GBR as YUV444P with matrix=0 but it tripped up most software I found
<Daemon404>
it also compresses terrbly
<Traneptora>
ye, but in particular, it straight up doesn't work
<Traneptora>
mpv, for example, doesn't invert it properly
<Traneptora>
neither does vf_libplacebo
<Daemon404>
you need to set the coepoints proprly
<Daemon404>
for rgb
<Traneptora>
the idea was I cast gbrp to yuv444p by outputting to rawvideo and then using ffmpeg -f rawvideo -pixel_format yuv444p -colorspace 0 -i ....
<Daemon404>
link to slides is in the description if you hate me face
<Daemon404>
my*
<Traneptora>
so basically you're saying that internally AV1 flags RGB by using I444 and matrix=identity
<Traneptora>
so if you tag that explicitly, stuff will get confused
<Daemon404>
no it flags it by that exact set of primaries, matrix, and trasfer + i444
<Daemon404>
not just matrix
<Traneptora>
what if you set matrix=0 primaries=709 transfer=709 format=yuv444p
<Traneptora>
will that work, in theory?
<Daemon404>
no.
<Traneptora>
no, I mean, what if you try to cheat it
<Daemon404>
it wont.
<Daemon404>
that check is in the spec an lal implementations do ti
<Daemon404>
all*
<Daemon404>
transfer MUST be srgb
<Traneptora>
Daemon404: so if the transfer isn't SRGB but the matrix is identity, and the pixel format is I444, it's an illegal file?
<Traneptora>
and is this also true about H.264?
<Daemon404>
it's not illegal but things wont pick it up as h264
<Daemon404>
er
<Daemon404>
brainfart
<Daemon404>
things wont pick it up as rgb***
<Daemon404>
and no
<Daemon404>
this is specfic to av1
<Daemon404>
Lynne, what are you looking in to ycgco-r for?
dellas has joined #ffmpeg-devel
<Traneptora>
Daemon404: there's a reverislbe YCgCo transform in the JXL spec so it's probably that?
<Traneptora>
it's one of the RCT (reversible color transforms) that are used internally for lossless
<Daemon404>
jxl uses ycgco-r, yes
<Daemon404>
iirc.
dellas has quit [Remote host closed the connection]
<JEEB>
yea and I am monitoring JVET/ITU when it gets an official identifier
<JEEB>
the drafts were pretty damn set so I could even throw a patch out there
dellas has joined #ffmpeg-devel
cone-389 has quit [Quit: transmission timeout]
Krowl has quit [Read error: Connection reset by peer]
user23 has quit [Remote host closed the connection]
user23 has joined #ffmpeg-devel
Krowl has joined #ffmpeg-devel
<durandal_1707>
Lynne: how to rount fractional to power of 2?
<durandal_1707>
*round
<BBB>
michaelni: I think people agree with how work should be done. the issue is that because it is work-for-pay, it should be decided up front
<BBB>
otherwise the money will be used as an argument in the decision-making process
<BBB>
which is not really fine
<BBB>
"you should do what I want because I'm reviewer and I can block your patch and you won't get paid muhaha"
<BBB>
not to mention labour laws
<michaelni>
money complicates things :(
<BBB>
since it's no longer volunteer work
<BBB>
yes, I agree
<BBB>
but it's important to realize because we want who-ever does this to be paid
<BBB>
I like that you're trying to move this forward btw, sws can use some love and spi has enough money for this
<BBB>
so hopefully you'll keep going until this is ready to go
<durandal_1707>
my case to port zimg to sws for 40k eur still stand
noonien has joined #ffmpeg-devel
BetweenUs has quit [Quit: Leaving]
<Lynne>
durandal_1707: fractional? a float?
<durandal_1707>
0.5 -> 0.5
<durandal_1707>
0.75 - 0.75
<durandal_1707>
0.66->0.5 ?
<Lynne>
how is 0.5 a power of two :)
<nevcairiel>
multiply by 4, round to whole number, divide again? boring sledgehammer method
<durandal_1707>
it is not
<Lynne>
you can just convert it to some limited sized integer and do it in the integer domain
<thardin>
is this still about that thing I told you there is a lossless lifting scheme for?
<durandal_1707>
thardin: yes
<durandal_1707>
that is an optimization problem and there is not single straight forward solution
<thardin>
mkay
<durandal_1707>
it is finding minimum of linear combination of 2 vectors of same lenght, so its energy/absolute sum of all elements in vector after transform is minimal
<thardin>
you mean like PCA?
<durandal_1707>
does it works with integers?
<durandal_1707>
i can not use 2x2 matrix inverse at all
<durandal_1707>
it is using affine trasformations with special matrices
<durandal_1707>
of form: { 1, a,}, { b, 1 + a *b}
<durandal_1707>
and getting inverse of that matrix is trivial
<durandal_1707>
but even if i get such matrix in code, its is not going to work, because, of this affine single step thing; the first calculated output ch is used in next calcuations of next channels
<durandal_1707>
and this is not solvable via typical NxN matrix
<thardin>
I see the inverse is just [1+ab,-a;-b,1]
<durandal_1707>
if i just copy paste that one for mono in stereo audio, i get wrong decoding
<durandal_1707>
because of that affine thing
<durandal_1707>
the output of first calculated channel is used in next calculation of next channel
Krowl has quit [Read error: Connection reset by peer]
<durandal_1707>
and IIUC there is no way to rewrite matrix to fix that
Mikhail_AMD has joined #ffmpeg-devel
<jkqxz>
Does anyone think it is ever acceptable for ffmpeg to busy wait for something?
<durandal_1707>
nope
<durandal_1707>
its hack
<Lynne>
shit hardware
<Lynne>
then it's your duty to shame them in the code
<jkqxz>
It feels like that AMF patch is the same idea as a proposal to change some locks to spinlocks with an argument that it gains slightly in wall clock time. Like, maybe that is true, but still fuck no.
___nick___ has joined #ffmpeg-devel
<philipl>
Lynne: any relevant fixes you know are in the new 545 driver?