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.1 has been released! | Please read ffmpeg.org/developer.html#Code-of-conduct
ccawley2011 has quit [Ping timeout: 248 seconds]
Everything has quit [Quit: leaving]
Marth64 has joined #ffmpeg-devel
ccawley2011__ has joined #ffmpeg-devel
Marth64 has quit [Quit: Leaving]
ccawley2011_ has quit [Ping timeout: 248 seconds]
ccawley2011__ has quit [Read error: Connection reset by peer]
Kei_N_ has joined #ffmpeg-devel
Kei_N has quit [Ping timeout: 276 seconds]
<fflogger>
[newticket] tfoucu: Ticket #11312 ([avformat] MP4 Fragmented demuxer: does not respect audio duration from TRUN) created https://trac.ffmpeg.org/ticket/11312
Traneptora has quit [Quit: Quit]
thilo has quit [Ping timeout: 252 seconds]
arch1t3cht3 has joined #ffmpeg-devel
thilo has joined #ffmpeg-devel
arch1t3cht has quit [Ping timeout: 245 seconds]
arch1t3cht3 is now known as arch1t3cht
cone-627 has quit [Quit: transmission timeout]
haihao has quit [Ping timeout: 246 seconds]
haihao has joined #ffmpeg-devel
Traneptora has joined #ffmpeg-devel
^Neo_ has quit [Ping timeout: 245 seconds]
jamrial has quit []
darkapex has quit [Ping timeout: 252 seconds]
cone-399 has joined #ffmpeg-devel
<cone-399>
ffmpeg Lynne master:eb536d97a027: ffv1enc_vulkan: support buffers larger than 4GiB
<fflogger>
[editedticket] an0ndev: Ticket #9535 ([undetermined] PNG decoder fails processing more than a certain number of frames) updated https://trac.ffmpeg.org/ticket/9535#comment:11
<fflogger>
[editedticket] an0ndev: Ticket #9535 ([undetermined] PNG decoder fails processing more than a certain number of frames) updated https://trac.ffmpeg.org/ticket/9535#comment:12
darkapex has joined #ffmpeg-devel
Martchus_ has joined #ffmpeg-devel
Martchus has quit [Ping timeout: 252 seconds]
compnnn has quit [Read error: Connection reset by peer]
compnnn has joined #ffmpeg-devel
Marth64 has joined #ffmpeg-devel
System_Error has joined #ffmpeg-devel
mkver has joined #ffmpeg-devel
<fflogger>
[editedticket] an0ndev: Ticket #9535 ([undetermined] PNG decoder fails processing more than a certain number of frames) updated https://trac.ffmpeg.org/ticket/9535#comment:13
<fflogger>
[editedticket] an0ndev: Ticket #9535 ([undetermined] PNG decoder fails processing more than a certain number of frames) updated https://trac.ffmpeg.org/ticket/9535#comment:14
haihao has quit [Ping timeout: 260 seconds]
haihao has joined #ffmpeg-devel
haihao has quit [Ping timeout: 276 seconds]
haihao has joined #ffmpeg-devel
cone-399 has quit [Quit: transmission timeout]
<haasn>
is it just me or is av_csp_trc_func_from_id(AVCOL_TRC_SMPTE2084) defined with the wrong range respective to all other functions?
<haasn>
it seems to take raw nits input
<haasn>
or at least that's what const double L = Lc / 10000.0; implies
<haasn>
but all other functions are defined to take range 0.0 - 1.0
<haasn>
in theory this means EXR inputs with gamma=st2048 should be broken
<haasn>
cc Traneptora it seems you wrote this code, maybe you know how to test?
<Traneptora>
looks like it was written by Kevin JW
<Traneptora>
(this is the parent commit to my refactor)
<haasn>
ah
<haasn>
whelp
j45 has quit [Ping timeout: 276 seconds]
j45 has joined #ffmpeg-devel
j45 has quit [Changing host]
j45 has joined #ffmpeg-devel
<haasn>
how do we even handle HLG inside swscale
<haasn>
so HLG is fundamentally scene referred, but we do all gamut/tone mapping in IPT colorspace
<haasn>
which is defined on an absolute reference scale
<haasn>
do we 1) apply static OOTF tuned for 1000 nits
<haasn>
2) just treat it as scene referred but normalize it to 12 * sdr white, so peak = 203 * 12 = 2436
<haasn>
3) do all processing in display referred space instead, require OOTF for both BT.1886 and HLG
<haasn>
consider that we need a conversion from PQ to HLG to do the right thing (tm)
<haasn>
cc JEEB
<haasn>
it's largely for this reason that I went with approach c) inside libplacebo, which is aimed at the playback use case
<haasn>
do you happen to remember what the most up-to-date ITU document is about how to correctly convert between HLG and PQ for signal delivery?
<haasn>
is it still BT.2446?
<haasn>
oh that one only considers HDR<->SDR
<haasn>
seems like BT.2408 is the one to poke
<JEEB>
I think yea
<haasn>
.. which just references 2390
<JEEB>
yup :D
<haasn>
seems they want me to do implement option 1
<haasn>
i.e. just slap a 1000 nits ootf on top of the HLG curve
<haasn>
which is.. fine, I guess; and then I assume we stick with 203 nits normalization
<haasn>
except for DV, which apparently wants 100 nits these days
Krowl has quit [Read error: Connection reset by peer]
<JEEB>
or some other OOTF which converts between scene and display, but the 1000 nit one is the most common one
<haasn>
I am very hesitant on adding too much magic to swscale tbh because the intent is for it to be largely predictable when auto-inserted into filter chains
<haasn>
and in particular, to be used on the production / encoding side
<haasn>
so we shouldn't hard-code _any_ assumptions about the target device
<haasn>
infact, I would prefer to do all tone mapping in scene referred space inside swscale
<haasn>
to avoid having to hard-code even assumptions about BT.1886 vs sRGB, target display contrast, etc
<haasn>
scene referred space assumes infinite contrast after all
<JEEB>
inverse HLG OOTF is also in BT.2100 itself
IndecisiveTurtle has joined #ffmpeg-devel
<haasn>
but this means we would then need to transfer e.g. PQ signals back to scene referred space before tone mapping
<JEEB>
and alpha may be set to 1.0 nit for processing purposes
<haasn>
which of course is defined in some document as using the BT709+BT1886 interaction as the canonical OOTF
<haasn>
so the question I have now is, uh... should I pass PQ through an *inverse* BT1886 OOTF before tone mapping it to SDR and then encoding it with the piecewise BT709??
<haasn>
or should we stick with doing everything in display referred space and treat only HLG as a special case, plus hard-code gamma 2.4 for all of the SDR functions
<haasn>
seems no matter which way we cut it, the results will be surprising in at least some cases
<haasn>
maybe I need to implement both and see what produces better results..
<haasn>
maybe I can just make it an option to escape accountability
j45 has quit [Ping timeout: 248 seconds]
j45 has joined #ffmpeg-devel
j45 has quit [Changing host]
j45 has joined #ffmpeg-devel
ccawley2011 has joined #ffmpeg-devel
<kasper93>
I sitll don't know what is diffused white value in case on DV with HDR10 fallback
<kasper93>
DV itself is 100 nits from what I see...
<kasper93>
(also assuming 1000:1 contrast ratio was always little bit meh to me, so scene refered would avoid that)
HarshK23 has quit [Quit: Connection closed for inactivity]
HarshK23 has joined #ffmpeg-devel
cone-507 has quit [Quit: transmission timeout]
<fflogger>
[newticket] tysonite: Ticket #11313 ([undetermined] Stream loop VTT subtitles via UDP ( error = Numerical result out of range )) created https://trac.ffmpeg.org/ticket/11313