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
abdu93 has quit [Quit: Client closed]
<fflogger>
[editedticket] Balling: Ticket #11298 ([undetermined] AMD VAAPI HEVC encoding a 1080p video results in a 1920x1088 one) updated https://trac.ffmpeg.org/ticket/11298#comment:2
<Marth64>
I need to vanish for a few days. Talk to you soon.
<Marth64>
BtbN: I ordered the CPU fan for the beater box to experiment with as a node. It should arrive this week. Thank you.
<BtbN>
let me know when you need a token to register it
<Marth64>
TY
Marth64 has quit [Quit: Leaving]
Kei_N has joined #ffmpeg-devel
Kei_N_ has quit [Ping timeout: 272 seconds]
thilo has quit [Ping timeout: 248 seconds]
thilo has joined #ffmpeg-devel
khrbtxyz has quit [Remote host closed the connection]
khrbtxyz has joined #ffmpeg-devel
mkver has quit [Ping timeout: 252 seconds]
cone-083 has quit [Quit: transmission timeout]
^Neo has quit [Ping timeout: 252 seconds]
jamrial has quit []
MisterMinister has joined #ffmpeg-devel
Martchus_ has joined #ffmpeg-devel
Martchus has quit [Ping timeout: 252 seconds]
System_Error has quit [Remote host closed the connection]
System_Error has joined #ffmpeg-devel
MisterMinister has quit [Ping timeout: 252 seconds]
MisterMinister has joined #ffmpeg-devel
MisterMinister has quit [Ping timeout: 252 seconds]
beastd has joined #ffmpeg-devel
ngaullier has joined #ffmpeg-devel
ngaullier has quit [Remote host closed the connection]
ngaullier has joined #ffmpeg-devel
^Neo has joined #ffmpeg-devel
^Neo has quit [Ping timeout: 265 seconds]
<fflogger>
[editedticket] fildens: Ticket #11430 ([ffmpeg] ffmpeg 7.x There are no speed and time statistics if there are data streams in the SRT stream) updated https://trac.ffmpeg.org/ticket/11430#comment:3
<PolarizationLead>
added generic 32bit path to vf_pf2pf.c next big step is float support
<PolarizationLead>
> Starting on January 19, 2025 Facebook's internal policy makers decided that Linux is malware and labelled groups associated with Linux as being "cybersecurity threats".
<PolarizationLead>
finally! just have only windows and apple and nothing else
<kierank>
michaelni: are we vulnerable to rsync attacks?
<PolarizationLead>
lol, that article is under paywall
<PolarizationLead>
about rsync 10 security bugs, one of them being very critical
<PolarizationLead>
looks like nothing is safe anymore
<kierank>
PolarizationLead: is librempeg safe
<PolarizationLead>
kierank: nope
<PolarizationLead>
kierank: use native Rust projects instead
PolarizationLead has quit [Quit: Client closed]
PolarizationLead has joined #ffmpeg-devel
<PolarizationLead>
kierank: so join symphonia or nihav or some other alive rust coding project (ignore unsafe rust wrapper projects)
PolarizationLead has quit [Quit: Client closed]
PolarizationLead has joined #ffmpeg-devel
abdu has joined #ffmpeg-devel
^Neo has joined #ffmpeg-devel
^Neo has quit [Changing host]
^Neo has joined #ffmpeg-devel
^Neo has quit [Ping timeout: 252 seconds]
jamrial has joined #ffmpeg-devel
ccawley2011 has joined #ffmpeg-devel
<PolarizationLead>
C Is Not Suited to SIMD, says Vanessa McHale, 2024-09-05
<BBB>
if twitter people say it is true, then it must unquestionably be true
<nevcairiel>
its not like we want to write SIMD in C either, which is why we tell people to use ASM directly =P
abdu has quit [Quit: Client closed]
ngaullier has quit [Remote host closed the connection]
ngaullier has joined #ffmpeg-devel
abdu has joined #ffmpeg-devel
ngaullier has quit [Remote host closed the connection]
ngaullier has joined #ffmpeg-devel
<PolarizationLead>
Dillo 3.2.0 released, does it work with JS pages?
cone-555 has quit [Quit: transmission timeout]
<thardin>
I'm surprised blockifying for loops is still an effective method of hinting the compiler to do vectorization
<nevcairiel>
blockifying? you mean unrolling?
<PolarizationLead>
unrolling loops
ngaullier has quit [Remote host closed the connection]
ngaullier has joined #ffmpeg-devel
<thardin>
funroll-loops
<PolarizationLead>
but how would you funroll-loops if function accepts several parameters with fixed values
<thardin>
you can't
<thardin>
what I mean is you divide the size by some constant, say 64, then run a specialized version of the loop size/64 times, plus a final set of singular iterations to deal with the slop (steps % 64)
<thardin>
as for example memcpy() implementations often do
<thardin>
a C implementation with JIT support would be nice. a friend of mine did something like that with llvm
ngaullier has quit [Remote host closed the connection]
ngaullier has joined #ffmpeg-devel
ccawley2011_ has joined #ffmpeg-devel
ccawley2011 has quit [Ping timeout: 252 seconds]
ngaullier has quit [Remote host closed the connection]
ngaullier has joined #ffmpeg-devel
ngaullier has quit [Remote host closed the connection]
ngaullier has joined #ffmpeg-devel
ccawley2011 has joined #ffmpeg-devel
ngaullier has quit [Remote host closed the connection]
ngaullier has joined #ffmpeg-devel
ccawley2011__ has joined #ffmpeg-devel
ccawley2011_ has quit [Ping timeout: 265 seconds]
PolarizationLead has quit [Quit: Client closed]
ccawley2011 has quit [Ping timeout: 244 seconds]
ccawley2011__ has quit [Ping timeout: 272 seconds]
qesat60 has quit [Quit: Connection closed for inactivity]
ngaullier has quit [Remote host closed the connection]
ngaullier has joined #ffmpeg-devel
PolarizationLead has joined #ffmpeg-devel
ngaullier has quit [Remote host closed the connection]
ngaullier has joined #ffmpeg-devel
<haasn>
PolarizationLead: in the end I decided to go with a big switch/case of pixfmts instead of trying to roll some new intermediate struct / parsing AVPixFmtDescriptor
<haasn>
since we decompose it into multiple steps anyway
<PolarizationLead>
how many cases in switch() are?
<haasn>
only like 2-4 per step
<haasn>
since we decompose pixformats into several operations (gather bytes from planes, swap endianness, swizzle, expand)
<haasn>
the grouping is different per step
<haasn>
for example, the first step only cares about the cases (packed, planar, semipacked)
<haasn>
the second step is just a check for the pixfmt flag
<haasn>
the third step only cares about one distinct case per channel ordering
<haasn>
we also need a third step for shifting/masking across bytes
<haasn>
for example for rgb565
<haasn>
this will go in between endian swap and swizzle
<PolarizationLead>
awaiting first usable version to compare with vf_pf2pf.c approach
ngaullier has quit [Remote host closed the connection]
ngaullier has joined #ffmpeg-devel
ngaullier has quit [Remote host closed the connection]
ngaullier has joined #ffmpeg-devel
<haasn>
PolarizationLead: how is pf2pf handling 4:2:0 <-> 4:4:4 conversions? hard-coded scalers?
hbbs has quit [Quit: bye]
<PolarizationLead>
haasn: lol, it does not handle scaling at all, i await your ground-breaking work there
<haasn>
fair
hbbs has joined #ffmpeg-devel
hbbs has quit [Changing host]
hbbs has joined #ffmpeg-devel
<haasn>
I originally wanted only one path for scaling
<PolarizationLead>
i'might get that far to do scaling/colorspace conversions in separate filters
<haasn>
so subsampled chroma would just be a special case of read planes -> filter h/v -> merge with luma
<haasn>
but I think that exact 2x scaling might be enough of a special case, plus having to deal with subpixel offsets (which the normal scaling path would _not_ need to care about)
<PolarizationLead>
my idea is to make in more modular, unscaled work - separate filter, scaling - separate filter, colorspace stuff - separate filter...
<haasn>
that it might make sense to continue having dedicated fast paths for chroma scaling
<haasn>
yeah, maybe
<haasn>
I mean that's ultimately the approach I'm going for as well, I just want to be able to fuse operations across "filters"
<haasn>
if you make each step a separate avfilter and actually go through memory for each step it will be way too slow I think
<PolarizationLead>
yes, by having one API call to rule them all..
<haasn>
I also want the ability to "optimize" redundant calls during compilation
<haasn>
for example, two matrix multiplications in a row should fuse to a single one
<haasn>
and an EXPAND operation followed by an identical COMPRESS operation should also fuse
<PolarizationLead>
yes, if they are independent
<haasn>
to a noop
<PolarizationLead>
yea, i'm aware that this "mine" modular approach might be issue, that will be shown as soon as i have some filter done on that part
<PolarizationLead>
i guess bilinear/nearest scaller is trivial to write
<PolarizationLead>
but how that plays with chroma positions? top-left, others? which others chroma positions?
<haasn>
I'm not sure what shape to give my SwsFilterOp though, I was thinking to give it float (*kernel)(float) directly and have the "compile" function generate the LUT
<haasn>
PolarizationLead: chroma positions for interlaced content is very nontrivial as well
<haasn>
you need to possibly handle chroma positions that lie outside the pixel itself
<haasn>
(i.e. chroma is in different row)
<PolarizationLead>
interlaced is not gonna be supported - i do not care for interlaced anything
<haasn>
heh
<haasn>
topleft, left and center are the only three used in practice afaict
<PolarizationLead>
does lavu have flags for all of them?
<haasn>
yeah
<PolarizationLead>
also arent LUTs an fixed numbers, and not fractional/float?
<haasn>
well, it doesn't have right-aligned chroma since that is (mercifully) not a thing
<haasn>
yeah, but since compile() is a slow path we can easily take a float function and compress it down to coeff_t in the last step
<haasn>
and actually I am 100% convinced this is the correct thing to do
<PolarizationLead>
how you gonna combine LUTs with linear interpolation?
<haasn>
because it lets us hide the bit depth of coeff_t as an implementation detail
<haasn>
and we could even increase this bit depth for HBD processing
<haasn>
I already have code for that, see libswscale/lut3d.c
<haasn>
but speaking of LUTs, they still leak coeff_t
<PolarizationLead>
also it would be awesome if LUTs size can be adjusted for better/higher quality..
<haasn>
oh, no, LUTs are currently hard-coded as 16-bit
<haasn>
that is actually problematic if we want to handle PAL8 decoding as a LUT op
<haasn>
hmm
<haasn>
PolarizationLead: for filtering the size is fixed
<haasn>
so there's nothing to adjust there
<PolarizationLead>
at init time?
<haasn>
changing the scaling ratio will require a full graph reinit in any case
<PolarizationLead>
i mean not changing thing at runtime
<haasn>
not sure what you're asking then
<PolarizationLead>
and also not having fixed quality LUT that converts from xyz to b709
<PolarizationLead>
that is fixed to 256x256x256
<haasn>
that is a different layer so irrelevant from the PoV of what I'm working on atm
<haasn>
but yes it would be nice to expose those sizes from libswscale/lut3d.c
<PolarizationLead>
and have it allocated on heap, and not hardcoded table in code
<haasn>
oh, to be clear, I am not reproducing any fixed XYZ to RGB code
<haasn>
that will be handled by the gamut mapping layer (lut3d.c)
<PolarizationLead>
about struct / function declaration ? is that really an unsolvable issue?
<haasn>
though I might add a fast path for when only matrix multiplications are needed
<haasn>
I guess not, I think I have a good solution in mind
<PolarizationLead>
are floats really enough for all colorspace stuff? or doubles are also needed?
<haasn>
floats are really good at representing color values, they are naturally log coded
<haasn>
assuming you're only using the parts from 0 to 1 that's still something like 30 bits of precision
<haasn>
way more than you'll ever need
<kepstin>
32bit floats have enough precision to exactly represent all 16 bit integers, fwiw
<haasn>
30 bits *gamma encoded* precision, at that
<PolarizationLead>
but once you start cascading */+/- and start getting denormals?
<haasn>
I don't think we do any operations that are prone to cascade errors
<haasn>
linear operations are like the best case scenario
<haasn>
consider that we use 16 bit floats on GPU and it's still more than visually lossless
<haasn>
you need something like 10 bits to start noticing errors
<haasn>
and even that is talking idealized conditions, comparing zoomed still frames
<haasn>
so 32 bits already gets you like a dozen bits of overhead for processing error
<haasn>
anyway, it would be easy to change retroactively
<haasn>
s/float/double/g
<kepstin>
honestly, the main reason to use 32bit instead of 16bit floats is that 32bit floats have better support in cpu simd operations
ccawley2011 has joined #ffmpeg-devel
abdu has quit [Ping timeout: 240 seconds]
abdu has joined #ffmpeg-devel
ccawley2011_ has joined #ffmpeg-devel
ccawley2011 has quit [Ping timeout: 252 seconds]
ccawley2011 has joined #ffmpeg-devel
ccawley2011__ has joined #ffmpeg-devel
ccawley2011_ has quit [Ping timeout: 252 seconds]
System_Error has quit [Ping timeout: 264 seconds]
ccawley2011 has quit [Ping timeout: 248 seconds]
System_Error has joined #ffmpeg-devel
ngaullier has quit [Remote host closed the connection]
ccawley2011 has joined #ffmpeg-devel
ccawley2011_ has joined #ffmpeg-devel
ccawley2011__ has quit [Ping timeout: 265 seconds]
ccawley2011 has quit [Ping timeout: 244 seconds]
ccawley2011 has joined #ffmpeg-devel
ccawley2011__ has joined #ffmpeg-devel
ccawley2011_ has quit [Ping timeout: 252 seconds]
ccawley2011_ has joined #ffmpeg-devel
ccawley2011 has quit [Ping timeout: 260 seconds]
ccawley2011__ has quit [Ping timeout: 252 seconds]
darkapex has quit [Remote host closed the connection]
darkapex has joined #ffmpeg-devel
realies has quit [Quit: ~]
realies has joined #ffmpeg-devel
Teukka` has quit [Read error: Connection reset by peer]
abdu99 has joined #ffmpeg-devel
Teukka has joined #ffmpeg-devel
Teukka has quit [Changing host]
Teukka has joined #ffmpeg-devel
abdu has quit [Ping timeout: 240 seconds]
realies has quit [Quit: ~]
System_Error has quit [Remote host closed the connection]
ccawley2011 has joined #ffmpeg-devel
System_Error has joined #ffmpeg-devel
ccawley2011_ has quit [Ping timeout: 252 seconds]
PolarizationLead has quit [Ping timeout: 240 seconds]
ccawley2011_ has joined #ffmpeg-devel
ccawley2011__ has joined #ffmpeg-devel
ccawley2011 has quit [Ping timeout: 252 seconds]
ccawley2011_ has quit [Ping timeout: 260 seconds]
ccawley2011 has joined #ffmpeg-devel
System_Error has quit [Remote host closed the connection]
System_Error has joined #ffmpeg-devel
ccawley2011__ has quit [Ping timeout: 276 seconds]
abdu25 has joined #ffmpeg-devel
abdu99 has quit [Ping timeout: 240 seconds]
abdu6 has joined #ffmpeg-devel
abdu8 has joined #ffmpeg-devel
abdu25 has quit [Ping timeout: 240 seconds]
abdu6 has quit [Ping timeout: 240 seconds]
System_Error has quit [Ping timeout: 264 seconds]
ccawley2011_ has joined #ffmpeg-devel
ccawley2011__ has joined #ffmpeg-devel
ccawley2011 has quit [Ping timeout: 272 seconds]
System_Error has joined #ffmpeg-devel
realies has joined #ffmpeg-devel
ccawley2011_ has quit [Ping timeout: 252 seconds]
Traneptora has quit [Quit: Quit]
realies has quit [Client Quit]
realies has joined #ffmpeg-devel
ccawley2011 has joined #ffmpeg-devel
ccawley2011__ has quit [Ping timeout: 244 seconds]
paulk has quit [Ping timeout: 272 seconds]
paulk has joined #ffmpeg-devel
abdu50 has joined #ffmpeg-devel
abdu8 has quit [Ping timeout: 240 seconds]
<fflogger>
[editedticket] MasterQuestionable: Ticket #11430 ([avformat] [Regression] Data stream in MPEG-TS may glitch "-stats" display in FFmpeg 7) updated https://trac.ffmpeg.org/ticket/11430#comment:4
uau has quit [Ping timeout: 252 seconds]
ccawley2011_ has joined #ffmpeg-devel
ccawley2011 has quit [Ping timeout: 252 seconds]
uau has joined #ffmpeg-devel
ccawley2011 has joined #ffmpeg-devel
ccawley2011_ has quit [Ping timeout: 252 seconds]
^Neo has joined #ffmpeg-devel
^Neo has joined #ffmpeg-devel
ccawley2011_ has joined #ffmpeg-devel
ccawley2011 has quit [Ping timeout: 260 seconds]
abdu53 has joined #ffmpeg-devel
abdu50 has quit [Ping timeout: 240 seconds]
System_Error has quit [Remote host closed the connection]