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: 264 seconds]
paulk has quit [Read error: Connection reset by peer]
paulk has joined #ffmpeg-devel
paulk has joined #ffmpeg-devel
paulk has quit [Changing host]
epony has joined #ffmpeg-devel
rvalue has joined #ffmpeg-devel
navi has quit [Quit: WeeChat 4.1.2]
mkver has quit [Ping timeout: 272 seconds]
uau_ has joined #ffmpeg-devel
uau has quit [Ping timeout: 256 seconds]
<kasper93>
>Move to Gitlab
<kasper93>
no way, is ffmpeg entering current century?
<kierank>
lol
dellas has quit [Remote host closed the connection]
jarthur has quit [Quit: jarthur]
thilo has quit [Ping timeout: 272 seconds]
thilo has joined #ffmpeg-devel
lexano has quit [Ping timeout: 272 seconds]
user1453 has quit [Ping timeout: 272 seconds]
<Lynne>
all this talk about money before or after merging, but there's one thing no one's mentioned yet
<Lynne>
what if the reviewer wants a cut for this?
<Lynne>
"I'm not paid to review your code, I can't give you a good explanation right now, the whole design is wrong, <vague directions>, but if you give me 20% I'll work with you."
<Lynne>
I'd like to say that we're too civilized for this, but I'm not sure I would totally put this past ourselves, especially with the last part removed and the former just being an invitation to haggle over the percentage over PM
cone-731 has quit [Quit: transmission timeout]
lemourin has quit [Read error: Connection reset by peer]
lemourin has joined #ffmpeg-devel
qeed has joined #ffmpeg-devel
jamrial has quit []
rajiv_ has joined #ffmpeg-devel
epony has quit [Read error: Connection reset by peer]
zsoltiv__ has joined #ffmpeg-devel
zsoltiv_ has quit [Ping timeout: 255 seconds]
derpydoo has quit [Ping timeout: 246 seconds]
Martchus_ has joined #ffmpeg-devel
AbleBacon has quit [Read error: Connection reset by peer]
Martchus has quit [Ping timeout: 256 seconds]
<Lynne>
jkqxz: updated the vulkan patch for v2
<Traneptora>
kasper93: many of us oppose gitlab because of a metric ton of JS that comes with it
<Traneptora>
we prefer mail servers written by perl scripts that larry wall wrote in 1988
<Lynne>
hate to say it, but this century is almost a quarter done with
coala has joined #ffmpeg-devel
gnafu has quit [Quit: Rebooting for kernel update...]
gnafu has joined #ffmpeg-devel
haihao has quit [Ping timeout: 260 seconds]
haihao has joined #ffmpeg-devel
<Traneptora>
I personally would like some sort of UI that makes PRs easier than the current ML system
<Traneptora>
but there isn't really any consensus among devs on that
qeed has quit [Quit: Leaving]
quietvoid has quit [Ping timeout: 268 seconds]
quietvoid has joined #ffmpeg-devel
rajiv_ is now known as rajivharlalka
thilo has quit [Ping timeout: 256 seconds]
thilo has joined #ffmpeg-devel
thilo has joined #ffmpeg-devel
thilo has quit [Changing host]
epony has joined #ffmpeg-devel
Krowl has joined #ffmpeg-devel
Wenbin_Chen_ has quit [Quit: Wenbin_Chen_]
<frankplow>
Traneptora: I believe the consensus is that moving to GitLab will only happen if it’s possible to open and review PRs from the terminal or at least a mail client.
epony has quit [Remote host closed the connection]
<frankplow>
Traneptora: So the metric ton of JS can be avoided if you are concerned about it.
mkver has joined #ffmpeg-devel
HarshK23 has joined #ffmpeg-devel
<JEEB>
yea elenril was requested to check out the current iteration of gitlab cli
epony has joined #ffmpeg-devel
Krowl has quit [Read error: Connection reset by peer]
coala has left #ffmpeg-devel [WeeChat 4.1.3]
tufei_ has quit [Ping timeout: 255 seconds]
cone-580 has joined #ffmpeg-devel
<cone-580>
ffmpeg Andreas Rheinhardt master:76ef2b9337cf: avformat/avformat: Remove obsolete comment
<cone-580>
ffmpeg Andreas Rheinhardt master:569ad285a5c2: avformat/options: Only allocate AVCodecContext for demuxers
<cone-580>
ffmpeg Andreas Rheinhardt master:ad9f644505bd: avformat/avformat: Avoid av_strdup(NULL)
<cone-580>
ffmpeg Andreas Rheinhardt master:1d5ba34249e2: avformat/avformat: Remove dead check, write-only assignment
<cone-580>
ffmpeg Andreas Rheinhardt master:9b67c5a6841e: avfilter/ccfifo: Inline trivial functions
<cone-580>
ffmpeg Andreas Rheinhardt master:71e1da4522de: avformat/mux: Don't allocate priv_pts separately
<cone-580>
ffmpeg Andreas Rheinhardt master:1a52cbd40482: avfilter/ccfifo: Improve included headers
<cone-580>
ffmpeg Andreas Rheinhardt master:8b83b52d0fa5: avformat/nutenc: Fix indentation
<cone-580>
ffmpeg Andreas Rheinhardt master:ed56ca856c3b: avutil/opt: Fix AV_OPT_TYPE_CONST default value
<cone-580>
ffmpeg Andreas Rheinhardt master:e05d3c1a16c9: avdevice/caca: Allow to list multiple dither option types at once
ccawley2011 has joined #ffmpeg-devel
Krowl has joined #ffmpeg-devel
\\Mr_C\\ has joined #ffmpeg-devel
j45_ has joined #ffmpeg-devel
j45 has quit [Ping timeout: 260 seconds]
<haasn>
make fate-mov-write-amve # fails for me on git master
<haasn>
even after rsync
<haasn>
even on previously good commits
<haasn>
something broke about the test clips?
<nevcairiel>
fate boxes seem to be fine
<nevcairiel>
other then msvc bein broken due to some vvc dsp issues
<elenril>
no compiler I've tried on godbolt has a problem with anonymous unions
<elenril>
in c or c++
<nevcairiel>
most compilers probably supported it as extensions before it was standardized
<nevcairiel>
apparently gcc fails with -std=c99, but not with std=gnu99
<elenril>
yeah, some google results say it goes back to 80s or earlier
<haasn>
src/tests/fate-run.sh: line 271: test: -show_entries: binary operator expected
<haasn>
src/tests/fate-run.sh: line 89: /home/nand/dev/FFmpeg/build/ffprobe: No such file or directory
<haasn>
huh
<haasn>
the binary is named ffprobe_g
<elenril>
it should run the stripped builds without _g
<haasn>
which doesn't seem to exist
<elenril>
make ffprobe?
<haasn>
I am building with --disable-stripping
<elenril>
fun
<haasn>
what's strange though is that this used to work
<haasn>
works after rm -rf ./build
<haasn>
odd
j45 has joined #ffmpeg-devel
j45 has quit [Changing host]
j45 has joined #ffmpeg-devel
j45_ has quit [Ping timeout: 260 seconds]
mkver has quit [Ping timeout: 272 seconds]
mkver has joined #ffmpeg-devel
epony has quit [Remote host closed the connection]
navi has joined #ffmpeg-devel
epony has joined #ffmpeg-devel
<JEEB>
haasn: that sounds like some funky build root crapping out :D
uau_ is now known as uau
<JEEB>
michaelni: fun that sdl outdevice worked for you on windows. I tested during FOSDEM a yuv420p mp4 file with realtime decoding and it didn't even create a window
<JEEB>
argh, of course didn't mention the OS :) fedora linux
<haasn>
hmm
<haasn>
there is a fundamental problem in swfmt negotiation
<haasn>
vf_hwupload can do both sw->hw transfers and hw->hw transfers
<haasn>
for sw->hw transfer, the input fmt ref needs to be the same as the output swfmt ref
<haasn>
but for hw->hw transfer, the input swfmt ref needs to be the same as the output swfmt ref, with the input fmt including hwframe formats
<haasn>
it would be easier of hwupload and hwderive (or w/e) could be separate filters
<haasn>
oh, maybe we can settle if we're doing a sw->hw xfer or a hw->hw xfer at query_formats time
jamrial has joined #ffmpeg-devel
omegatron has joined #ffmpeg-devel
cone-580 has quit [Quit: transmission timeout]
<elenril>
>"mxf caused me to stop bathing"
<elenril>
-- seen on irc
<rodeo>
I've known of a developer who coded while bathing, maybe it was the same guy who stopped coding altogether because of mxf and the lack of bathing was merely a consequence of that
lexano has joined #ffmpeg-devel
<elenril>
it's so stupid how a non-existent variable expands to nothing rather than and empty string
<elenril>
(in sh)
Krowl has quit [Read error: Connection reset by peer]
<mkver>
elenril: If this is about my patch: The issue is actually that ffprobe_opts can contain more than one word.
<elenril>
ah
<kasper93>
Traneptora: I understand, but wouldn't you guys say ML is less powerful than tools that are designed to aid development?
<kasper93>
frankplow: btw, thanks for the fix, after recent change vvc doesn't crash on me.
<BtbN>
jamrial: did you see my second follow up mail yesterday? Patch looks good otherwise.
Marth64 has joined #ffmpeg-devel
<Marth64>
good day
<elenril>
it's a day alright
<frankplow>
kasper93: Good to hear :)
user1453 has joined #ffmpeg-devel
<Lynne>
as much as we keep stupid crap like self-modifying swscale code or capture code no one's ever used that is old enough to drink
<Lynne>
the kernel still keeps something even worse - x32 ABI
<Lynne>
you can't even use it with clang, only gcc supports that
<BBB>
it's relatively self-contained, it's not that big a deal. it's just quirky
<Gramner>
did anyone ever use x32 if you exclude the people who created it?
<Marth64>
burn all legacy code
<Marth64>
death to CrystalHD
<BBB>
I meant self-modifying sws code, not x32. x32 is pure evil and needs to die
<Gramner>
isn't sws just runtime-generated, not self-modifying?
cone-122 has joined #ffmpeg-devel
<cone-122>
ffmpeg Lynne master:bd3e71b21ec3: x86/tx_float: enable SIMD for sizes over 131072
<BBB>
it modifies a template :)
<Lynne>
Gramner: nope, no distribution ever picked it on and enabled it (obviously, no way they would package anything for it)
<Lynne>
the authors were **loud** though, and the last time they tried to remove it in 2019, they again extinguished the discussion
<BBB>
I don't think we ever accepted support for it, did we?
_whitelogger has joined #ffmpeg-devel
<Gramner>
I believe x32 "support" in most code bases where such things exist is some variant of "disable all optimizations on x32 because everything breaks otherwise"
<mkver>
jamrial: But improve the commit message.
<jamrial>
mkver: what do you want me to say?
<mkver>
That mixing an ownership-pointer with a pure data pointer is bad and leads to problems, like the problem you mentioned in the commit message of the first commit.
AbleBacon has joined #ffmpeg-devel
<cone-122>
ffmpeg James Almer master:7f92014acaad: avcodec/nvdec: don't free NVDECContext->bitstream
<cone-122>
ffmpeg James Almer release/6.1:bfacb66fc821: avcodec/nvdec: don't free NVDECContext->bitstream
<cone-122>
ffmpeg James Almer release/6.0:178575bdc151: avcodec/nvdec: don't free NVDECContext->bitstream
<cone-122>
ffmpeg James Almer release/5.1:c36c91900f93: avcodec/nvdec: don't free NVDECContext->bitstream
<mkver>
BtbN: Why do H.264 and HEVC actually copy the bitstream at all?
<BtbN>
That's something I wondered as well yesterday. I thought only AV1 did
<mkver>
Is it because of isobmff->annex b?
<BtbN>
it must be because there is a chance the bitstream for one frame is somehow split over multiple slices
<BtbN>
otherwise there'd be no reason to
<mkver>
If these slices come from the same packet, there should not be a reason for a copy in case the input is annex b.
<mkver>
Apart from the internal hwaccel API which strips the startcodes from the NALUs.
<cone-122>
ffmpeg James Almer release/5.0:4f9c230f42d9: avcodec/nvdec: don't free NVDECContext->bitstream
<cone-122>
ffmpeg James Almer release/4.4:9d4076c50498: avcodec/nvdec: don't free NVDECContext->bitstream
<jamrial>
Daemon404: where are the meeting notes?
<jamrial>
and i forgot what was decided. back to the old behavior?
<cone-122>
ffmpeg Wu Jianhua master:3372876888db: avcodec/x86/vvc/vvcdsp_init: fix unresolved external symbol on ARCH_X86_32
<Daemon404>
jamrial, an option/api to switch between which gets preference, but first elenril must add a list type
<jamrial>
avoption list type? nice
<Daemon404>
i dont think it is an avoption, at least iirc
<BBB>
Gramner: yes you're correct, it doesn't modify while running
<BBB>
Gramner: it's still a bit evil, if only for maintenance purposes... but it's also kinda fun
<BBB>
(it being the sws thingy here)
<elenril>
Daemon404: it is
<Daemon404>
elenril, o ok
Krowl has quit [Read error: Connection reset by peer]
elastic_dog has quit [Quit: elastic_dog]
elastic_dog has joined #ffmpeg-devel
<elenril>
jamrial: on that topic, I might need to add things to AVOption during major bump
<elenril>
please give me a couple days for it
<jamrial>
sure
<mkver>
elenril: Making AVOption even more bigger? You can't be serious.
<elenril>
it has a 4-byte hole on 64bit arches
dellas has quit [Ping timeout: 272 seconds]
<elenril>
besides that, consider the possibility that not everyone cares about binary size as much as you do
<mkver>
This is .data.rel.ro. It takes memory even when the only time it is accessed is at program startup.
<mkver>
(I hate this. Given that in lots of scenarios the dso of the object with the pointer is the dso providing the pointee, one could write the offset of the pointer to the pointee in this field (or 0 in case the pointer is NULL). This would avoid relocations. Of course, one would need to opt-in for this (by annotating the source code with a specific attribute that would need to be created).)
<elenril>
with an extra 64bit field at the end, libavcodec.so size goes up by 0.035%
<mkver>
And how much does .data.rel.ro go up?
dellas has joined #ffmpeg-devel
<elenril>
5%
<mkver>
Shocking!
<Lynne>
wars have been fought over less
<elenril>
[doubt]
Krowl has joined #ffmpeg-devel
<Traneptora>
<kasper93> Traneptora: I understand, but wouldn't you guys say ML is less powerful than tools that are designed to aid development
<Traneptora>
hey, I'm not an advocate for the ML system
<Traneptora>
I'm just describing the discussion
<elenril>
courmisch: pls don't feed the trolls
dellas has quit [Remote host closed the connection]
Krowl has quit [Read error: Connection reset by peer]
derpydoo has joined #ffmpeg-devel
<Marth64>
there is also
<Marth64>
Gitea
<Daemon404>
i vote to ditch git and use perforce
<jamrial>
mercurial
<Daemon404>
i also vote we move to c89
<Daemon404>
or maybe ANSI
<mkver>
K&R
<Marth64>
D:
<Marth64>
i like k&r but i've come to learn ff___ doesnt
<Marth64>
c is quite noisy so can't blame you
<Marth64>
in java only k&r works
<kasper93>
discord + rust + github, this is what cool kids use today D:
<Lynne>
gittea's still working on federation, which is neat, but still nowhere near complete
<Lynne>
it does however show just how fucked up gitlab is when generating web diffs
<Lynne>
I still don't get it, why does gitlab take ages to do anything when all the data is measured in kilobytes and is just text
<elenril>
mkver: i thought you like -fms-extensions best
<mkver>
That would be heaven.
<mkver>
Can we require it?
<elenril>
do you feel there's not enough drama on ml lately?
<llyyr>
I assume ffmpeg would be looking at Forgejo, rather than Gitea when evaluating it as an option
rvalue has quit [Ping timeout: 272 seconds]
<Daemon404>
elenril, youre saying we nee a sow for stf to require it then
* elenril
stabs Daemon404
<Lynne>
I'll only accept -fms-extensions if we get allow mixed declaration
<Daemon404>
rude
<elenril>
I'd rather switch to go than allow mixed declarations
rvalue has joined #ffmpeg-devel
<Daemon404>
i am still anti-mixe-decl
<Daemon404>
but i have 0 authority, s.
<Daemon404>
so*
<elenril>
Daemon404: quick, send 7 patches and you'll have 1 authority
<rodeo>
have you tried looking for authority? maybe you just haven't found it yet
<Daemon404>
how many likes and prayers is 1 authority worth
dellas has joined #ffmpeg-devel
<elenril>
wait, we only require 20 commits, not 30
<elenril>
you are in the GA
<elenril>
you do have 1 authority
<elenril>
lying to a member of CC should be a CoC violation
<Daemon404>
i am for now
<kierank>
TIL Forgejo
<mkver>
Lynne: You seem to believe there is a drawback to -fms-extensions (except for lack of support). What drawbacks do you have in mind?
<elenril>
mkver: is it specified anywhere what exactly does it imply?
<elenril>
one of my favorite things about C is how it has a usable spec
<mkver>
It implies that one can use tagged structs (and typedefs thereof) as unnamed members of other structs and access the members of the unnamed struct as if they were part of the enclosing struct.
<Lynne>
I don't have any objections to that, it would be neat to allow templating without macros
<Lynne>
but I would also like mixed declarations while we're at improving life
<elenril>
"let's also do x while at it" is one the best ways to never get anything done
<Lynne>
yeah, but you know, one thing leads to another, and then the kitchen sink gets thrown in
<JEEB>
do note that compilers don't catch all jumps over declarations. for whatever reason like two or so years ago there was a jump over a declaration in one of the files in mpv, and that didn't seem to cause a warning or error in the compilers utilized.
<llyyr>
kierank: if federation is important for ffmpeg then forgejo probably makes more sense (even notwithstanding the ownership drama of gitea), they're the ones working on it and there's also discussions of making forgejo a hard fork in which case the federation stuff probably won't make it back to gitea
<elenril>
the myth of consensual libavdevice
<Lynne>
(but seriously, you wouldn't need to use mixed declarations in your code, and I wouldn't use mixed declarations in my usual code, but for stuff like vulkan where you need 16 structs-in-structs and 10 function calls to get anything done)
<elenril>
that's what people always say
<elenril>
and then it starts getting used
<elenril>
and then a year later you get eaten by a grue
<elenril>
c.f. the sdl device
<elenril>
"it's just a cute useful hack it doesn't break anything"
<JEEB>
I don't always like starting a new context a few lines after the function starts due to having to check something and then you no longer are able to declare things, but eh ┐(´д｀)┌
<Lynne>
elenril: you might even like it in a year, who knows
<Traneptora>
this syntax doesn't work on MSVC fwiw
<Traneptora>
you can't do struct Foo bar = (struct Foo){.a = baz, .b = qux}; on MSVC
<Traneptora>
don't know if we care about that
<Lynne>
err, it should, on any msvc version we support
<Lynne>
that's standard c99
<nevcairiel>
it works fine in C mode, it just doesnt work in C++ mode, because C++ doesnt allow it
<nevcairiel>
so avoid such constructs in public headers
reynaldo has quit [Quit: Lost terminal]
<Lynne>
yeah, I was confused since we use that literally everywhere in our code
<Traneptora>
hm, how do we autodetect mjpeg?
<JEEB>
most likely probing
<Traneptora>
I have a jpeg file that's being autodetected erroneously as mjpets (score=47) when read from a pipe, but it's clearly a jpeg file
<Traneptora>
it starts with 0xFF D8 FF E0` and it's otherwise a compliant jpeg
<JEEB>
formats have probing functions and codecs also get their checks
<Traneptora>
I'm just wondering why that's not being detected as jpeg
<Traneptora>
it starts with ffd8 (SOI) and then ffe8 (app0), which itself starts with JFIF. this is an easy file to probe.
<Traneptora>
what I'm wondering is why the jpeg prober isn't being fired up or detecting the file as mjpeg
<courmisch>
elenril: but but
<nevcairiel>
mjpeg is the main jpeg codec, isnt it what its supposed to use to decode your image
<elenril>
courmisch: you meant to say you'd starve to death?
<courmisch>
elenril: I meant "mais euh" but I don't know the English equivalent
<kasper93>
Traneptora: I think you meant it is detected as "mpegts"
<Traneptora>
I did mean that, it's a typo
<kasper93>
just clearing it for nevcairiel
<Traneptora>
it looks like the problem is jpeg_probe (img2dec.c, line 754)
<courmisch>
elenril: care to explain which troll I alleged fed? surely you don't call honorable estimated ffmpeg-devel contributor a troll
<elenril>
courmisch: ng, obviously
<courmisch>
now that looks like a CoC violation to me
<Traneptora>
it looks like jpeg_probe scans the entire Probe Buffer for JPEG markers
<courmisch>
my integrity commands me to denounce you to the ffbi
<elenril>
courmisch: there's a dick joke in there somewhere
<Traneptora>
and jpeg_probe won't return a score better than AVPROBE_SCORE_EXTENSION unless it finds EOI
<Traneptora>
which seems incorrect, considering that EOI is at the very end of the file and very well may not occur inside the probe buffer
<courmisch>
I thought my mail was pretty funny, and if you don't like my humour, obviously you're in the one in the wrong
<elenril>
provoking the unnameable one just fans the flames of drama
<elenril>
much as I find it funny, we have enough drama as it is
<elenril>
so please don't
<courmisch>
I don't want to hear that from a CC that does not do its job, TBH.
<courmisch>
So I'm going to ignore you.
<elenril>
rude
<elenril>
the rudeness bordering on coc violation
<courmisch>
Yes, you are being rude
<elenril>
Traneptora: abi-break blockers should be reported to jamrial, since he's doing the bump
<Traneptora>
ye, he knows about it
<elenril>
cool then
<Traneptora>
I asked him about removing an avpriv and he was like "good timing"
<elenril>
i should probably look at your patches at some point in a not too distant future
<Traneptora>
the issue is the special-casing of the MakerNote, everything is done pmuch
wyatt8740 has joined #ffmpeg-devel
wyatt8750 has quit [Ping timeout: 255 seconds]
<Dmitri_Ovch>
hi. as far as I understand, we cannot use the dxva decoder output in any shader-based components?
<Dmitri_Ovch>
ddagrab, for example, sets the D3D11_BIND_SHADER_RESOURCE flag by default.
<Dmitri_Ovch>
Maybe it makes sense to add option for this to hwcontext_d3d11va or to the decoder itself?
<JEEB>
I think the API user is expected to add that flag in the hwcontext or so
<JEEB>
although I hear that in some cases the returned surfaces are still not usable, but I'm not sure of that
<BtbN>
ddagrab only sets that flag if it needs it
<BtbN>
i.e. when it needs to render the mouse cursor
<Dmitri_Ovch>
if it is just a component to the ffmpeg that accepts the decoder output, then the user of the ffmpeg itself cannot configure this flag in any way. also, the component itself cannot tell hwcontext_d3d11va to use this flag in any way
<Lynne>
are you trying to implement d3d11 filters?
<JEEB>
I tried to poke libplacebo with d3d11 frames and yea, the flags were the first thing I stumbled upon
<nevcairiel>
hwcontext just has a BindFlags field, its up to the user to set that accordingly, there is no set of flags you can set that pleases everyone by default - hence its up to the user to just set it
lns has quit [Quit: leaving]
<Dmitri_Ovch>
>>are you trying to implement d3d11 filters? yes
haihao has quit [Ping timeout: 240 seconds]
haihao has joined #ffmpeg-devel
<Dmitri_Ovch>
" user to set that accordingly" - this field can be set only at the moment of context initialization, then its value is no longer used to create frames
<Dmitri_Ovch>
I'm not suggesting changing the defaults, just adding the ability to set this flag, even if it is disabled by default
<Dmitri_Ovch>
"ddagrab only sets that flag if it needs it" - You're right, I wasn't paying attention.
<Lynne>
since we have no idea where the frames will go, maybe we should set the flag by default?
<Lynne>
we do that for pretty much every other hwcontext with both decode and filter support
<Dmitri_Ovch>
this would be useful, but I was afraid that it might affect some components that are already using the decoder output and may not be ready for this flag.
<Lynne>
is there something special that they have to do to accept it?
<Dmitri_Ovch>
As far as I know, no. I'm just a little afraid to change the defaults)
<JEEB>
I think the only note I recall regarding that flag was that some decoders would just not give out surfaces with it, but I've not tested things to verify or deny this claim
<jkqxz>
As I understand it, the thing the flag actually affects is the memory location and layout of the texture.
<Dmitri_Ovch>
at the moment, all dxva2 decoders produce frames without it
<jkqxz>
So the problem is that if you set it but didn't need to then you can end up in a case where the output ends up in a lowest-common-denominator configuration that is then much slower.
<jkqxz>
Or maybe it just doesn't work at all and the driver says no you can't do that in some cases.
<Dmitri_Ovch>
but if we make it possible to set it as an option, but not change the default, then there should be no problems.
<jkqxz>
The bigger problem from my point of view, however, is that I don't actually know about any real case this affects. Hence being very unwilling to change defaults which might break things horribly for someone in a completely opaque way that they will never be able to debug.
<Dmitri_Ovch>
yes, I agree with this. so I would like to suggest doing this as a configurable option.
<jkqxz>
So what would the option actually look like?
dellas has quit [Remote host closed the connection]
<Dmitri_Ovch>
I'm not sure about the name. but the behavior is this: if the option is set, it adds this flag when creating ID3D11Device_CreateTexture2D. if it is not exposed, then everything works as it is now.
<jkqxz>
What is it an option to? Decoders and/or filters?
<Dmitri_Ovch>
as far as I understand, there are 2 places where it can be placed:
<Dmitri_Ovch>
1) ff_dxva2_common_frame_params
<Dmitri_Ovch>
2) hwcontext_d3d11va.c
navi has quit [Quit: WeeChat 4.1.2]
navi has joined #ffmpeg-devel
<Dmitri_Ovch>
unfortunately, adding it from the filter will not lead to anything, since it is necessary during creation
navi has quit [Client Quit]
navi has joined #ffmpeg-devel
<jkqxz>
Creation of the frames, though?
<Dmitri_Ovch>
yes
<nevcairiel>
hwcontext_d3d11va already has an option to control the BindFlags
<jkqxz>
For cases where the frames are created in the decoder, an API user makes it work by setting the flag in the get_format callback.
<jkqxz>
For cases where the frames are created by a filter I think you're stuck, though.
<nevcairiel>
as an API user, you are probably best of to just make your own hwcontext
<nevcairiel>
framesctx i mean
<Dmitri_Ovch>
"hwcontext_d3d11va already has an option to control the BindFlags" - maybe I understand something wrong, but it looks like I can't influence this flag in any way from the filter, because at the moment when I set up the filter, the frames are already allocated.
<Dmitri_Ovch>
you mean the BindFlags field in AVD3D11VAFramesContext?
<jkqxz>
Correct, but an API user can set it correctly when they created the frames because they know what they are going to be used for.
<Dmitri_Ovch>
I'm not looking as user of api, but as user ffmpeg itself
<Dmitri_Ovch>
if my component can work both on shaders and without them. but it will be faster on shaders, then it would be convenient to be able to simply configure the command line, and not create a new application for this.
<Dmitri_Ovch>
and just being able to create components on shaders seems good to me.
<Dmitri_Ovch>
are there any problems that I'm missing if we add such an option to the dxva2 decoders?(without changing the default behavior)
<JEEB>
if the option is already there in the d3d11 hwctx, then it "just" needs to be integrated/exposed in ffmpeg cli if that is the issue
<Dmitri_Ovch>
Yes, there is such a property. if it is better to configure it specifically as a context property, then I will look in this direction. I thought that since the problem concerns the output of decoders, and they configure this field, then it is worth editing them.
<Lynne>
keep in mind users are allowed to give their own contexts for decoding
vjaquez has quit [Ping timeout: 252 seconds]
vjaquez has joined #ffmpeg-devel
user1453 has quit [Read error: Connection reset by peer]
<kierank>
Warning: the ECDSA host key for 'source.ffmpeg.org' differs from the key for the IP address '213.36.253.5'
<Lynne>
fine here? have you not pulled on that machine in a year or more?
<kierank>
Wed Nov 1 04:18:54 2023 last time I pulled
<Lynne>
maybe it was over ipv6?
<Daemon404>
source.ffmpeg.org is technically a mirror
<Daemon404>
and run by unknown bulgarians
dellas has joined #ffmpeg-devel
<kierank>
source.ffmpeg.org. 1794 IN CNAME git.videolan.org.
<kierank>
git.videolan.org. 294 IN A 213.36.253.5
<kierank>
;; ANSWER SECTION:
<kierank>
git.ffmpeg.org. 1800 IN A 79.124.17.100
<kierank>
git.ffmpeg.org is unknown bulgarians
<elenril>
iirc git.videolan.org had some key rotation or whatever recently
<elenril>
ask thresh
<elenril>
and complain loudly about lack of dnssec and sshfp
<elenril>
oh wait, there is sshfp
<elenril>
but it's of limited usefulness without dnssec
<kierank>
hmm do decoders actually support experimental
<kierank>
seems so
<Daemon404>
kierank, ah yah i had it backwards
<BtbN>
mkver: looking at the code, h264/5 for nvdec copy the whole buffer, for the sole reason that ffmpeg hwaccel infra provided the buffer without the 0x00,0x00,0x01 start code, and nvdec wants it.
<BtbN>
that's literally all it does. Add the startcode, and then copy the buffer
<mkver>
Yeah, as I guessed.
qeed has joined #ffmpeg-devel
<Lynne>
yup, same with vulkan, it's annoying
<Lynne>
also vulkan wants all slices in one buffer, because copying is nice
<BtbN>
wonder if one could do funky mmap magic to virtually stitch together such a continous buffer
<jamrial>
ff_h2645_extract_rbsp() skips the startcode even for raw_data?
<BtbN>
No idea WHAT skips it, but the buffer the hwaccel implementations get never have it
<BtbN>
The more involved approach to deal with this would be to somehow signal from the hwaccel that the startcode is needed, so the other code does not strip it
<jamrial>
looks like it does
<nevcairiel>
there is no guarantee a start code even exists