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
lemourin7 has joined #ffmpeg-devel
lemourin is now known as Guest306
Guest306 has quit [Killed (copper.libera.chat (Nickname regained by services))]
lemourin7 is now known as lemourin
IndecisiveTurtle has quit [Ping timeout: 276 seconds]
System_Error has quit [Remote host closed the connection]
System_Error has joined #ffmpeg-devel
cone-245 has quit [Quit: transmission timeout]
marth64_ has joined #ffmpeg-devel
Marth64[m] has quit [Ping timeout: 248 seconds]
mkver has quit [Ping timeout: 265 seconds]
jamrial has quit []
Martchus_ has joined #ffmpeg-devel
Anthony_ZO has joined #ffmpeg-devel
Martchus has quit [Ping timeout: 260 seconds]
zsoltiv has quit [Ping timeout: 260 seconds]
zsoltiv_ has quit [Ping timeout: 260 seconds]
<fflogger>
[editedticket] nyanmisaka: Ticket #11618 ([ffmpeg] hwupload filter fails with "Cannot allocate memory" for VA-API on AMD RX 7900 XT (Navi 31) preventing H.264/HEVC hardware encoding initialization.) updated https://trac.ffmpeg.org/ticket/11618#comment:1
Anthony_ZO1 has joined #ffmpeg-devel
Anthony_ZO has quit [Quit: Anthony_ZO]
Anthony_ZO1 is now known as Anthony_ZO
System_Error has quit [Remote host closed the connection]
System_Error has joined #ffmpeg-devel
zsoltiv_ has joined #ffmpeg-devel
zsoltiv has joined #ffmpeg-devel
Arcitec has quit [Remote host closed the connection]
zsoltiv has quit [Read error: Connection reset by peer]
lemourin has quit [Read error: Connection reset by peer]
omegatron has joined #ffmpeg-devel
akol23 has quit [Quit: Konversation terminated!]
lemourin has joined #ffmpeg-devel
lemourin has joined #ffmpeg-devel
lemourin is now known as Guest4823
Guest4823 has quit [Ping timeout: 248 seconds]
Anthony_ZO has quit [Ping timeout: 252 seconds]
lemourin has joined #ffmpeg-devel
lemourin is now known as Guest2280
Guest2280 has quit [Ping timeout: 248 seconds]
lemourin has quit [Ping timeout: 248 seconds]
lemourin has joined #ffmpeg-devel
lemourin has quit [Ping timeout: 245 seconds]
lemourin has joined #ffmpeg-devel
kode544 has joined #ffmpeg-devel
kode54 has quit [Ping timeout: 248 seconds]
kode544 is now known as kode54
lemourin has quit [Ping timeout: 268 seconds]
lemourin has joined #ffmpeg-devel
dbonatto has joined #ffmpeg-devel
<dbonatto>
Hi all
<dbonatto>
I’m interested to know if there are companies that contribute to the development of ffmpeg
<dbonatto>
I’m looking to start a kind of new extension for ffmpeg, and I’m interested in companies that are would be willing to participate
<another|>
what kind of extension?
lemourin has quit [Ping timeout: 244 seconds]
<dbonatto>
I can't say much in public, but let's say I have at my disposal knowledge of new codecs that are not yet public available and I’m in contact with people that want to make them more available
<nevcairiel>
You know its open source right? Secrets dont exactly keep being secret once the code is here
<dbonatto>
yes, it will be open source
dbonatto has quit [Quit: Client closed]
<kierank>
lol
<kierank>
I'm 95% sure what this is
dbonatto has joined #ffmpeg-devel
<dbonatto>
oups, my connection was reset, did I miss something ?
<dbonatto>
So, I was saying, yes, the final codecs will be public and opensource, probably BSD, they are still in development at the moment, but we are interested in making them available to the community
<dbonatto>
The companies that are interested will receive fundings for the development
<kierank>
what kind of codecs
<dbonatto>
again, I can't say much, but it will include new kinds of (video) media encoding and decoding and streaming
mkver has joined #ffmpeg-devel
<kierank>
a new codec that doesn't exist in the world at all?
<dbonatto>
yes
lemourin has joined #ffmpeg-devel
<kierank>
or just one that is available in a proprietary implementation
<dbonatto>
new codec, not available to public yet, it will probably contain IP protected parts (yet to be defined), but overall the objective is to make it more available
<kierank>
very strange
<kierank>
ffmpeg will almost certainly not accept a binary blob if that's what you are suggesting
<dbonatto>
no, no, code available and open-source
<kierank>
"it will probably contain IP protected parts"
<dbonatto>
the code will not be protected, but some algorithms may be subject to some IP
<kierank>
ah
<kierank>
interesting approach
<another|>
>inb4 AI video codec
lemourin has quit [Ping timeout: 244 seconds]
<dbonatto>
it is my understanding that ffmpeg already use this approach, x265 for example contains many many IP (enforced by the commercial license) but it is still open-source
<kierank>
x265 is dual licensed
<kierank>
so you can pay to use it in proprietary projects
<kierank>
that's orthogonal to any "IP"
<dbonatto>
the dual license is there to pay companies for their IP if used commercially
<kierank>
if you want to do BSD then that provision won't be there
<kierank>
the commercial licence is there in x265 to have a licence that is not GPL
kode547 has joined #ffmpeg-devel
<dbonatto>
honestly, the final license is not defined yet, at the moment we are looking for partners that are interested in participating, and the license will be decided depending on the partners and the funding agency
<kierank>
it's an interesting approach you are taking
<frankplow>
Are you talking about an encoder, decoder or both here? What does "new kinds of (video) media ... streaming" mean -- this is not just a codec you are talking about, but also systems/HLS stuff?
kode54 has quit [Ping timeout: 244 seconds]
kode547 is now known as kode54
<frankplow>
If it is to be available generally under the terms of the BSD license then it can't go in the FFmpeg repo and would have to be included as a library as I understand it (like dav1d)
<BBB>
maybe he's intending to make the decoder freely available under a permissive license, but have people pay for the encoder? the adobe flash model
<dbonatto>
encoder and decoder, I’m not expert in streaming, but yes, kind of HLS also
<dbonatto>
the project as it is currently defined includes the encoder and decoder
<wbs>
frankplow: individual files can have other licenses; if they're less permissive than lgpl they need extra opt-in like --enable-gpl
<kierank>
dbonatto: hls in this example is "high level syntax"
<dbonatto>
oh
<frankplow>
wbs: Ah I thought I read/heard in a talk somewhere that some license issue was the motivation for dav1d not to live under the FFmpeg project. I can see there are a few reasons one might want to do that though
<BBB>
it wasn't an "issue"
<BBB>
it was just a desire by some parties to have it be more liberal than lgpl (bsd) so it could be used in ways the lgpl does not allow
<BBB>
I agree that if you're going to make this new project bsd, it should presumably be a separate project
<BBB>
(because drive-by-patches would presumably be under lgpl, not bsd)
<dbonatto>
thanks for the advices
<wbs>
BBB: if the file in ffmpeg is marked as e.g. BSD, any drive-by patch to that would also implicitly be BSD licensed - that bit is not an issue. but if you want it to be usable on its own as BSD, just like dav1d, then it's best not to build it inside libavcodec yeah
cone-813 has joined #ffmpeg-devel
<cone-813>
ffmpeg Andreas Rheinhardt master:fa45e2002976: tests/fate/mov: Fix fate-mov-mp4-frag-flush requirements
<cone-813>
ffmpeg Andreas Rheinhardt master:9416ffd8b879: avcodec/ac3dec: Hardcode tables to save space
<cone-813>
ffmpeg Andreas Rheinhardt master:11723b3526e0: avcodec/ac3: Move gain value defines to ac3defs.h
<cone-813>
ffmpeg Andreas Rheinhardt master:20caa5cf2d91: avcodec/ac3dec: Deduplicate mantissas and their init code
<cone-813>
ffmpeg Andreas Rheinhardt master:dbd2ca3580fa: avcodec/ac3{dec,enc}: Deduplicate gain levels table
<cone-813>
ffmpeg Andreas Rheinhardt master:2d5f5e8726b7: avcodec/ac3dec: Deduplicate tables
<cone-813>
ffmpeg Andreas Rheinhardt master:6d45668801db: avcodec/hpeldsp: Remove duplicate pel functions
<cone-813>
ffmpeg Andreas Rheinhardt master:83b346914297: avcodec/x86/hpeldsp_init: Use ff_avg_pixels16_mmxext
<cone-813>
ffmpeg Andreas Rheinhardt master:09aeeeb66323: avcodec/hpeldsp_init: Detemplatize
<cone-813>
ffmpeg Andreas Rheinhardt master:93e53e253a5b: avcodec/vc1dsp: Fix vc1op_pixels_func semantics
<dbonatto>
ok thanks, I need to check which license is available with the funding, I have no strong opinions on the matter, I’m just looking for possible partners
<dbonatto>
and the best way to make the project available to the community
<kierank>
it's a bit chicken and egg, if you want companies to fund it, you have to say what it is
<BBB>
wbs: makes sense, alright
<BBB>
dbonatto: kierank is right that without knowing what it is, it'll be difficult to find partners. a potential counterparty will need to know what skills you're looking for / are necessary before engaging. this means knowing what the project consists of.
kode54 has quit [Ping timeout: 245 seconds]
<BBB>
and then secondly, irc might not be the most efficient method to engage with a wide variety of counterparties. if you want a wider audience, maybe mailinglist is better?
<dbonatto>
you are right, I’m looking for partner companies to help in the development and that are willing to apply with us for funds, and trying to understand the ffmpeg model and if something is possible.
<dbonatto>
thanks, I didn't know what was the best channel to contact the ffmpeg team, I figured that the dev channel allows me to meet the companies directly
<dbonatto>
but, yeah, I will probably send a message in the mailing list after agreement by all partners
<BBB>
companies?
<dbonatto>
companies that are currently working on ffmpeg code
<haasn>
Lynne: vkCopyMemoryToImage is a massive fps gain, while vkCopyImageToMemory seems to slow things down dramatically, even if I first check if the image is in-use and only emit the host copy if the image is idle
<haasn>
not sure how to feel about that
Traneptora has joined #ffmpeg-devel
heit0r has joined #ffmpeg-devel
lemourin has quit [Client Quit]
<BtbN>
Does Vulkan have no concept of unified memory?
<BtbN>
Or is the format too different to just have a frame with standard pixel data it in be in UVM and shared directly, like with CUDA?
lemourin has joined #ffmpeg-devel
<haasn>
Lynne: also, I need to enable hostImageCopy featur during lavu device creation, but validation layers complain that I am attaching both the Vulkan14Features struct and the ShaderSubgroupRotateFeatures struct
<haasn>
do you have any precedent for how to handle this scenario properly?
lemourin has joined #ffmpeg-devel
lemourin is now known as Guest8893
Guest8893 has quit [Ping timeout: 276 seconds]
Traneptora has quit [Quit: Quit]
odrling has quit [Remote host closed the connection]
odrling has joined #ffmpeg-devel
Traneptora has joined #ffmpeg-devel
heit0r has quit [Quit: heit0r]
Teukka has quit [Quit: Not to know is bad; not to wish to know is worse. -- African Proverb]
<ramiro>
mkver: nice patchset! what are the issues with configure regarding zlib? isn't it just a matter of adding more hostcc test functions?
<mkver>
ramiro: Would we not also need a way to check the host's pkg-config for the zlib linker flags?
<ramiro>
mkver: yes. that could be a bit tricky. especially wrt env vars, such as PKG_CONFIG_PATH.
<courmisch>
mkver: SIGBUS usually means alignment error. Are you sure that checkasm checks thorouughly enough?
<mkver>
IIRC it uses a constant misalignment of 1.
<courmisch>
well if it's RVV-only it's probably my bug
<ramiro>
mkver: one idea is to add --host-pkg-config{,-flags} options, along with HOST_ pkg-config env vars. we would override the pkg-config env vars to the HOST_ versions in test_host_pkg_config if they exist (or unset the env vars if the HOST_ versions don't exist). hopefully if that tails, a fallback to check_host_lib -lz works. if none of that works, we print a warning and disable compression.
<ramiro>
that *does* sound convoluted and error-prone though :/. also not very standard.
<courmisch>
[5626548.576033] enc0:0:asv1[1424371]: unhandled signal 7 code 0x1 at 0x0000002adceb0b28 in ffmpeg[2adc59e000+1391000]
<courmisch>
now what is code 1
<courmisch>
and it does not reproduce under QEMU, sigh
<ramiro>
mkver: another option is to keep using gzip, but pipe the ouptut to bin2c to avoid the intermediate file.
omegatron has quit [Quit: Power is a curious thing. It can be contained, hidden, locked away, and yet it always breaks free.]
ngaullier has quit [Remote host closed the connection]
<Lynne>
haasn: I've sent the patch to use host image copy on the hwcontext_vulkan side
<Lynne>
why do you use version1.4 structs? you only need the EXT-one
<haasn>
in libplacebo I use the version 1.4 structs iff the vulkan version is above 1.4
<haasn>
and otherwise use the EXT structs
<Lynne>
oh? ah, I remember
<Lynne>
the ifdeffery shouldn't be too heavy
<haasn>
since iirc you're not allowed to use the extension structs for promoted extensions
<haasn>
or something dumb like that
<Lynne>
yeah, I've brought that up
<haasn>
it's not something you can decide at build time
<Lynne>
err? really?
<Lynne>
if the headers support 1.4, its safe to assume the drivers support 1.4 structs
<haasn>
what nonsense, I can compile ffmpeg against vulkan 1.4 headers and point it at a vulkan 1.1 driver
<Lynne>
(they told me 'wontfix', sadly)
<Lynne>
how do you even detect the max version the driver supports?
<haasn>
VkPhysicalDeviceProperties.apiVersion
<haasn>
and vkEnumerateInstanceVersion for the loader
<haasn>
which, I may add, is also allowed to be older than the headers
<haasn>
(try deploying your app on Android, for example)
<Lynne>
ah, I didn't know that
<Lynne>
its a fairly new feature, so I think you should be fine to requre 1.4 for it
<Lynne>
it only makes sense on nvidia, which have had 1.4 for almost a year now, I think?
<haasn>
llvmpipe also has it, technically
<haasn>
anyway, that's besides the point
<haasn>
even if we require vulkan 1.4, we then need to request vulkan 1.4-promoted features differently
<haasn>
so in your feature checks you need to account for the possibility of both
<haasn>
maybe you can steal the libplacebo code for this
<haasn>
I have a function to "normalize" a features struct chain based on the active vulkan API version
<haasn>
either converting all to VulkanXYFeatures or all to separate extensions, depending on the vulkan version
<haasn>
also wow how did I miss vkTransitionImageLayout
<Lynne>
yeah, I meant for now, requiring 1.4 for the only extension which has this issue and not having a backup
<Lynne>
I hope image layouts will go poof in the near future
<Lynne>
like, sooner than you may think
<Lynne>
well, not poof, but you just pick general and never worry about it
<Lynne>
for 2d anyway, for 3d multisample-based stuff and compressed (s3tc et al), it's still needed IIRC since RADV does some copies in that case
<haasn>
I kinda wish they would have instead added vkCmdCopyImageToMemory and vice versa
<haasn>
to still allow executing it asynchronously on the dma engine
<Lynne>
the thing is that GPUs themselves have no idea what sort of permute is happening, they only know how to manipulate images in a certain permutation order
<Lynne>
so this is basically just doing the tiling/compression on the CPU-side by the driver, as I understand it
wellsakus has joined #ffmpeg-devel
IndecisiveTurtle has joined #ffmpeg-devel
System_Error has quit [Remote host closed the connection]
System_Error has joined #ffmpeg-devel
Everything has joined #ffmpeg-devel
<courmisch>
mkver: https://pastebin.com/cVuLxhyr it's expected 64-bit alignment, which it gets, but the stride is 22 bytes
<courmisch>
expecting*
<courmisch>
mkver: IMO avsenc.c should use get_pixels_unaligned rather than get_pixels if the stride is not a multiple of ? 16?
<mkver>
But that is what it does since 75960ac2708659344bc33b4c108e4a49a0d3184e.
<mkver>
8 should be enough; given that the blocks have a width of eight bytes, you can never guarantee 16B alignment.
System_Error has quit [Remote host closed the connection]
System_Error has joined #ffmpeg-devel
<courmisch>
mkver: the code would work if the stride was a multiple of 8 bytes, but 22 is not a multiple of 8
<mkver>
But the code should already use get_pixels_unaligned in this case.
<mkver>
Why doesn't it do so?
minimal has joined #ffmpeg-devel
<courmisch>
mkver: the code assumes that the stride is a multiple of 8 even if the pointers are unaligned, which was ostensibly true until recently?
<mkver>
No, it checks the stride. See 75960ac2708659344bc33b4c108e4a49a0d3184e
<courmisch>
I mean the asm
<mkver>
The aligned get_pixels function should not be called when the stride is not a multiple of eight.
<courmisch>
mkver: point is that, until recently, we were never calling the unaligned function with unaligned *strides* only unaligned base addresses
<courmisch>
I don't know if it was just poor FATE coverage, or it is a real recent change, but that's why the crash comes up only now
<mkver>
Your https://pastebin.com/cVuLxhyr shows that the crash happens in the aligned function, not the unaligned one.
pal has joined #ffmpeg-devel
<pal>
j2k
<courmisch>
because of shared code in the assembler
<courmisch>
the unaligned code has the same assumption anyway
<mkver>
And this aligned function should not be used in this case at all. Which is what surprises me.
<mkver>
What shared code in the assembler?
<courmisch>
the assembler just reads two aligned blocks covering the unaligned block
<courmisch>
so if the block is in fact aligned (by base address), then the code is the same
<courmisch>
just feed an unaligned base address and you'll get the same crash but with the less confusing stack frame
<mkver>
I still don't get why your stack trace shows that the aligned function was used. Does the unaligned function call the aligned one?
<courmisch>
if the base is aligned it has to
<courmisch>
otherwise we'd be doing out of bound reads
<courmisch>
but again, that's not the issue. The issue is that the code assumes the stride is a multiple of 64-bit, which seemed to have held true until recently
<courmisch>
s/seemed/seems/
<courmisch>
s/64-bit/64 bits/
<mkver>
The documentation for PixBlockDSPContext does not mention any alignment requirement for stride; it is clear that stride is supposed to be a multiple of eight for the aligned case, but I don't see why the unaligned case could make any presumption whatsoever.
<mkver>
(Anyway, the documentation of AVFrame.linesize actually requires alignment (so sending such a frame to lavc is actually an API violation), but other parts of the code create such frames.)
<mkver>
Where exactly does ff_get_pixels_unaligned_8_rvv call ff_get_pixels_8_rvv?
<courmisch>
line 40, but removing it will make things even worse
<Lynne>
bcheng: if it's a 502, its just the server being overloaded
<courmisch>
but there you have it, checkasm does not test unaligned strides
Warcop has quit [Remote host closed the connection]
<bcheng>
Lynne: oh, ok... should I switch to the github mirror?
Everything has quit [Quit: leaving]
kode54 has joined #ffmpeg-devel
halloy5771 has joined #ffmpeg-devel
<fflogger>
[editedticket] Noki0100: Ticket #11618 ([ffmpeg] hwupload filter fails with "Cannot allocate memory" for VA-API on AMD RX 7900 XT (Navi 31) preventing H.264/HEVC hardware encoding initialization.) updated https://trac.ffmpeg.org/ticket/11618#comment:2