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: 240 seconds]
thilo has joined #ffmpeg-devel
arch1t3cht9 has joined #ffmpeg-devel
arch1t3cht has quit [Ping timeout: 268 seconds]
arch1t3cht9 is now known as arch1t3cht
cone-891 has joined #ffmpeg-devel
<cone-891>
ffmpeg Michael Niedermayer master:e7775973f037: avcodec/tests/bitstream_template: Assert bits_init8() return
<cone-891>
ffmpeg Michael Niedermayer master:b6fa2ed77e57: tools/enc_recon_frame_test: Assert that av_image_get_linesize() succeeds
<cone-891>
ffmpeg Michael Niedermayer master:33da5f4e2717: avformat/demux: resurrect dead stores
<cone-891>
ffmpeg Michael Niedermayer master:c4004605b2fa: avdevice/dshow: fix badly indented line
<cone-891>
ffmpeg Michael Niedermayer master:c841cb45e81e: qsv: Initialize impl_value
<cone-891>
ffmpeg Michael Niedermayer master:3c1915d7762d: avformat/hlsenc: Remove dead ret stores
<cone-891>
ffmpeg Michael Niedermayer master:87846f64b570: avutil/random_seed: Avoid dead returns
<cone-891>
ffmpeg Michael Niedermayer master:e8a1e1899d9e: avutil/tests/dict: Check av_dict_set() before get for failure
<cone-891>
ffmpeg Michael Niedermayer master:e3481730ed9b: avutil/tests/opt: Check av_set_options_string() for failure
<cone-891>
ffmpeg Michael Niedermayer master:3f9daf1c18c2: swscale/x86/swscale: use a clearer name for INPUT_PLANER_RGB_A_FUNC_CASE
<cone-891>
ffmpeg Michael Niedermayer master:bfc22f364d31: swscale/yuv2rgb: Use 64bit for brightness computation
<cone-891>
ffmpeg Michael Niedermayer master:6df8bd64ffa5: tools/decode_simple: Check avcodec_send_packet() for errors on flushing
<cone-891>
ffmpeg Michael Niedermayer master:8814cedb079d: avcodec/tiff: Assert init_get_bits8() success in horizontal_fill()
<cone-891>
ffmpeg Michael Niedermayer master:a287f17db22c: avcodec/tiff: Assert init_get_bits8() success in unpack_gray()
<cone-891>
ffmpeg Michael Niedermayer master:992b28f57281: avcodec/vc1_block: remove unused off from vc1_decode_p_mb_intfr()
<cone-891>
ffmpeg Michael Niedermayer master:d5cc21741b9c: avcodec/vc1_block: remove unneeded store to off in vc1_decode_p_mb_intfi()
<cone-891>
ffmpeg Michael Niedermayer master:62d7106c3603: avcodec/vlc: Cleanup on multi table alloc failure in ff_vlc_init_multi_from_lengths()
<cone-233>
ffmpeg Rémi Denis-Courmont master:4e56455d3672: lavc/vp8dsp: avoid one multiplication on RISC-V
<cone-233>
ffmpeg Rémi Denis-Courmont master:a11122f9c63b: lavc/vp8dsp: save one R-V GPR
___nick___ has joined #ffmpeg-devel
<cone-233>
ffmpeg Rémi Denis-Courmont release/7.0:449cab7b1638: lavc/lpc: fix off-by-one in R-V V compute_autocorr
___nick___ has quit [Client Quit]
___nick___ has joined #ffmpeg-devel
<Sean_McG>
can we PLEASE stop having code reviews that are getting up to double-digit revisions?
ngaullier has quit [Ping timeout: 264 seconds]
<nevcairiel>
would you rather developers write code better quicker, or reviews be less thorough?
<nevcairiel>
many of these revisions only include small fixes, would be far less obvious if a new revision would be just pushing a git branch to a MR
<Lynne>
JEEB: do you havve a response to Marton?
<courmisch>
if you don't dispatch ffmpeg-devel to a separate IMAP folder, you have a problem
<JEEB>
Lynne: yea I wanted to comment that if we explicitly pick a different name from either spec for the +/-90 degree one, then there should be a ///< doxy comment or so that mentions the ISO and IEC/ITU identifiers that it's supposed to map to. also you should check how the top one is called in the specs.
<JEEB>
on my side I will then make a patch that adds that to the different existing things
canjar has joined #ffmpeg-devel
<rajivharlalka>
Can someone please explain in simple terms what "perceptually uniform" means. Have searched quite number of places, but couldn't get a meaning in reference to video. ref: "majority of LDR metrics assume that the input values are approximately perceptually uniform. While luma values in LDR images have this property, the same cannot be said about
<rajivharlalka>
luminance values found in HDR images."
<JEEB>
that reminds me of the gamut mapping discussion
<haasn>
rajivharlalka: imagine an experiment where you ask a human to distinguish between two slightly different brightness levels presented at the same time (or in succession)
<BBB>
I believe uniformity refers to the stepping between integer/pixel values (e.g. changing from 1 to 2, or from 1011 to 1012) having the same effect on brightness, that is, the effect the integer value delta would have on changing of brightness is independent of that brightness itself
<BBB>
and that's not true for HDR because gamma is non-constant?
<haasn>
you will determine, through experiment, a certain relationship between the brightness level and the "just noticeable difference", e.g. going from 1000 cd/m² to 1010 cd/m² may be just noticeable, but going from 1 to 1.01 cd/m² may also be
<haasn>
if you plot this out you get a curve mapping brightness on the x axis against just noticeable difference on the y axis
<haasn>
"perceptually uniform" means that your numerical encoding is the inverse of this curve
<haasn>
in practice, the PQ function approximates this relationship well on the interval from 0 to 10000 cd/m²
<haasn>
so in simpler terms, "perceptually uniform" means you're encoding PQ values instead of linear brightness values
<haasn>
well, this is one specific instance of the term "perceptually uniform", as applied to brightness levels
<haasn>
but the same concept generalizes to any conceivable aspect of human perception; for example color gradations
<rajivharlalka>
Okay so making some metrix, say x, perceptually uniform would mean finding a inverse mapping of x such that the PU of x is linear?
<rajivharlalka>
s/metrix/metric
<haasn>
oh, I misspoke slightly, it's not the inverse of the brightness/sensitivity graph, but the inverse of the *integral*; e.g. imagine if the just noticeable difference is a constant 1% of the signal level; then a perceptually uniform encoding of this signal would just be a logarithm
Lypheo has quit [Quit: Ping timeout (120 seconds)]
Lypheo has joined #ffmpeg-devel
<haasn>
(as you'll find, many perceptually uniform encodings closely approximate logarithms, due to weber's law)
<JEEB>
HLG even has that in its name
<haasn>
rajivharlalka: I'm not sure what you mean by "such that the PU of x is linear", but you basically want the property that the just noticeable difference is a constant across the whole encoding range; e.g. going from 100 to 101 should be as equally noticeable as going from 10 to 11
<haasn>
funnily enough, the original quote is arguably wrong; traditional SDR gamma encodings are not very perceptually uniform
<haasn>
they're, conversely, very good at approximating CRT monitors
<haasn>
perceptual uniformity was _not_ the chief design goal of conventional SDR gamma functions
<rajivharlalka>
Okay, PU now makes more sense, but still have a silly doubt which I would try to get more clarity first before asking.
<rajivharlalka>
The quote is actually from a paper, "PRACTICALITIES OF PREDICTING QUALITY OF HIGH DYNAMIC RANGE IMAGES AND VIDEO" by Rafał K. Mantiuk
<kepstin>
yeah, it just happened that the response function of phosphors in crts is similar in shape to a perceptually uniform encoding.
<nevcairiel>
the paper seems to imply whatever input values of HDR are in are in fact no PQ, as the paragraph after that it discusses PQ and other encoding options to get a PU space
<nevcairiel>
but it does not actually specify how its receiving HDR data for that assumption
<nevcairiel>
linear?
<nevcairiel>
seems like its assuming linear
<kepstin>
in almost all cases when talking about transforms, people will be talking about encodings to/from linear.
<haasn>
typically you receive HDR data from a camera which gives you a linear count of the number of photons that hit each cell of the photoreceptor during the exposure period
<nevcairiel>
so the argument in that first section is that linear color is not perceptually uniform, while it assumes LDR is 2.2 gamma
Krowl has quit [Read error: Connection reset by peer]
<nevcairiel>
seems like an odd starting point, but sure
<haasn>
(or something linearly related to that count, anyway)
<kepstin>
it could be implied when comparing or starting from an image in some encoding, that it's first decoded to linear before being encoded with a different method.
Krowl has joined #ffmpeg-devel
Krowl has quit [Read error: Connection reset by peer]
IndecisiveTurtle has joined #ffmpeg-devel
AbleBacon has joined #ffmpeg-devel
iive has joined #ffmpeg-devel
Livio has quit [Ping timeout: 240 seconds]
Livio has joined #ffmpeg-devel
jarthur has joined #ffmpeg-devel
<courmisch>
uho, fate-vc1_ilaced_twomv passes in QEMU, fails on hardware
<Lynne>
JEEB: could you reply to Marton?
<JEEB>
yea, just ended up doing job applications today
cone-233 has quit [Quit: transmission timeout]
Kei_N_ has quit [Read error: Connection reset by peer]
Kei_N has joined #ffmpeg-devel
<courmisch>
update_lls_8_c: 82.4
<courmisch>
update_lls_8_sse2: 25.4
<courmisch>
update_lls_8_avx: 25.4
<courmisch>
update_lls_8_fma3: 25.4
<courmisch>
not sure what to say about that
<courmisch>
even at max size, avx and fma give same results
mkver has quit [Ping timeout: 240 seconds]
<jamrial>
courmisch: i see a slight boost from sse2 to avx and from that to fma3
<jamrial>
844 c, 220 sse, 159 avx, 125 fma3
<jamrial>
on max size
<courmisch>
on my AuthenticAMorDor Ryzen 5 avx and fma3 have same results for all three benches
<courmisch>
jamrial: update_lls doesn't even have additions, so not sure what FMA is even supposed to bring
<jamrial>
??
<jamrial>
there's a bunch of mulpd + addpd it replaces with fmaddpd
<courmisch>
jamrial: update_lls is just a glorified outer product, only multiplies
<courmisch>
evaluate has additions
<jamrial>
m->covariance[i][j] += var[i] * var[j];
<courmisch>
that's a subtraction of the opposite
<courmisch>
to it is avg_vc1_mspel_pixels_tab[1][0] failing on hardware, working on QEMU
<courmisch>
on the bright side, for once, it's not my code.
<IndecisiveTurtle>
Lynne: I got a question, should I use FFCodec for the vulkan implementation or switch to FFHWAccel? I saw the various vulkan video decoders use that and access avctx->internal->hwaccel_priv_data for the vulkan context. I thought maybe we could have that and use avctx->priv_data for the plain existing VC2 encoder state.
<IndecisiveTurtle>
I have setup some vulkan code during init based on the filters. I'm thinking of using buffer device address as a start because it doesn't need descriptor set setup.
<Lynne>
IndecisiveTurtle: hwaccels can only be decoders
<Lynne>
use FFCodec with a hardware flag
<Lynne>
you do need a descriptor set
<Lynne>
you receive VkImages
<Lynne>
which you need to generate ImageViews for
<Lynne>
for which you need to bind to descriptors
Krowl has joined #ffmpeg-devel
<IndecisiveTurtle>
Ah okay so set AV_CODEC_CAP_HARDWARE in capabilities, got it.
<IndecisiveTurtle>
Is there somewhere else in libavcodec that shows how VkImages are provided? Only found some code in vulkan_video/vulkan_decode but that uses the other FFHWAccel API I think
<Lynne>
libavutil/pixfmt.h
<Lynne>
though really, it's just that AVFrame->data[0] contains an AVVkImage