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.0.1 has been released! | Please read ffmpeg.org/developer.html#Code-of-conduct
thilo has quit [Ping timeout: 256 seconds]
thilo has joined #ffmpeg-devel
thilo has quit [Changing host]
thilo has joined #ffmpeg-devel
sudden has quit [Ping timeout: 255 seconds]
sudden has joined #ffmpeg-devel
mkver has quit [Ping timeout: 260 seconds]
lexano has quit [Ping timeout: 256 seconds]
j45_ has joined #ffmpeg-devel
j45 has quit [Ping timeout: 260 seconds]
j45_ is now known as j45
j45 has quit [Changing host]
j45 has joined #ffmpeg-devel
asenat has quit [Quit: Client closed]
Kei_N_ has joined #ffmpeg-devel
Kei_N has quit [Read error: Connection reset by peer]
aaabbb has quit [Read error: Connection reset by peer]
aaabbb has joined #ffmpeg-devel
arch1t3cht0 has joined #ffmpeg-devel
arch1t3cht has quit [Ping timeout: 255 seconds]
arch1t3cht0 is now known as arch1t3cht
\\Mr_C\\ has quit [Remote host closed the connection]
jamrial has quit []
philipl has quit [Quit: leaving]
philipl has joined #ffmpeg-devel
Martchus_ has joined #ffmpeg-devel
Martchus has quit [Ping timeout: 268 seconds]
vtorri_ has joined #ffmpeg-devel
vtorri has quit [Ping timeout: 256 seconds]
vtorri_ has quit [Remote host closed the connection]
vtorri_ has joined #ffmpeg-devel
Warcop has quit [Remote host closed the connection]
vtorri_ has quit [Ping timeout: 268 seconds]
vtorri_ has joined #ffmpeg-devel
AbleBacon has quit [Read error: Connection reset by peer]
vtorri_ has quit [Ping timeout: 268 seconds]
vtorri_ has joined #ffmpeg-devel
cone-011 has joined #ffmpeg-devel
<cone-011>
ffmpeg Brad Smith master:41190da9e11f: aarch64: Add OpenBSD runtime detection of dotprod and i8mm using sysctl
vtorri_ has quit [Remote host closed the connection]
vtorri_ has joined #ffmpeg-devel
<cone-011>
ffmpeg Brad Smith release/7.0:887e6f404da5: aarch64: Add OpenBSD runtime detection of dotprod and i8mm using sysctl
<cone-011>
ffmpeg Brad Smith release/6.1:07fac146530e: aarch64: Add OpenBSD runtime detection of dotprod and i8mm using sysctl
vtorri_ has quit [Remote host closed the connection]
vtorri_ has joined #ffmpeg-devel
System_Error has joined #ffmpeg-devel
vtorri_ has quit [Ping timeout: 268 seconds]
Krowl has joined #ffmpeg-devel
IndecisiveTurtle has joined #ffmpeg-devel
<IndecisiveTurtle>
Lynne: Almost done with the shader, feel I could get something to run today. Need to think of how to handle the put bit context in shader though (I will prob try to copy paste the c code for now).Initially I had an entire shader for everything, haar wavelet, quant and encoding. But deinterleaving was a pain so I split the Haar part into a separate shaderwhere it dispatches workgroups with the dimentions of the slice
<IndecisiveTurtle>
In horizontal/vertical passes each invocation handles a pair of pixels (so half of them are masked out) and final deinterlaving part all invocations load their pixel and store it in correct position. Could be better but it doesn't need any temp storage and I believe it works alright from testing
<Lynne>
IndecisiveTurtle: "doesn't need temporary storage"?
<Lynne>
does the haar shader dump the data into the ether then?
<Lynne>
I don't think this is the right approach
<Lynne>
as much as its painful to do deinterleaving, you have to do it, but at least you don't have to do it multiple times
<IndecisiveTurtle>
It does it on the frame image itself
<IndecisiveTurtle>
I can change it to a buffer though if it's better
<Lynne>
you cannot alter the frame image
<Lynne>
the input frame must remain untouched
Krowl has quit [Read error: Connection reset by peer]
<Lynne>
you cannot use the input image format either, because anything more than 2 level haar, and your DC coeff will explode beyond 8 bits very quickly
<IndecisiveTurtle>
Ah sorry didn't realise that. Will fix it asap
<Lynne>
so that means you have to carry around 32 bit floats, and if you're doing this, you may as well just skip this entirely
<Lynne>
well, you cannot get rid of temporary memory
<IndecisiveTurtle>
Would writing to uint SSBO work in that case?
<IndecisiveTurtle>
Or better prefer something like an R32UINT image
<Lynne>
with an ubershader approach, you still have to put the data somewhere, even if you only use it within the shader
<Lynne>
has to be float
<Lynne>
you can use int32s, but you'll generally get worse perf because GPUs have more int32 units
<Lynne>
*float units
<Lynne>
hmm, actually better use int32s, the encoder has to be lossless when the quantizer is 0
<IndecisiveTurtle>
I read somewhere that AMD has 1:1 integer performance in its gpu not sure how accurate it is
<Lynne>
there's no telling whether somewhere rounding or inexactness in the float implementation may happen
<cone-507>
ffmpeg J. Dekker master:e61fed8280cc: avutil/riscv/cpu: fix __riscv_v_min_vlen typo
j45 has quit [Ping timeout: 260 seconds]
j45 has joined #ffmpeg-devel
j45 has quit [Changing host]
j45 has joined #ffmpeg-devel
Krowl has quit [Read error: Connection reset by peer]
<haasn>
michaelni: do you understand why `lumToYV12` outputs different value ranges for different input formats? where is this compensated for by the rest of the code?
<haasn>
for example, for reading packed yuyv, it outputs the 8-bit input values directly
<haasn>
for something like pal8, it outputs the input value left-shifted by 6
<haasn>
for monowhite, it outputs either 0 or 16383
<haasn>
all of these are wildly different value ranges, yet I don't see it being compensated for anywhere else - the values afaict are just fed directly to the horizontal scaler
<haasn>
doesn't the horizontal scaler already expect 15-bit coefficients? where is the conversion from 8-bit to 15-bit performed for something like yuv420p?
kekePower has quit [Remote host closed the connection]
jamrial has joined #ffmpeg-devel
<michaelni>
haasn, i suspect reading the code that initializes the used function pointers could clarify things. I do remember there was more than 1 case for the intermediate but id have to read the code myself to know exactly
lexano has joined #ffmpeg-devel
<haasn>
it seems like the hscale code always expects 8 bit inputs
Krowl has joined #ffmpeg-devel
<haasn>
ah found it
<haasn>
it seems like each arch handles this slightly differently (annoyingly)
<haasn>
but basically in the case of e.g. RGB, it gets converted to 16 bit during conversion to yuv and then treated as regular 16 bit input
<haasn>
for the monowhite case it seems like it's just a bug?
<haasn>
monowhite2Y_c feeds directly into hScale16To15_c
<haasn>
monowhite2Y_c outputs values in the range [0,16383]
<haasn>
ah it works out because it's hard-coded into the isAnyRGB() exception which makes hScale16To15 hard-code 13 bits input
<haasn>
14*
<haasn>
this is all very obtuse and confusing design, and random parts statefully affecting other parts with hard-coded assumptions.. I see I have a lot of cleaning up to do before I can even re-use the existing asm
Livio has quit [Ping timeout: 256 seconds]
<elenril>
state is great
<elenril>
don't you just love state
<elenril>
the globaler, the better
IndecisiveTurtle has joined #ffmpeg-devel
IndecisiveTurtle has quit [Ping timeout: 240 seconds]
Livio has joined #ffmpeg-devel
Livio has quit [Ping timeout: 264 seconds]
Krowl has quit [Read error: Connection reset by peer]
Krowl has joined #ffmpeg-devel
IndecisiveTurtle has joined #ffmpeg-devel
Krowl has quit [Read error: Connection reset by peer]
Krowl has joined #ffmpeg-devel
Krowl has quit [Read error: Connection reset by peer]
cone-507 has quit [Quit: transmission timeout]
Krowl has joined #ffmpeg-devel
<haasn>
in mpv/libplacebo we assume YUV frames with unspecified colorspace to be BT.709 iff the resolution exceeds 1280x576 (in any dimension)
<haasn>
and otherwise BT.601 / SD
<haasn>
libswscale currently defaults to BT.601 for everything
<kasper93>
libplacebo does a good thing, but the big assumption is that we are working with video
<haasn>
good point
<haasn>
we should probably stick to defaulting to BT.601 following principle of minimum surprise
<kasper93>
for example images shouldn't be treated this way
<kasper93>
I wanted to fix it somehow for mpv/libplacebo, because it is weird to open small image and have differnt colorspace than big image. But not sure what would be best here
<haasn>
in b4 we add an exception for 1-frame sources and then somebody complains that their screenshot of movie looks different from the movie itself
<kasper93>
well this is already the case, we convert to srgb for jpg, for png we tag it
<kasper93>
it is little bit of mess
<kasper93>
always has been
<kasper93>
and there is gamma issue in png tagging, so yet another tricky one
<haasn>
s/screenshot/single frame dump/
<kasper93>
ah, yes, indeed
<haasn>
so I think the correct thing to do in libswscale, for unspecified sources in general, is to have a flag controlling whether we want "strict" mode or "fuzzy" mode
<BBB>
isn't that the bitexact flag?
<haasn>
in "strict" mode, something like a conversion from RGB to YUV with AVCOL_RANGE_UNSPECIFIED would be rejected
<haasn>
BBB: no, that's about the internal precision; not about whether or not an operation should be attempted
<haasn>
put another way; the bitexact flag only matters if the operation is being done at all
<haasn>
so in "strict" mode, you would have to explicitly request either MPEG or JPEG range, the implementation won't simply assume MPEG by default
<haasn>
whereas in "fuzzy" mode, it would e.g. assume that untagged YUV should be treated as limited range BT.601
<haasn>
the same as what libswscale currently does
<haasn>
my question is: should "strict" or "fuzzy" mode be the default?
<haasn>
I am thinking that we probably want fuzzy mode by default
<haasn>
it's closer to how libswscale currently operates
mkver has quit [Ping timeout: 264 seconds]
Livio has joined #ffmpeg-devel
IndecisiveTurtle has quit [Ping timeout: 255 seconds]
IndecisiveTurtle has joined #ffmpeg-devel
mkver has joined #ffmpeg-devel
<elenril>
mkver: did you have some patches for FFFilter?
Krowl has quit [Read error: Connection reset by peer]
Kei_N_ has quit [Ping timeout: 264 seconds]
<mkver>
elenril: Yes, but NG didn't like a preparatory patch.
<elenril>
he's been outvoted on the filter link question, so this could go ahead as well now
<cosminaught>
haasn: not sure whether this would be a popular opinion, but I would keep defaulting things out of swscale, and have it reject doing conversions when the right thing to do cannot be determined
<jamrial>
haasn: i think vf_zscale does it the "strict" way
<cosminaught>
I think that kind of defaulting logic belongs in the caller, who has more context about what it's dealing with, and can print warnings as needed, etc
<kasper93>
I agree.
<kasper93>
guessing thigns deep into processing code is only confusing for users, becase it is not visible enough
AbleBacon has joined #ffmpeg-devel
Krowl has joined #ffmpeg-devel
<haasn>
cosminaught: I was thinking about providing something like an AVFrame helper for inferring/sanitizing colorspace fields, but I feel icky about permanently "adding" information that was never there to begin with
<haasn>
then again, it would effectively be there post-conversion anyway, so I guess it's not a big deal
IndecisiveTurtle has quit [Ping timeout: 268 seconds]
<cosminaught>
I think that default color space would be a useful filter to have
Krowl has quit [Read error: Connection reset by peer]
Livio has quit [Ping timeout: 246 seconds]
vtorri_ has quit [Ping timeout: 256 seconds]
Livio has joined #ffmpeg-devel
vtorri_ has joined #ffmpeg-devel
Warcop has joined #ffmpeg-devel
IndecisiveTurtle has joined #ffmpeg-devel
vtorri_ has quit [Ping timeout: 246 seconds]
vtorri_ has joined #ffmpeg-devel
kekePower has joined #ffmpeg-devel
kekePower has quit [Client Quit]
kekePower has joined #ffmpeg-devel
vtorri_ has quit [Ping timeout: 256 seconds]
vtorri_ has joined #ffmpeg-devel
Sebastinas has quit [Quit: -]
Sebastinas has joined #ffmpeg-devel
<Lynne>
just as long as it isn't as strict as vf_zscale, it was very pedantic with respect to what options were specified and IIRC it couldn't derive anything from the AVFrame's fields
<JEEB>
it does derive from the AVFrame fields, but for the output side of course you need to set things
<kasper93>
Can I assume that input buffer to av_parser_parse2 always include AV_INPUT_BUFFER_PADDING_SIZE padding?
<JEEB>
libavcodec/parser.c seems to utilize that define a few times, but as I haven't looked at the actual parser logic in a while (just looked at specific parsers themselves) I don't want to promise things
<JEEB>
ok, so with buf_size 0 you get the dummy buffer of exactly that size. which would I think mean that the padding should generally be there
<JEEB>
(bugs not withstanding)
<JEEB>
and yea, ff_combine_frame there adds the padding size too in reallocs and such
IndecisiveTurtle has quit [Ping timeout: 264 seconds]
<mkver>
kasper93: Yes.
IndecisiveTurtle has joined #ffmpeg-devel
<kasper93>
I figured this much, but what I see is that packet_alloc allocs 4096 and clears the padding at the end
<kasper93>
but the size from av_parser_parse2 is 53 (in my case) and while ofcourse the buffer is big enough for padding, the padding itself is not zeroed
vtorri_ has quit [Ping timeout: 260 seconds]
vtorri_ has joined #ffmpeg-devel
Livio has quit [Ping timeout: 252 seconds]
Livio has joined #ffmpeg-devel
vtorri_ has quit [Ping timeout: 255 seconds]
<mkver>
kasper93: Bug in jpegxl_anim_read_packet then.
cone-286 has joined #ffmpeg-devel
<cone-286>
ffmpeg Michael Niedermayer master:749994194cc2: tools/target_dec_fuzzer: Adjust threshold for jpeg2000
<cone-286>
ffmpeg Michael Niedermayer master:f81602fb3ac5: tools/target_dec_fuzzer: Adjust threshold for MV30
<cone-286>
ffmpeg Michael Niedermayer master:3a9292aff320: avcodec/snowenc: MV limits due to mv_penalty table size
<cone-286>
ffmpeg Michael Niedermayer master:eb9c96a82f95: avcodec/ratecontrol: Try to keep fps as a rational
<cone-286>
ffmpeg Michael Niedermayer master:d34d4b6a7ce7: avcodec/r210enc: Use av_rescale for bitrate
<cone-286>
ffmpeg Michael Niedermayer master:4a7220bd5c18: avcodec/targaenc: Allocate space for the palette
<cone-286>
ffmpeg Michael Niedermayer master:228f255b5d9b: avcodec/jfdctint_template: Fewer integer anomalies
<cone-286>
ffmpeg Paul B Mahol master:c22488f718f2: avcodec/smcenc: make sure ny/nx are >= 0
<cone-286>
ffmpeg Michael Niedermayer master:9e6c5b6e865a: swscale/output: alpha can become negative after scaling, use multiply
<cone-286>
ffmpeg Michael Niedermayer master:c221c7422f07: swscale/output: Avoid undefined overflow in yuv2rgb_write_full()
<cone-286>
ffmpeg Michael Niedermayer master:10801166589a: avcodec/aac/aacdec_usac: Test ac in usac
<kasper93>
mkver: Thanks, for you pointers, I have better understanding now, how this padding suppose to be used. Will send patch later, I found unrelated issue in mpv fuzzers while at it, fun times.
<mkver>
Traneptora: What is 0x0a870a0d in line 113 of jpegxl_anim_dec.c?
<Traneptora>
the header is 12 bytes
<Traneptora>
before the ftyp box
<Traneptora>
first eight are the standard eight for isombff
vtorri_ has joined #ffmpeg-devel
<mkver>
And what do these four bytes after the first eight mean?
<Traneptora>
mkver: I do not know why they were chosen but they're part of the spec