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
thilo has quit [Ping timeout: 244 seconds]
thilo has joined #ffmpeg-devel
thilo has quit [Changing host]
thilo has joined #ffmpeg-devel
minimal has quit [Quit: Leaving]
<Lynne>
expired domains get pruned from search engines too, even though search engines themselves keep backups
<Lynne>
I'm sure its probably some scraping/bandwidth issue
<cone-764>
ffmpeg Lynne master:ec3f3457fdfd: vulkan_decode: add STORAGE flag to output images
j45_ has joined #ffmpeg-devel
j45 has quit [Ping timeout: 276 seconds]
j45_ is now known as j45
j45 has quit [Changing host]
j45 has joined #ffmpeg-devel
averne_ has joined #ffmpeg-devel
averne has quit [Ping timeout: 252 seconds]
averne has joined #ffmpeg-devel
averne_ has quit [Ping timeout: 252 seconds]
<ramiro>
haasn: thanks for swscale5_shuffle branch, I'll look at it in a couple of weeks.
<ramiro>
I also noticed that rgba -> rgb0 could be improved by a better packed shuffle solver
<ramiro>
you _could_ submit it to the ML again, but you could also tackle subsampled formats first, since you will inevitably have to do it very soon :)
<fflogger>
[editedticket] MasterQuestionable: Ticket #11542 ([ffmpeg] gdigrab sometimes fails to capture specific windows on some machines) updated https://trac.ffmpeg.org/ticket/11542#comment:17
mkver has quit [Ping timeout: 276 seconds]
derpydoo has quit [Quit: derpydoo]
mkver has joined #ffmpeg-devel
kode540 has joined #ffmpeg-devel
kode54 has quit [Ping timeout: 244 seconds]
kode540 is now known as kode54
witchymary has quit [Ping timeout: 252 seconds]
cone-764 has quit [Quit: transmission timeout]
Anthony_ZO has quit [Remote host closed the connection]
ubitux has joined #ffmpeg-devel
HarshK23 has quit [Quit: Connection closed for inactivity]
jamrial has joined #ffmpeg-devel
microlappy has joined #ffmpeg-devel
microlappy has quit [Quit: Konversation terminated!]
<cone-987>
ffmpeg softworkz master:5fc424c27cde: ffmpeg/repo: Add dot-folders in the repository root to .gitignore
ahmedhamed has quit [Quit: Connection closed for inactivity]
elvis_a_presley has quit [Quit: smoke-bomb ; grapple-hook]
elvis_a_presley has joined #ffmpeg-devel
lexano has quit [Remote host closed the connection]
lexano has joined #ffmpeg-devel
<llyyr>
why is the commit message scuffed
minimal has joined #ffmpeg-devel
<jkqxz>
If you have a 4:2:2 JPEG (therefore centre chroma sampling), is it possible to represent that in normal video codecs like H.264/AV1 or is it mandatory to rescale that when transcoding?
<cone-987>
ffmpeg Lynne master:7cd1edeaa410: vulkan: drop bgr_workaround
<Lynne>
jkqxz: both have chroma alignment fields
<Lynne>
h273
<jkqxz>
Only talks about 4:2:0.
<jkqxz>
H.265 seems to say that 4:2:2 must be collocated.
<jkqxz>
AV1 is vague, but doesn't let you signal anything for 4:2:2 anyway.
<another|>
wdym? 4:2:2 is supported in the "Professional" profile
<jkqxz>
So where are the chroma samples relative to the luma when coding 4:2:2 in AV1?
microlappy has joined #ffmpeg-devel
<another|>
that I do not know
microlappy has quit [Client Quit]
<Lynne>
probably the default
<jkqxz>
And what is "the default"? Same as JPEG, same as H.265, something else?
<Lynne>
"external"... oh, well
<Lynne>
it's just what libaom assumes the default is that is the default, then
<jkqxz>
Does libaom even care? I would have thought it just passes the pixels through without thinking about the meaning.
<Lynne>
doesn't look like it
<Lynne>
when in doubt, just assume h264 default chroma then
termos has joined #ffmpeg-devel
cone-987 has quit [Quit: transmission timeout]
<linkmauve>
Lynne, according to the documentation, after having been submitted to a queue, a VkCommandBuffer that began as a ONE_TIME_SUBMIT ends up in the invalid state, and must be reset before being begin again.
<linkmauve>
I’ve tried to implement that state machine, but ffmpeg never resets the command buffer in-between uses.
<linkmauve>
I’m surprised other vulkan video drivers don’t care about that.
<linkmauve>
I still have some state issues even if I vk->ResetCommandBuffer() after vk->QueueSubmit2() so I’ll hold on submitting a patch just now.
HideoSugai has joined #ffmpeg-devel
iive has joined #ffmpeg-devel
Grimmauld has quit [Quit: Client closed]
<mkver>
jkqxz: What is the longest APV VLC entry?
<jkqxz>
~30 bits. The large entries are rare, though - most things hit in the moderately-sized table.
realies has quit [Quit: ~]
<mkver>
Did you try to use a standard VLC?
<kurosu>
The chroma location could matter for some AV1/2 tools. But I remember more shenanigans for 4:2:0 (nominal vs what's used for BT2020/UHD blu-ray) than 4:2:2
<jkqxz>
mkver: I did not. I was playing with directly constructing different forms of it and didn't really think about fitting them into the existing VLC functions.
<jkqxz>
jamrial: What is the benefit of putting constant tables in rodata over text there? Having them next to the function in text means that simple PC-relative loads always work regardless of the code model.
realies has joined #ffmpeg-devel
<jamrial>
jkqxz: it's just following existing conventions. it's probably not important if you think it's ok as is
<jkqxz>
Is there a name which gives me the register which is probably [er]ax unless there is something weird going on?
<jkqxz>
I was using rax/int64_t in that code to try to avoid having to think about ABI issues like bad top-halves in registers, but maybe I am missing some case.
<jamrial>
just use the d suffix for that
<jamrial>
qp_shiftd, bit_depthd, will make sure to ignore (and overwrite) the upper 32 bits of the respective registers
<jkqxz>
I mean a different register which isn't a named argument.
<jamrial>
you can give a name to a register that's not an argument
<jamrial>
or use the next free r$ alias
<jamrial>
so after qp_shift you have r6
<jkqxz>
What is "the next free r$ alias"?
<jamrial>
r0, r1, r2, ..., r15
<jkqxz>
Oh, r6 is magically the next register I haven't used?
<jkqxz>
I did not realise that.
<jamrial>
yes, those are aliases x86inc gives to all available registers, regardless of what you define in cglobal
<jkqxz>
(I feel the documentation of x86inc.asm could be improved.)
<jamrial>
but if you use them, you need to declare them as used in the third cglobal argument
<jamrial>
so "cglobal apv_decode_transquant, 6, 7, 16"
<jkqxz>
For your later comment, is there a reason not to put the 'v'? Given that I know everything must be VEX it feels cleaner to just write it in all cases rather than spending any time at all considering whether things might be able to not have a 'v'.
___nick___ has joined #ffmpeg-devel
<jamrial>
in this specific function there's no real need other than saving writing the three-operand form where dst == src1, but in functions using x86util macros it's needed because SWAP may have been used
<jamrial>
or maybe that only mattered if you use the canonical names xmm, ymm, etc instead of the x86inc m, xm, ym, zm macros. i don't recall
<jkqxz>
I am missing why SWAP could matter.
<jamrial>
SWAP changes simd register aliases
<jkqxz>
Ok, yes, SWAP will go horribly wrong if you use real names.
<jkqxz>
But I don't see how that could ever work here?
<jamrial>
yeah, it probably doesn't matter
<jkqxz>
Hmm. If I remove the use of rax and change int64_t/movq to int32_t/movd this probably works on x86-32. Does anyone actually care about that any more?
<jamrial>
you still need to reduce usage of simd registers to 8, so no, it will not work without extra considerations :p
<jkqxz>
Oh, ouch. I think that's pretty doomed then - spilling some of the 8x8 32-bit intermediates would be a big pain.
___nick___ has quit [Remote host closed the connection]
<kurosu>
Yes, x86_32 is in legacy mode in a lot of places besides ffmpeg