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.1 has been released! | Please read ffmpeg.org/developer.html#Code-of-conduct
rvalue has quit [Ping timeout: 260 seconds]
rajivharlalka has quit [Quit: Connection closed for inactivity]
rvalue has joined #ffmpeg-devel
kurosu has quit [Quit: Connection closed for inactivity]
MisterMinister has quit [Ping timeout: 268 seconds]
MisterMinister has joined #ffmpeg-devel
iive has quit [Quit: They came for me...]
feiwan1 has joined #ffmpeg-devel
thilo has quit [Ping timeout: 260 seconds]
thilo has joined #ffmpeg-devel
thilo has quit [Changing host]
thilo has joined #ffmpeg-devel
IndecisiveTurtle has quit [Ping timeout: 260 seconds]
<Lynne>
mkver: did you test compilation for mips?
<mkver>
With your patchset?
<Lynne>
no, without
<Lynne>
can't get anything to compile, the assembler errors out on register indices
<Lynne>
on a mips64 with an FPU
<mkver>
"Error: float register should be even, was 11"
<Lynne>
yup, that
<mkver>
I think the issue is with HAVE_MIPSDSP.
<mkver>
It works if that is 0.
<mkver>
Lynne: How about we just nuke the code that no longer compiles?
<mkver>
Just like I did in f1b08b8a65c0cc3f.
qeed has joined #ffmpeg-devel
qeed_ has joined #ffmpeg-devel
qeed_ has quit [Remote host closed the connection]
<Lynne>
yeah, I agree
<Lynne>
I'll add those commits in my patchset
<Lynne>
I'll try on loongson just in case
<mkver>
--cpu=loongson3 works here
CoreX has quit [Ping timeout: 252 seconds]
CoreX has joined #ffmpeg-devel
cone-735 has quit [Quit: transmission timeout]
mkver has quit [Ping timeout: 260 seconds]
<Sean_McG>
isn't nuking it going to do bad things to people with Loongson setups?
<Marth64>
set title=1..n (or demux with ffmpeg and enjoy)
<Marth64>
I'll put a ticket on Trac, but basically in that command ^ instead of exiting after an error that I can't remux TX3G->Matroska, ffmpeg cli hangs
<Lynne>
ah, that's sad
<Marth64>
I'm working on it :)
<Marth64>
It is working on my local, except for dual layer discs (timestamps reset in the middle...so picking at it slowly)
<Marth64>
sorry for the confusion -- the error I called out after "Hmmm.." msg is what I meant hangs. anyway I'll put it on Trac
rajivharlalka has quit [Quit: Connection closed for inactivity]
Krowl has quit [Read error: Connection reset by peer]
MisterMinister has quit [Ping timeout: 264 seconds]
kurosu has joined #ffmpeg-devel
Krowl has joined #ffmpeg-devel
<wbs>
BtbN: the binary you linked seems to run just fine
<wbs>
BtbN: the win devkit 2023 is supposedly pretty nice HW, but not really possible to buy any longer, at least not within europe
<wbs>
(I was considering whether to try to get one, it was possible to buy in UK/germany/france at the start, but nowadays it's all just listed as out of stock)
rajivharlalka has joined #ffmpeg-devel
mkver has joined #ffmpeg-devel
cone-011 has joined #ffmpeg-devel
<cone-011>
ffmpeg Andreas Rheinhardt master:a7ad5d4d10ec: avformat/iamfenc: Remove always-false check
<cone-011>
ffmpeg Andreas Rheinhardt master:6a9ddfcd9683: avformat/iamfenc: Align check and error message
<cone-011>
ffmpeg Andreas Rheinhardt master:cd8cc3d1b39b: avformat/iamfenc: Remove unused headers
Krowl has quit [Read error: Connection reset by peer]
Krowl has joined #ffmpeg-devel
Chagalle has joined #ffmpeg-devel
IndecisiveTurtle has joined #ffmpeg-devel
<IndecisiveTurtle>
Hello not sure if this is the right place, but it was mentioned it was a good place to come in contact with. I'm a first year undergraduate student and wanted to apply for one of the gsoc projects. I have 2 years of experience in writing vulkan code and have hands-on experience with x86-64 (have written a moderately fast JIT) and ARM64 assembly. So I found the x86/arm64 asm projects the Vulkan VC2 encoder you have h
<JEEB>
nice re: vulkan
<JEEB>
I think Lynne is sleeping right now, but she's probably the one related to that projects?
<JEEB>
and yes, this is the correct IRC channel :)
<galad>
IndecisiveTurtle: your message seems truncated here, it stops with "encoder you have h"
<IndecisiveTurtle>
Ah no idea why, it ended with "encoder you have here the most interesting of the bunch xD"
<Lynne>
can't sleep, too bright
<Lynne>
IndecisiveTurtle: sure, the qualification task is to make a multi-level 2D haar transform that does an in-place transformation
<IndecisiveTurtle>
Lynne: Sure thing, I can start tackling that today. And thanks for the link, it saved me a lot of research :p
<Lynne>
you should still do research on discrete wavelet transforms, you have to know how after transforming, you're left with four quarter-sized images
<Lynne>
and how for multiple levels, you perform the transform on one of the quarter-sized output images from the previous transform
DuckInspector has joined #ffmpeg-devel
<IndecisiveTurtle>
Yeah definitely I want understand all the topics here necessary before the work begins
DuckInspector has left #ffmpeg-devel [#ffmpeg-devel]
Chagalle has quit [Read error: Connection reset by peer]
dre-droid has joined #ffmpeg-devel
<IndecisiveTurtle>
Should have started a bit earlier tbh with this but now I feel like I need to hurry to have time to make a proposal :/
<Lynne>
you should write down a 2D haar transform of a small 8x8 block on a piece of paper, where you just write down which pixel is the average of two, or the difference of two
<Lynne>
and highlight which ones, after performing the transform in both horizontal and vertical direction, belong to the quarter-sized original image
<Lynne>
then you just need to repeat the same transform function, but with twice the stride
ffc0 has joined #ffmpeg-devel
<IndecisiveTurtle>
Alright will do that today after classes today. Also found a shadertoy example online, it appears understandable
<ffc0>
Hi everyone, having some problem since 16 march to build ffmpeg against libbluray, do someone have encountered same issue, something changed into fftools seems to be the cause any hint? latest good was commit 605fc72f19ed975df6b36ea13d9f63b1fe9c852a
<mkver>
TLDR: Use macros to rename one of the symbols or stop linking libbluray statically.
<ffc0>
mkver: i didn't see that one. will try thanks
<Lynne>
IndecisiveTurtle: keep in mind, in ffmpeg we're only using compute shaders
<IndecisiveTurtle>
Is that due to performance reasons or because compute pipelines are easier to setup than graphics ones?
dre-droid has quit [Remote host closed the connection]
<BBB>
a license to compile, wow
<BBB>
that's new
<JEEB>
yea
<JEEB>
basically "all rights reserved"
<BBB>
so the binary blob comment means "we cannot compile it", as opposed to "it's actually a binary blob", right?
<JEEB>
more or less
<BBB>
as in, we do get source code, we just are not permitted to use (compile) it
<JEEB>
well, OK. giving those rights that github requires so it can show the cod eetc
<BBB>
how ... innovative
<BBB>
inNOVAtive?
<BBB>
see what I did there
* BBB
runs
rajivharlalka has quit [Quit: Connection closed for inactivity]
<nevcairiel>
yeah the inability to even compile and test it without obtaining a license first is the argument here. non-free usually means you can do that, just not distribute, which is fine. but restricting local use should just kill it from consideration
<BBB>
yeah, also philosophically, it just doesn't feel right
<Lynne>
IndecisiveTurtle: both
<Lynne>
these days I wouldn't even use vertex shaders for anything because mesh shaders are just better
<JEEB>
BBB: yea, like fdk-aac is still open source, just that it has those things which seem to make it (according to some lawyers) not compatible with GPL
<JEEB>
this stuff can't be called open source :D
<JEEB>
(even though the source code is in the open)
<BBB>
how difficult would it be to reimplement? or is it just a neural network of MACs?
<JEEB>
it has a spec since V-NOVA licked the right people
<JEEB>
so as I said, it can be reimplemented if someone cares enough
<BBB>
I wonder if they'll go all dolby on us if we do that
<JEEB>
I actually wonder what the license for the referecen implementation is... if it has one
<Lynne>
license to compile?
<JEEB>
yes, they explicitly mention it
<Lynne>
no, I meant the original topic, I don't follow why v-nova was brought up
<BBB>
patch on ML to add support to ffmpeg
<JEEB>
original topic was the patch set for lc-evc avfilter wrapper
<JEEB>
which uses their library
<JEEB>
which has a hilarious COPYING and license in README
<JEEB>
BBB was just verifying if he understood the comments correctly
<IndecisiveTurtle>
Lynne: Mesh shaders are pretty cool, I'm curious to try them at some point. Though in the project I worked on (Citra Emulator) they had an application, the app needed to run on very crappy mali devices with vulkan 1.1 so many features were to be considered "niceties"
<BBB>
right
<BBB>
+ --stdcxx=STDCXX use C standard STDCXX [$stdcxx_default]
<BBB>
should that be "C++ standard"?
<Lynne>
IndecisiveTurtle: we require 1.3, with the buffer address extension to use real pointers in glsl
<haasn>
BBB: surely this license is unenforcable
<BBB>
in fate tests running in publicly visible instances?
<BBB>
I'm not so sure
<BBB>
for personal use, I don't know how they'd prove it
<IndecisiveTurtle>
That's cool 1.3 is so awesome just with dynamic rendering/state extensions and you get to weed out all the subpar drivers too xD
<BBB>
but we're an opensource project, everyone should be able to download, compile and run - and reproduce our test instances
<IndecisiveTurtle>
But yeah if you use compute shaders only, it wouldn't matter too much ehre
<IndecisiveTurtle>
The first part
<haasn>
graphics shaders are good for drawing lots of triangles; in image processing we only draw a single quad
<haasn>
so the performance difference evaporates
<IndecisiveTurtle>
The only time I was forced to use fixed pipeline iirc was related with format support. Some formats don't support storage writes can be color attachments so if you want to do a conversion pass with that as dest it can't be a compute shader
<IndecisiveTurtle>
You probably can write to a buffer though can then copy it to the image afterwards tbh, but eh
<haasn>
in dav1d-gpu I learned to fully embrace the gpgpu paradigm
<haasn>
no images, no graphics pipelines
<haasn>
just compute shaders accesing host memory over DMA, as linear storage buffers
<haasn>
bindless everything, just use push constants and pointers/offsets
<haasn>
it's a really elegant model in that it evaporates much of the traditional complexity of interop'ing GPU with CPU processing
<haasn>
no texel buffers either, in fact no texel formats at all
<haasn>
just raw int8/int16 access
<JEEB>
:)
Workl has joined #ffmpeg-devel
Krowl has quit [Ping timeout: 264 seconds]
_whitelogger_ has joined #ffmpeg-devel
feiwan1 has quit [*.net *.split]
Teukka has quit [*.net *.split]
stevenliu_ has quit [*.net *.split]
zsoltiv_ has quit [*.net *.split]
Gramner has quit [*.net *.split]
_whitelogger has quit [*.net *.split]
jamrial has joined #ffmpeg-devel
* Sean_McG
peeks in
feiwan1 has joined #ffmpeg-devel
IndecisiveTurtle has quit [Ping timeout: 240 seconds]
<jamrial>
i wonder if you should disable memory-poisoning for this node
<Sean_McG>
I can do that, sure
cone-980 has joined #ffmpeg-devel
<cone-980>
ffmpeg Jan Ekström master:28783896dca9: avutil/frame: split side_data_from_buf to base and AVFrame func
<cone-980>
ffmpeg Jan Ekström master:d5104b3401f9: avutil/frame: split side data list wiping out to non-AVFrame function
<cone-980>
ffmpeg Jan Ekström master:919c9cdbe6d2: avutil/frame: add helper for freeing arrays of side data
<cone-980>
ffmpeg Jan Ekström master:d2bb22f6d5c1: avutil/frame: split side data removal out to non-AVFrame function
<cone-980>
ffmpeg Jan Ekström master:f287a285d91b: avutil/frame: add helper for getting side data from array
<cone-980>
ffmpeg Jan Ekström master:53335f6cf42f: avutil/frame: add helper for adding side data to array
<cone-980>
ffmpeg Jan Ekström master:3c52f73e253e: avutil/frame: add helper for adding existing side data to array
<cone-980>
ffmpeg Jan Ekström master:d9ade14c5c55: {avutil/version,APIchanges}: bump, document new AVFrameSideData functions
<cone-980>
ffmpeg Jan Ekström master:0d36844ddf90: avcodec: add frame side data array to AVCodecContext
<cone-980>
ffmpeg Jan Ekström master:8f4b173029aa: ffmpeg: pass first video AVFrame's side data to encoder
<cone-980>
ffmpeg Jan Ekström master:f4b89b6e5457: avcodec/libsvtav1: add support for writing out CLL and MDCV
<cone-980>
ffmpeg Jan Ekström master:471c0a34c13a: avcodec/libx264: add support for writing out CLL and MDCV
<cone-980>
ffmpeg Jan Ekström master:d7d2213a6bdd: avcodec/libx265: add support for writing out CLL and MDCV
<JEEB>
there we go
<JEEB>
I like how the svt-av1 commit is from 2023-03-10 8)
<mkver>
Ok, I know why ASAN doesn't work (and why my setup works): It is due to EXTERN_PREFIX. Recent ASAN by default creates an __odr_asan.foo symbol for every object (not function) foo. Our configure script test sees this and infers that the extern prefix and EXTERN_ASM "__odr_asan." should be used and this makes the assembler mangle the function names with a leading underscore; but the actually required functions don't use this
<mkver>
underscore.
<jamrial>
JEEB: the channel layout set started in 2013 :p
<mkver>
This can be fixed by -fno-sanitize-address-use-odr-indicator
<mkver>
Or rather worked around.
<JEEB>
jamrial: :)
<mkver>
Seems like GCC does not accept this, so one can only use ASM-ASAN with clang for now.
<mkver>
But actually it is an issue in how our build system decides whether function and object names need to be mangled.
<JEEB>
sounds quite possible
<frankplow>
mkver: Just tested, I can compile --toolchain=clang-asan without --disable-asm for clang <= 15.0.7. Guessing this corroborates your theory
rvalue has quit [Ping timeout: 252 seconds]
tufei has joined #ffmpeg-devel
<JEEB>
Marth64: did your patch set for the CC demuxer get any further reviews? or it's just an LGTM and basically needs someone to push it?
<Marth64>
JEEB: mkver reviewed again with valid points, need to update. working on it asap
<JEEB>
gotcha
<Marth64>
thx for pinging it's actually a useful feature imo
<Marth64>
you can also retime CCs is what I've found with it , -itsoffset etc work
<Marth64>
i have yet to find another solution to do that
<Marth64>
that is oss
rvalue has joined #ffmpeg-devel
<JEEB>
I think itsoffset only works well for subtitles due to ffmpeg cli's logic :D
<JEEB>
it adjusts it, and then that adjustment isn't taken into account when dragging the timestamps to start at zero
<Marth64>
i will spend more time in subtitles, i think that is where i can best try to contribute (i know little about dsp/codecs)
* JEEB
has barely written one huffman-based encoder
<Marth64>
if anything this has been a learning experience in C for me hahaha
IndecisiveTurtle has joined #ffmpeg-devel
qeed has quit [Quit: Leaving]
IndecisiveTurtle has quit [Remote host closed the connection]
IndecisiveTurtle has joined #ffmpeg-devel
<jamrial>
JEEB: next could be adding cli options to set cll and mdcv for encoding/remuxing, using the same syntax from other tools
IndecisiveTurtle has quit [Read error: Connection reset by peer]
IndecisiveTurtle has joined #ffmpeg-devel
<Marth64>
mkver: if I'm reading it correctly, ff_subtitles_queue_insert() also has a merge option already I did not realize. so I think that can also serve to solve the previous point of merging clusters 2>=16 (still debating if needed but the merge argument opens that window cleanly I think).
<mkver>
Exactly.
<mkver>
Are there actually oversized packets in practice?
<Marth64>
I have not seen any in the ~200 DVD/ATSC/SCTE sources I've processed. I also am unclear how ccextractor handles this case or if it does at all when demuxing. I should be able to put together a forged file to see how both applications behave.
<Marth64>
~196Kb of a eia608 packet for a single PTS tick is unrealistic, a 20 minute video in my sample set averages ~70Kb for the whole duration. but this format is littered with hacks and encoder oddities so it's a faint possibility still.
<Marth64>
"this format" being eia608 in general, not rcwt
<mkver>
If it's not really a thing, then there is no need for it.
<Marth64>
Are you ok with logging a warning if there is an occurrence, at least the user then is aware and if it becomes a thing it can be repoted vs. silently doing wrong behaviour?
<Marth64>
Will remove the other useless logs.
<mkver>
should be info, not warning
<Marth64>
good deal. thanks.
<JEEB>
jamrial: I'll first try to add listing of supported things into encoders
<JEEB>
so they become visible in `ffmpeg -h encoder=libsvtav1` for example
Warcop has joined #ffmpeg-devel
Warcop has quit [Remote host closed the connection]
Warcop has joined #ffmpeg-devel
IndecisiveTurtle has quit [Read error: Connection reset by peer]
IndecisiveTurtle has joined #ffmpeg-devel
<Lynne>
jkqxz: ping
<cone-980>
ffmpeg James Almer master:6c2ff982dcbe: configure: make the C and C++ standard settable
<cone-980>
ffmpeg James Almer master:5ff0eb34d2b1: configure: check for C17 by default
<Sean_McG>
yay \o/
<BtbN>
Anyone from the US who can buy and ship something to me? Will pay obviously
Marth64 has quit [Ping timeout: 264 seconds]
Marth64 has joined #ffmpeg-devel
<wbs>
BtbN: arm devbox? if you manage to get one, let me know and I'd like to get one too
<BtbN>
It's a used one
<wbs>
oh, I see
<BtbN>
I did order it now, via a proxy shipping service
<BtbN>
The seller claims to have used it as a daily driver
<Sean_McG>
jamrial: ... is there an _ISOC17_SOURCE ? just a thought while I was compiling now
<jkqxz>
(Not tested at all, just transcribing the relevant bits of the spec and it not obviously exploding.)
<Marth64>
I can order/ship
<BtbN>
I think I'm good. Found that there is plenty services that handle it for incredibly cheap, probably cheaper than an individual could
<Marth64>
cool. I live next to 2 post office if needed in the future, and yes they do rip us off on individual shipping haha
<jkqxz>
Don't forget that you'll be hit for VAT on the import.
<Marth64>
BtbN: Which one did you end up getting?
<Marth64>
just curious
<BtbN>
There is more than one?
<BtbN>
It's the Microsoft Devkit
<Marth64>
Ahhh. I imagined a laptop. Got it.
<jamrial>
Sean_McG: don't think so
<BtbN>
I wanna turn it into a fate box, so the devkit seems more convenient
<jamrial>
c17 is just bugfixes and clarifications
<Sean_McG>
aye, I just Googled it, no hits
<Lynne>
jkqxz: looks fine
<Lynne>
my ref bias code is identical though
<jkqxz>
Probably? When I said "make the code look like the spec" I really did mean "make the code look like the spec". Putting the variables in different orders and inverting conditions makes it harder to tell that it's actually the same.
<Lynne>
I put them exactly the way they are in the spec
<Lynne>
doesn't matter, as long as it works
<Lynne>
do you think the vulkan part of the code is correct?
<jkqxz>
Which? I didn't write anything on that for SavedOrderHints.
mkver has quit [Ping timeout: 272 seconds]
<Lynne>
the part where it saves the order hints at the time of decoding, and uses them when the frame is ref'd?
<Lynne>
(though now it would be saving saved order hints?)
<jkqxz>
ref[i].saved_order_hints[j] is spec SavedOrderHints[i][j].
<jkqxz>
The Vulkan specification's definition of RefFrameSignBias is still confusing. It's used in a context where it should mean relative to the reference frame, but the AV1 specification doesn't use that.
<Lynne>
in practice, though, everyone expects the bitstream values, put in a bitmask
<Lynne>
so how should we get this merged?
<jkqxz>
Why does the field exist at all, then?
andrea3 has quit [Quit: WeeChat 4.2.1]
<Lynne>
if you see weird field, it's nvidia's fault, and their obsession with memory reduction
<jkqxz>
Right, that is the sign bias from the point of view of the reference frame, not the one in the immedate bitstream. So that's not what the spec says.
Marth64 has joined #ffmpeg-devel
<jkqxz>
Or maybe it is, depending on how you read it.
<jkqxz>
In any case, that's not the same as the ffmpeg patch, so I'd say make it agree with that if that's an official example.
<jkqxz>
And I think that's the last open question.
iive has joined #ffmpeg-devel
s55 has joined #ffmpeg-devel
<Lynne>
jkqxz: it's a semi-official example
<Lynne>
it's the world's worst example, undoubtedly, but radv does get bullied by nvidia a bit for not testing with it at all (because none of us can read or even compile it)
<BtbN>
Why _is_ HEVCVPS 7mb?
<BtbN>
I see nothing in there that'd grow it to THAT size
<Lynne>
statically allocated at all their maximum sizes and number of units, the total size is around 120 megs
<Lynne>
that's why vulkan allocates the structs
<BtbN>
But what in HEVCVPS specifically is 7mb?
<BtbN>
it just doesn't look that big
<Lynne>
HEVC_MAX_LAYER_SETS = 1024
<BtbN>
oh, that one variable
<BtbN>
There got to be a better way to handle that
<Lynne>
you copy alloc_hevc_header_structs() from vulkan
s55 has quit [Ping timeout: 252 seconds]
s55 has joined #ffmpeg-devel
Livio has joined #ffmpeg-devel
s55 has quit [Ping timeout: 264 seconds]
s55 has joined #ffmpeg-devel
cone-980 has quit [Quit: transmission timeout]
s55 has quit [Ping timeout: 264 seconds]
<BtbN>
wbs: it really seems like I snatched the only (used) devkit that was available worldwide. Let's hope shipping works
<jamrial>
BtbN, Lynne, michaelni: sent a patch for sizeof(HEVCVPS) just now
<jamrial>
Lynne: also sent a fix to properly set some fields, as vulkan expects them
<BtbN>
What's the new sizeof()? Saving a few byte in something that's in a 1024 element array is quite a bit already
<jamrial>
i replaced those 1024 copies of the same struct with 1024 pointers
s55 has joined #ffmpeg-devel
<jamrial>
so it should be much, much smaller
<BtbN>
hm, then I'm not looking at the right patch