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.1 has been released! | Please read ffmpeg.org/developer.html#Code-of-conduct
abdo1 has joined #ffmpeg-devel
abdo1 has quit [Client Quit]
Kei_N_ has joined #ffmpeg-devel
Kei_N has quit [Ping timeout: 252 seconds]
abdu has quit [Quit: Client closed]
System_Error has quit [Remote host closed the connection]
System_Error has joined #ffmpeg-devel
mkver has quit [Ping timeout: 265 seconds]
grillo_0 has quit [Quit: Ping timeout (120 seconds)]
grillo_0 has joined #ffmpeg-devel
tufei has quit [Remote host closed the connection]
tufei has joined #ffmpeg-devel
Martchus has joined #ffmpeg-devel
Martchus_ has quit [Ping timeout: 265 seconds]
jamrial has quit []
cone-541 has joined #ffmpeg-devel
<cone-541>
ffmpeg Zhao Zhili release/7.1:9237125e51a4: avformat/mov: Reduce seek when interleaved_read is disabled
<cone-541>
ffmpeg Zhao Zhili release/7.1:94784d091893: avcodec/bsf/h264_mp4toannexb: Fix mixed bitstream format
<compn>
why are you stream copying mpegts to flv thardin
<compn>
flv died with adobe in my mind /s
MisterMinister has quit [Ping timeout: 245 seconds]
System_Error has quit [Remote host closed the connection]
<kurosu>
jkqxz: I see the LUT approach also breaks for some codebooks as in prores. Glad you caught that, it did hurt there
<kurosu>
ff_apv_entropy_build_decode_lut: aren't the codebooks static? Maybe it's not critical, but it feels like this should a run once thing, or whatever. With the caution that these tables being static could cause large binary sizes ofc
<kurosu>
should be
<kurosu>
Also, not a fan of the Put/GetBitContext: I'd go directly with bit twiddling (see eg how legacy vlc table building does/did it), but maybe this is cleaner
<jkqxz>
Yeah, it's all static. ~100KB of binary size, though.
<kurosu>
Ah. I'd thought large coeffs * sufficient tables could build up to many codewords. Maybe not the 30k of prores and its excessive cb switching
<jkqxz>
It is pretty annoying to do with bit-twiddling, and didn't seem worth it. The one-time cost is not much in this form.
<kurosu>
I think this is moot, but also wondering about compacting APVSingleVLCLUTEntry. For instance, number of bits being negative would be the value that more holds. But then the struct size would no longer be a power of 2
<kurosu>
And I imagine with 12bits content, there can be 14bits DC coeffs
<kurosu>
(maybe more)
<kurosu>
"more" holds
<kurosu>
ah, you did use bitfields for the multi one
<jkqxz>
The approach is always to do a single lookup and then use bit-twiddling if it fails, so the large coeffs don't end up in it.
<jkqxz>
Agree that the single table could hold some more helpful information (e.g. length of code if the lookup has enough bits to tell you that), but it's only used for the DC coefficient now so is not the critical part.
<kurosu>
Interesting, probably worthwhile for at least transform-based codecs
<kurosu>
ok about the single think, didn't catch that
<kurosu>
APVMultiVLCLUTEntry: no hole in the struct, but strange to see the larger elements in the middle. Probably laid in the order of use ?
<kurosu>
'next_bits = show_bits(gbc, 16);' <- you do hit that large a value? Somehow expecting a smaller value, but maybe again 12bits + lowquant + ...
<kurosu>
for later likely: have you try folding the sign reading in the vlc entry/ies?
<kurosu>
*single thing
<jkqxz>
Not in any particular order. The assembly just loads single bytes or words anyway, so it doesn't make much difference beyond maintaining alignment (which is why the bitfields for the least-used fields).
<jkqxz>
The golomb-style codes give you 2N bits for an N bit coefficient, so there are always some very long cases.
<jkqxz>
The 18 is enough to always capture a whole run (and then it constructs it via bit twiddling), a long AC coefficient takes multiple reads.
<jkqxz>
I did try to fold the single table into the multi table, but it's really annoying.
<jkqxz>
The DC coefficient is parameterised separately so even if it looks like an AC coefficient it can't go the level-first entry because it messes up the second coefficient.
<jkqxz>
And it has the sign reading conditional on whether the value is zero or not. I tried an early zero detection case, but that made it slower vs. just doing the lookup.
<jkqxz>
Hmm. I could have a whole separate DC-first table which in best case would give DC/run/first-AC/run. That would absorb all the special cases but be larger.
abdu has joined #ffmpeg-devel
<kurosu>
OK. The sign reading is just something that sparked a recollection in prores
System_Error has quit [Remote host closed the connection]
<cone-541>
ffmpeg xiongweixiao master:8ce32a7cbb17: lavf: vvc_probe: lower probe score for invalid SPS/PPS/IRAP order to avoid misdetection of mp3 as VVC
System_Error has joined #ffmpeg-devel
tufei_ has joined #ffmpeg-devel
tufei has quit [Ping timeout: 264 seconds]
mkver has joined #ffmpeg-devel
System_Error has quit [Remote host closed the connection]
System_Error has joined #ffmpeg-devel
abdu has quit [Ping timeout: 240 seconds]
abdu has joined #ffmpeg-devel
<ramiro>
haasn: I modified the shuffle solver to check for SWS_OP_CLEAR with a nonzero value. I perform an or operation after the shuffle with the constant values. this might help the x86 backend as well.
<ramiro>
also from my tests, on out-of-order arm cores, it's almost always faster to use ld1/shuffle/st1 instead of ldX and stX with packed data (except on some pathological cases where a dozen tbl and orr instructions are needed)
<ramiro>
I'm even thinking of extending the shuffle solver to accept either input or output being planar.
Anthony_ZO has quit [Ping timeout: 252 seconds]
<haasn>
Lynne: ffmpeg -vf format=yuv420p,hwupload,format=vulkan,libplacebo is still much slower than ffmpeg -vf format=yuv420p,libplacebo
<haasn>
any idea why that could be the case?
<haasn>
with -init_hw_device vulkan=vk -filter_hw_device vk
<haasn>
like, almost half the fps
<Lynne>
nvidia?
<haasn>
yep
<haasn>
are you using the tx queue?
cone-541 has quit [Quit: transmission timeout]
<Lynne>
yes
<Lynne>
I can implement the host transfer extension which is the official khronos-blessed way to do this, rather than host-mapping buffers
minimal has joined #ffmpeg-devel
jamrial has joined #ffmpeg-devel
Dariusz has quit [Ping timeout: 252 seconds]
HarshK23 has quit [Quit: Connection closed for inactivity]
APic has joined #ffmpeg-devel
abdo98 has joined #ffmpeg-devel
abdo98 has quit [Client Quit]
MisterMinister has joined #ffmpeg-devel
HarshK23 has joined #ffmpeg-devel
abdu has quit [Ping timeout: 240 seconds]
abdu has joined #ffmpeg-devel
user23 has joined #ffmpeg-devel
abdu32 has joined #ffmpeg-devel
abdu has quit [Ping timeout: 240 seconds]
<haasn>
Lynne: which ext is that?
<Lynne>
VK_EXT_host_image_copy
<haasn>
oh, neat
<haasn>
but I don't think that can be the reason, libplacebo also uses host memory imports
<Lynne>
how's the performance on AMD?
abdu32 has quit [Ping timeout: 240 seconds]
minimal has quit [Quit: Leaving]
<haasn>
Lynne: 7k fps libplacebo upload vs 4.3k fps hwupload
<haasn>
the most accurate part of this meme is that the entire entertainment industry rests on the shoulders of porn
natto17 has quit [Ping timeout: 260 seconds]
abdu has joined #ffmpeg-devel
<beastd>
thardin: that's a funny one :) tho it's seems wildly inaccurate that netflix is build on top off p*rnhub, tiktok, twitch, instagram and facebook *thinking
<beastd>
haasn: maybe that's true, but not on the building blocks it provides to build and deploy streaming / vod platforms. that would be more about content and market and not on the tech side :)
<thardin>
what haasn said
<thardin>
legend has it this is why VHS won over betamax
rvalue- has joined #ffmpeg-devel
<beastd>
thardin: wonder if that one is actually true. but surely it's a "sustainable legend"
rvalue has quit [Ping timeout: 260 seconds]
<compn>
the weird thing is no one has tried to commercially replace ffmpeg. like sony or adobe or apple
<compn>
also weird that google hobbled together mencoder and ffmpeg. instead of gstreamer or something
<thardin>
trying to be maximally compatible kind of goes against what companies usually do
<compn>
thardin, so why are you stream copying mpegts h264 to flv h264 ?
<compn>
:D
abdu15 has joined #ffmpeg-devel
<thardin>
actually I was stream copying from mp4 to mpegts to flv
* compn
facepalms
<thardin>
I solved the issue by copying from mp4 to flv to flv
<compn>
yep thats what i would suggest :)
rvalue- is now known as rvalue
<thardin>
in this case I was lucky that the output was rtmp. flv is necessary for adding closed captions because libcaption has a tool for it, that only understands flv
natto17 has joined #ffmpeg-devel
<compn>
its not too late, we can still kill rtmp /s
<thardin>
if the output were hls it'd probably go mp4 -> mpegts -> flv -> mp4
<thardin>
or, not any more
<compn>
fmp4 is the devil
<thardin>
at least it isn't mxf
<compn>
"how can we make our 30 year old mp4 format streamable?" "just cut it into 1000 pieces"
<thardin>
or I mean MXF is the best. everything should be MXF
abdu has quit [Ping timeout: 240 seconds]
<compn>
its true i dont touch mxf
<beastd>
compn: maybe variation on postel's law. for platforms like yt it is/was presumably interesting to accept as much as possible if it helps them to get more content on their platform. anyway it's surely by now also a question about history and economic viability
<JEEB>
at least ISOBMFF is kinda standardized and utilized as such, while MXF and stuff like cropping out of view data from 576i etc is "fun"
<thardin>
ISOBMFF also supports cropping. and rotation
<JEEB>
yes
<thardin>
MXF is extra fun in that it can have multiple levels of cropping
<compn>
beastd, i dont even mean supporting all inputs. but i'm pretty sure they still run ffmpeg 100000000s of times per day to reencode video from one format to another h264>vp9>av1 etc
<JEEB>
but basically the interpretation of various values seemed to come from some common best practices spec
<thardin>
a file doesn't just have one resolution. it has up to four if I remember correctly
<compn>
per second/ per day
<JEEB>
yea, there were multiple
* JEEB
used to poke into MXF years ago
<JEEB>
oh, and multi-track audio mappings
<JEEB>
8 mono tracks and no metadata on how to map
<thardin>
fun
<JEEB>
while in QTFF/ISOBMFF you at least can have per-track metadata
<JEEB>
and it is actually kinda implemented in the reader
<thardin>
you can do that with MXF too. both on the materialpackage layer and the filepackage layer
<thardin>
because MXF is basically AAF you can do all kinds of things
<JEEB>
so you can tag the channel as center, left, right etc?
<JEEB>
and people just don't utilize it because lol why
<thardin>
I.. hm. I'm not sure. but you can have various types of metadata on an essence stream
<JEEB>
yea, that I fully understand. I was specifically noting the audio channel definition metadata per-track. which is supported by avformat, but just the whole ffmpeg.c use case doesn't utilize it since it wants to pick a single track
<thardin>
yeah that's more of an NLE kind of operation. ffmpeg isn't really for NLE stuff
<JEEB>
and thankfully apple wants somewhat sane stuff for itunes input
<compn>
does ffmpeg have a goal ?
<JEEB>
so you often can point at the itunes ingest spec
<JEEB>
"this big vendor would not take this crap in, so uhh... try to keep sanity of samples on that level"
<thardin>
I've been pointing out for a while that ffmpeg shouldn't do stuff that other tools already do, so as to not waste developer time
<compn>
i like that idea
<thardin>
so for example, rather than trying to cram NLE features into the program, we could instead work on melt
<compn>
what is melt
<thardin>
it's the backend almost all libre NLEs are built on top of. most notable kdenlive