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 6.1 has been released! | Please read ffmpeg.org/developer.html#Code-of-conduct
dellas has joined #ffmpeg-devel
dellas has quit [Remote host closed the connection]
dellas has joined #ffmpeg-devel
dellas has quit [Remote host closed the connection]
APic has joined #ffmpeg-devel
epony has quit [Remote host closed the connection]
epony has joined #ffmpeg-devel
iive has quit [Quit: They came for me...]
jess is now known as sandy-claws
lexano has quit [Ping timeout: 245 seconds]
thilo has quit [Ping timeout: 256 seconds]
thilo has joined #ffmpeg-devel
thilo has joined #ffmpeg-devel
thilo has quit [Changing host]
navi has quit [Quit: WeeChat 4.0.4]
Guest4791 has quit [Read error: Connection reset by peer]
Guest47917 has joined #ffmpeg-devel
Guest47917 is now known as lemourin
jamrial has quit []
tmm1_ has joined #ffmpeg-devel
tmm1 has quit [Ping timeout: 260 seconds]
MisterMinister has joined #ffmpeg-devel
wyatt8740 has quit [Quit: ZNC got killed or something else has gone wrong, probably.]
wyatt8740 has joined #ffmpeg-devel
MisterMinister has quit [Ping timeout: 245 seconds]
PAUL007 has joined #ffmpeg-devel
mkver has joined #ffmpeg-devel
rvalue has quit [Read error: Connection reset by peer]
<BBB>
that sounds like how it was back when I worked on gstreamer
<BBB>
I think I concluded that pitivi is a video editor made by framework (gst) developers wanting a gst-based video editor, rather than by people who really need a video editor and decided gst is the best framework to base it on
<BBB>
I worked on a video player based on gstreamer for a while, and then eventually decided the problem was me - I don't care about video players at all. making me write a video player is a terrible idea
<BBB>
thardin: ^
lexano has quit [Ping timeout: 268 seconds]
lexano has joined #ffmpeg-devel
<thardin>
that's the immediate feel I got as well
<thardin>
just how ffmpeg is unsuitable for NLE work
<thardin>
or j2k in mxf
<BBB>
I think ffmpeg as a direct wrapper would be somewhat inconvenient, yes
<BBB>
j2k in mxf I can't really say :)
<BBB>
I guess I believe you. but isn't that how movies like meridian were released?
mkver has quit [Ping timeout: 252 seconds]
Krowl has joined #ffmpeg-devel
iive has joined #ffmpeg-devel
tmm1_ has joined #ffmpeg-devel
tmm1 has quit [Ping timeout: 264 seconds]
navi has quit [Quit: WeeChat 4.0.4]
ccawley2011 has quit [Ping timeout: 256 seconds]
MisterMinister has joined #ffmpeg-devel
<thardin>
yes
<thardin>
try to decode j2k realtime and you'll quickly discover some of the problems. and they can't really be addressed within lavf or in any library written in C I suspect
Krowl has quit [Read error: Connection reset by peer]
<thardin>
or not practicably so at least
Krowl has joined #ffmpeg-devel
Krowl has quit [Read error: Connection reset by peer]
navi has joined #ffmpeg-devel
<kierank>
need to use gpu for j2k
Krowl has joined #ffmpeg-devel
jamrial has quit []
mkver has joined #ffmpeg-devel
ccawley2011 has joined #ffmpeg-devel
<thardin>
that doesn't really help
<thardin>
entropy decoding is the heaviest part, and it's full of branches. I hear that russian guy did implement it on GPU but it seems it doesn't help much for lossless j2k
<thardin>
trying to compile the oldest versions of ffmpeg. the reliance on ancient mpg123 makes it difficult
<Lynne>
branches on GPUs aren't that big of a problem, you can mostly reduce their impact
<thardin>
october 2006 is too recent, june 2006 appears to maybe work
<thardin>
oh? even with the way j2k works, which is basically CABAC on every coefficient bit
<thardin>
neither openjpg, openjpeg nor lavc is particularly good for lossless or other high bitrate j2k
<elenril>
is anything?
<Lynne>
FPGAs and ASICs
<thardin>
lots of normal cores
<thardin>
but again no existing lib seems to support entropy decoding each CB separately
<Lynne>
thardin: you get about a million parallel invocations of a shader, way more than enough to assign one invocation per block, and for cabac, assign one invocation that covers one particular path of entropy decoding
<thardin>
even when there's 2^4096 paths per CB?
<Lynne>
eh, maybe not so much, but I'm sure there's a way
<thardin>
you can have the other cores block of course, but I'm not sure how you deal with the range decoding crap at the same time
<thardin>
shader cores that is
<thardin>
the IDWT can be done on GPU of course but that's the cheapest operation in j2k
<Lynne>
you use the parallelism to reduce the number of branches you take
<Lynne>
modern GPUs come with all sorts of features that break invocation isolation, like workgroup-wide ops
<Lynne>
so you can play tennis with bits if you need to
PAUL007 has quit [Ping timeout: 268 seconds]
<thardin>
I see
<thardin>
but also there's CPUs with 96 cores now
<thardin>
but no library does per-CB threading to make use of that
<elenril>
so then your definition of 'good' seems suspect
kurosu has quit [Quit: Connection closed for inactivity]
<thardin>
find me a library that can decode lossless 8k j2k realtime where seeking doesn't take several seconds due to frame threading
<Lynne>
how fast is that closed-source cuda decoder?
<thardin>
the build we got didn't run
s55 has quit [Ping timeout: 256 seconds]
<thardin>
but also EU rules prevents licensing it because russia
PAUL007 has joined #ffmpeg-devel
<thardin>
openjpeg showed some promise but couldn't handle truncated input
<Lynne>
there's apparently an official nvidia decoder
<Lynne>
nvJPEG2000
<thardin>
I suspect we looked at that too
<Lynne>
they say 4x speedup over some CPU on an a100, so that's what, 3fps :)
<Lynne>
maybe 12fps if you run it on a 4090 while expelling enough air to heat up a room over christmas
<thardin>
myeah
<Lynne>
keep in mind cuda sucks with regards to branch handling and lacks support to express some of the features modern gpus have
<Lynne>
that's why bwdif_vulkan is faster than bwdif_cuda
<Lynne>
where *do* you need fast losslessish jpeg2000 decoding?
<Lynne>
that isn't for DCP playback?
s55 has joined #ffmpeg-devel
<thardin>
a client wants it
<thardin>
there is a usecase for live preview of lossless j2k without proxies
<Lynne>
proxies?
<thardin>
lower resolution transcodes
<thardin>
which are annoying and not gratis to keep around
<Lynne>
for DCP authoring?
<thardin>
IMF
<thardin>
files get up to about 10 Gbps
<thardin>
sometimes over the network
s55 has quit [Ping timeout: 264 seconds]
<Lynne>
right, I forgot netflix accept that in imf for final deliverables
<thardin>
yeah, and they're not alone
<Lynne>
I can see where it can be useful
<Lynne>
but for such a one-off use, maybe getting one of those expensive boxes may be a better idea
<thardin>
there we go, managed to build ca9118c87 (jul 30 2001)
<Lynne>
either that, or a huge 168-core CPU as well as a large paycheck (or paying someone to write a maybe unsuccessful GPU implementation and an even larger paycheck)
<thardin>
we use some of the more expensive boxes in uncle jeff's big computer cluster
<thardin>
96 cores I think
<thardin>
it's just barely possible
navi has quit [Quit: WeeChat 4.0.4]
s55 has joined #ffmpeg-devel
<thardin>
got this old version to encode an mp2 file. amazing
dellas has quit [Remote host closed the connection]
Krowl has quit [Read error: Connection reset by peer]
<thardin>
I'm curious about a more langsec way to handle multimedia parsing and transcoding and such ancient versions serve as a useful testbed
<thardin>
it's been interesting to watch kostya exploring rust, but I fear it too is not up to snuff in guaranteeing correct parsing
<elenril>
haskell is the way, duh
<thardin>
haskell is one way
<thardin>
it's been a while since I looked into it
<thardin>
a basic feature I'm looking for is range types
<thardin>
ooh coq can reason about haskell programs
<thardin>
the fact that contracts are often the hardest things to write rather than the program itself makes me suspect it's possible to program using only contracts
<thardin>
"this file implements an H.264 decoder because the contract says so"
<thardin>
maybe agda
<thardin>
even something simple like put_bits() is tricky to prove it doesn't have any nasty
<thardin>
bugs
<Lynne>
rust has no safe way of exporting multiple slices of a buffer to multiple threads to enable slice threading
<Lynne>
the code in rav1e took 3 months to write and it's just a wrapper around unsafe code
<thardin>
lol
<thardin>
I know there are formal methods for dealing with locking
<thardin>
probably is something for synchronizing thread access to buffers too
<BtbN>
Just don't slice then. People want "safe", they get safe and slow.
<thardin>
you can have both
<JEEB>
thardin: I'm so thankful itunes ingest rules are much more bearable
<JEEB>
with MP4/MOV with stuff
<thardin>
oh yeah
<thardin>
avid is awful with that
dellas has joined #ffmpeg-devel
PAUL007 has quit [Ping timeout: 240 seconds]
ccawley2011 has quit [Read error: Connection reset by peer]
tobias_ has joined #ffmpeg-devel
tobias_ has quit [Client Quit]
<kierank>
thardin: use comprimato
<thardin>
looks like htj2k
<thardin>
which of course is faster. but there's plenty of j2k matdrial
<thardin>
convincing people to convert their j2k files to ht is above my pay grade :)