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]
mkver has quit [Read error: Connection reset by peer]
mkver has joined #ffmpeg-devel
rvalue has joined #ffmpeg-devel
kurosu has quit [Quit: Connection closed for inactivity]
feiwan1 has quit [Remote host closed the connection]
feiwan1 has joined #ffmpeg-devel
cone-064 has joined #ffmpeg-devel
<cone-064>
ffmpeg Andreas Rheinhardt master:2a0194bafa62: avcodec/ccaption_dec: Use static_assert instead of _Static_assert
<cone-064>
ffmpeg Andreas Rheinhardt master:e6c7a88b34c5: avutil/hash: Avoid relocations for hash names
<cone-064>
ffmpeg Andreas Rheinhardt master:f1b08b8a65c0: avcodec/mips/aaccoder_mips: Remove MIPS-specific aaccoder
<cone-064>
ffmpeg Andreas Rheinhardt master:7b48cc61bed4: avformat/aeaenc: Fix printf-specifier
<cone-064>
ffmpeg Andreas Rheinhardt master:6e63295d4135: avformat/crypto: Avoid cast, use proper printf specifier
thilo has quit [Ping timeout: 240 seconds]
thilo has joined #ffmpeg-devel
thilo has quit [Changing host]
thilo has joined #ffmpeg-devel
Marth64 has joined #ffmpeg-devel
mkver has quit [Ping timeout: 260 seconds]
Marth64 has quit [Remote host closed the connection]
<Lynne>
our build system is nice and all, and was faster than meson last I checked
<Lynne>
but it would still be nice to have meson, because it makes integration very easy
<psykose>
i don't believe that it's faster for a second given how slow make is at anything
HarshK23 has quit [Quit: Connection closed for inactivity]
<Lynne>
if you use zsh or bash as a shell with extensions, configure will be slow, but dash (the default shell on debian) makes it fly
<psykose>
i don't mean just configure, i mean the total time for conf+build
<Lynne>
make's pararellization is just as good for a project our size and type, there shouldn't be any difference
<JEEB>
2023/09 of H.273 is still in prepublished state :/
<JEEB>
I want to post a patch for the new values that will be introduced there since I'm 99% sure they're the same as in the last draft, but not being able to confirm is meh
<galad>
Anything useful in there? Or just some "sei that helps printing video on a needle printer" additions?
qeed has quit [Quit: Leaving]
<JEEB>
galad: some shutter speed stuff and neural network stuff. otherwise meh.
<JEEB>
> namely the shutter interval information SEI message, the neural-network post-filter
<JEEB>
characteristics SEI message, the neural-network post-filter activation SEI message, and the phase indication SEI message.
<JEEB>
and apparently some corrections to existing text without mentioning where
Krowl has joined #ffmpeg-devel
<aaabbb>
new sei types is that crap that has tiff in the sei?
<JEEB>
not yet
<JEEB>
I posted that from the working group's archive and that stuff generally is discussed
stevenliu_ has quit [Remote host closed the connection]
stevenliu_ has joined #ffmpeg-devel
<elenril>
JEEB: no, not config nor encoder
<elenril>
both are misleading
Krowl has quit [Read error: Connection reset by peer]
<JEEB>
elenril: alright.
<elenril>
it's side data associated with the decoded stream
<elenril>
there's nothing encoder-specific about it
<elenril>
and 'config' means nothing
<JEEB>
as you could see by me taking in jamrial's suggestion I'm not really married to a specific name, and I did note that config wasn't really too great
sepro has quit [Ping timeout: 256 seconds]
sepro has joined #ffmpeg-devel
SystemError has quit [Remote host closed the connection]
SystemError has joined #ffmpeg-devel
kurosu has joined #ffmpeg-devel
Krowl has joined #ffmpeg-devel
hamzah has joined #ffmpeg-devel
ngaullie has joined #ffmpeg-devel
cone-870 has quit [Quit: transmission timeout]
cone-349 has joined #ffmpeg-devel
<cone-349>
ffmpeg Zhu Pengfei master:4e5b1882d65c: avformat/flvdec: support enhanced flv PacketTypeMetadata
<cone-349>
ffmpeg Zhu Pengfei master:aeebcd2f7316: fate/flvenc: support enhanced flv PacketTypeMetadata
<cone-349>
ffmpeg Zhu Pengfei master:85e047e7cdb7: avformat/flvenc: support enhanced flv PacketTypeMetadata
<Lynne>
That NN NALU is very loosely defined
<Lynne>
"General visual quality improvemen" is a valid mode of operation
<Lynne>
Wonder if there's a model to emulate mid 2010s TV - motion blur maxed, contrast set to nuclear blast, and interlacing artifacts enhanced
<JEEB>
:D
<kierank>
needs to be a mode to emulate web streams, everything forced to 60p, forced 601
<Lynne>
709 incorrectly tagged as 601, limited range incorrectly tagged as full, chroma position random()
<Lynne>
59.94 incorrectly tagged as 60
<kierank>
netflix golf is atrocious
<kierank>
grass looks terrible, the framerate conversion is awful
<JEEB>
oh right, they do live now
<Lynne>
Youtube's grass is just DCT basis function artifacts
<JEEB>
(why on earth are they doing frame rate conversions)
<frankplow>
sdc: The FFVVC repo (or your own fork) is still handy for staging large patchsets though, there's GitHub actions set up to run the conformance suite on a few systems.
<sdc>
Yeah I think I just need to find a branch with the ibc code you were mentioning
<sdc>
Start from there instead
<sdc>
frankplow: thank you!
<frankplow>
sdc: No worries. IBC is in the FFmpeg master branch. I would imagine the work you've done should apply cleanly.
Sean_McG has quit [Quit: leaving]
jamrial has joined #ffmpeg-devel
<cone-349>
ffmpeg Timo Rothenpieler master:ae5453503d1e: avutil/hwcontext_d3d11va: remove check for d3d11 debug layer dll
<cone-349>
ffmpeg Timo Rothenpieler master:6e78d92399f4: avutil/hwcontext_d3d11va: prefer DXGI 1.1 factory when available
<cone-349>
ffmpeg Timo Rothenpieler master:030f4925b8be: avutil/hwcontext_d3d11va: add logging to dxgi debug interfaces
<cone-349>
ffmpeg Timo Rothenpieler release/6.0:cd49ee45ba4d: avutil/hwcontext_d3d11va: prefer DXGI 1.1 factory when available
<cone-349>
ffmpeg Timo Rothenpieler release/6.1:98436c51becd: avutil/hwcontext_d3d11va: prefer DXGI 1.1 factory when available
Sean_McG has joined #ffmpeg-devel
<BtbN>
The winner of todays symbol clash: svt-av1 copying a data-table from libaom, without changing the name or making it static.
<JEEB>
:)
<galad>
well, always better than the time x265 started using global variables and broke running more than one encoding session in the same process.
<galad>
(and it's still broken)
<JEEB>
yea x265 isn't moving really
<JEEB>
but good to know lol
<JEEB>
not that x265 is that important for me since I never got it to do 2160p50 realtime
<BtbN>
Someone adding a non-static div_u32 function
<Gramner>
in dav1d we added a CI check to verify that global symbols are prefixed, I think most projects would benefit from doing that
<Sean_McG>
mkver: looks like Alpha an SH-4 FATE nodes don't like the changes to ccaption_dec
Krowl has quit [Read error: Connection reset by peer]
<mkver>
GCC 4.7? is that even c11 compatible?
<Sean_McG>
(they use GCC 4.7.x -- too old for static_assert() ?)
<Sean_McG>
yeah, not sure... might not be
<mkver>
It accepted _Static_assert, but MSVC 19.27 doesn't. The latter only accepts static_assert, which the former doesn't.
<JEEB>
Gramner: yup, that's good usage of CI
<Sean_McG>
looking at the GCC documentation for 4.7 -- yeah, I think this is it... the support for C11 was only "experimental" in that release. So I think your change is correct and we should ping michaelni to see if he can bump to at least 4.8 or later.
<Sean_McG>
hmmm wait it was still experimental in 4.8
<Sean_McG>
4.9 looks like first "substantially complete" C11 support
<Gramner>
it's just slapped together and kind of rudimentary, but eh, good enough
<Sean_McG>
better than nothing
<another|>
Ah! That's what this is for
<Sean_McG>
michaelni: Alpha and SH-4 FATE nodes now need gcc 4.9.x or later for proper C11 support -- any chance of those nodes being updated soon?
<kasper93>
speaking of symbol clash, seems like dec_init after this c4de5778 conflicts with libbluray
<Gramner>
kasper93: I think that's what started the discussion. there's a big thread on the ML about it
Krowl has joined #ffmpeg-devel
SystemError has quit [Remote host closed the connection]
SystemError has joined #ffmpeg-devel
<kasper93>
ah, I see. I don't follow ML too closely
<kasper93>
too much drama
SystemError has quit [Remote host closed the connection]
SystemError has joined #ffmpeg-devel
<BBB>
koda noted that last week's ML was surprisingly drama-free
Workl has joined #ffmpeg-devel
Marth64 has joined #ffmpeg-devel
Krowl has quit [Ping timeout: 268 seconds]
AbleBacon has joined #ffmpeg-devel
MisterMinister has joined #ffmpeg-devel
derpydoo has joined #ffmpeg-devel
tufei__ has quit [Ping timeout: 260 seconds]
<michaelni>
Sean_McG, i can disable sh4 & alpha fate clients. updating them is not "just" going to work. i think this is still based on ancient emdebian or something so it needs a new setup anyway
<Sean_McG>
OK, fair enough.
<Sean_McG>
mkver: I wonder if we should do a check for static_assert() into configure and fail hard if it doesn't work.
<jamrial>
or fallback to _Static_assert if it fails, until we require c17
<Sean_McG>
I'd be fine with either one
<JEEB>
I think we can do a ff_static_assert or so for now
<Sean_McG>
I just want to help out people who don't realize they need a proper C11 compiler now
<JEEB>
ye it makes sense to actually handle this in configure
qeed has joined #ffmpeg-devel
unlord has quit [Ping timeout: 246 seconds]
unlord has joined #ffmpeg-devel
<BtbN>
I'm not sure going c17 anytime soon is a good idea
<Sean_McG>
it might be too soon, but it would be nice to have a FATE node to see how it looks -- unfortunately -std=c11 is hard-coded in configure at the moment, so running said FATE node would always require manual intervention
<haasn>
jamrial: what should we do about the H.274 colorimetry fields that are already in the H274-specific film grain struct though
<haasn>
if we move it into the common struct those would either have to be deprecated or broken
<haasn>
or duplicated, all of which seem undesirable
derpydoo has quit [Ping timeout: 260 seconds]
<jamrial>
is this about standalone av1 fg?
<haasn>
yeah
<jamrial>
probably best to put them in the common struct and deprecate the h274 ones, then setting both until the latter are removed
<jamrial>
and if they differ, then deprecated ones should take priority. that's what we did with channel layout for example
jarthur has joined #ffmpeg-devel
<jamrial>
that way if the new ones are unset but the old ones are set (expected scenario with callers linking to current lavu), it will still work
Workl has quit [Read error: Connection reset by peer]
SystemError has quit [Remote host closed the connection]
SystemError has joined #ffmpeg-devel
dykai has joined #ffmpeg-devel
dykai has quit [Client Quit]
<jamrial>
haasn: attribute_deprecated needs to be added to all the fields, but yes, like that
<jamrial>
subsampling is afgs1 only, right? why add it to the common struct?
<haasn>
jamrial: H.274 technically specifies that the given film grain metadata is to be applied for 4:4:4 only
<haasn>
and if you want to apply it to something else, you either need to adjust the film grain metadata, or you need to upconvert the frame before applying film grain
<jamrial>
ok
<haasn>
so IMO it is correct for H.274 to signal sub_x=sub_y=0
<haasn>
that said, we always hard-code this conversion process to 4:2:0 apparently
<haasn>
hrm
<jamrial>
haasn: it's ok, put them in the common struct. both being 0 means you don't even need to bother with them as that's the default post allocation
microchip_ has quit [Quit: There is no spoon!]
microchip_ has joined #ffmpeg-devel
microchip__ has joined #ffmpeg-devel
microchip_ has quit [Read error: Connection reset by peer]
microchip__ is now known as microchip_
mkver has quit [Ping timeout: 240 seconds]
microchip__ has joined #ffmpeg-devel
microchip_ has quit [Ping timeout: 255 seconds]
Krowl has quit [Read error: Connection reset by peer]
odrling has quit [Remote host closed the connection]
rajivharlalka has quit [Quit: Connection closed for inactivity]
qeed has quit [Quit: Leaving]
averne has quit [Ping timeout: 272 seconds]
ngaullie has quit [Ping timeout: 256 seconds]
averne has joined #ffmpeg-devel
j45_ has joined #ffmpeg-devel
j45 has quit [Ping timeout: 268 seconds]
j45_ is now known as j45
j45 has quit [Changing host]
j45 has joined #ffmpeg-devel
j45_ has joined #ffmpeg-devel
j45 has quit [Ping timeout: 240 seconds]
j45_ is now known as j45
j45 has quit [Changing host]
j45 has joined #ffmpeg-devel
ngaullier has joined #ffmpeg-devel
mkver has quit [Ping timeout: 252 seconds]
<Sean_McG>
hi Marth
<Marth64>
hows the iMac? :)
<Sean_McG>
switchover was mostly problem-free
<Sean_McG>
I need to get him a new external HD because the drives in the newer iMacs are too small (only 256GB) and he has a lot of photos
<Marth64>
reasonable
Marth64 has quit [Ping timeout: 260 seconds]
Marth64 has joined #ffmpeg-devel
<frankplow>
On AArch64/Linux, I'm having some strange behaviour debugging. All local variables come up as <optimized out>, even when compiling with --disable-optimizations. Symbols seem fine: if I try to print a variable it does know which variable I won't to print and also I am able to set breakpoints and other things. Both lldb and gdb are affected.
hamzah has joined #ffmpeg-devel
<frankplow>
Any ideas what this might be? I've compiled a couple other applications on the same system and all works as expected there.
<frankplow>
want to print*
<Sean_McG>
--disable-optimizations should have been enough, but I'm on x86 and also POWER[7-10]
<Sean_McG>
maybe something peculiar to aarch64?
<JEEB>
elenril: anyways if you and jamrial figure out a name that you can both agree upon I'll just rename that thing to that
<JEEB>
:)
<jamrial>
frankplow: try adding --enable-debug=gdb, but like Sean_McG said, --disable-optimizations should in theory have been enough
<JEEB>
I think frame_side_data or something was originally as opposed to packet side data, and then the encoder_ thing was just what jamrial proposed since the side data is utilized to configure an encoder
<jamrial>
JEEB: i suggested encoder_ and still like it, but if elenril disagrees then i wont opoose. i don't want to delay this for silly reasons
<frankplow>
jamrial: No luck with --enable-debug=gdb
<jamrial>
JEEB: but much like him, i don't agree with the avcodec helper/wrapper. the caller can and should use the lavu helpers you already added
<Sean_McG>
frankplow: do you use GCC or Clang or ..?
<jamrial>
JEEB: oh well
<JEEB>
I really don't see it being specific to decoded stuff
<JEEB>
it's just whatever is being passed to an encoder for configuration/whatever
<JEEB>
and then when it is being raised as a match to "coded_side_data", I don't even understand that one's naming myself :D
<jamrial>
yeah
<JEEB>
jamrial: and sure fine, I can go back to the _extend API that I used to have around v4
<jamrial>
just go with decoded_. no point arguing about it any longer. just make sure the doxy explains what it is for
<jamrial>
JEEB: no, i mean just add the loop in the cli
<jamrial>
no need for an extend helper in lavu either
<JEEB>
:/ so each API user that wants to do something similar to ffmpeg.c will have to make up their own loop?
<JEEB>
that was my primary idea
<frankplow>
Sean_McG: Issue was with Clang 16.0.6. Just tried GCC 12.3.0 and it seems to have fixed the issue
<jamrial>
JEEB: no different than currently needed to add side data to packets and frames with the existing helpers
<Sean_McG>
ahhh, hmm. still something we should look into.
<JEEB>
jamrial: eh, OK.
<JEEB>
since I think mkver would have been OK with that
<jamrial>
it can be addded later in any case
<JEEB>
and at this point this patch set has been in review for way too long
<jamrial>
yeah, don't add more things that will generate arguments. keep the api additions to a minimum
<JEEB>
excuse me? :D I've not added more API things for a few revisions now :D
<Sean_McG>
frankplow: what distro are you using? Debian?
<JEEB>
also I do agree that the helper makes more sense if I had ended up being able to put the array on the private side so you could only touch it through the API
<JEEB>
that is not how that thing ended up being in the struct due to the FF-avctx thing being allocated in very specific locations
<JEEB>
(the private struct for avctx)
<JEEB>
but still, people were fine with the avctx stuff as opposed to the _extend API in v4 or so :P
<frankplow>
Sean_McG: NixOS. Its weirdness means the issue is likely my environment, I know, but I have the same setup working for debugging other applications.
<Sean_McG>
OK.
<jamrial>
JEEB: so yeah, patches 1 to 6 and 8 are good as is
<JEEB>
also regarding this patch set I've privately received comments on things like this being why certain people want to make sure during IRL meetings that they get some implementation/design decided in
<jamrial>
leave 7 for later until we agree on the semantics, as it's not used for now
<JEEB>
before they start writing code, because they don't want to end up in situations like this :D
<jamrial>
9 is ok but rename it to decode_ like elenril suggested
<jamrial>
drop 10, and reimplement 11 to do the loop in the CLI
<jamrial>
is that ok?
<jamrial>
IMO just push 1 to 6 and 8 now
<JEEB>
without any API users :D
<JEEB>
I'll double-check if he said decode_ or decoded_ in v7 thread, will drop the avctx helper and do the loop in ffmpeg_enc
<jamrial>
doesn't matter, they will come soon, and pushing it will make you feel better :p
<JEEB>
> I'd prefer to call it 'decoded_side_data' or 'raw_side_data'
<jamrial>
go with decoded_ then. better contrast to the existing coded_
cone-685 has quit [Quit: transmission timeout]
<frankplow>
Think I got to the bottom of the issue: https://github.com/NixOS/nixpkgs/issues/18995 Been playing with NixOS and quite liked it overall, but this is a questionable choice and I don't see how the issue isn't resolved after 6 years and dozens of complaints.
<Sean_McG>
oh, cute.
<frankplow>
Various workarounds proposed in that issue work. That being said, not sure why only FFmpeg seemed to be affected. I tried debugging some other applications (was side-by-side debugging VTM), with an identical environment, and variables seemed fine there. Wouldn't have posted here if it affected other applications.
<Sean_McG>
at a guess, configure doesn't like some of those options being already set
<Sean_McG>
remember, we don't use autotools, 'configure' is fully custom
<Sean_McG>
"bespoke", which is a word I don't get to use often :)
<jamrial>
JEEB: lgtm. add version bumps and apichanges entries where missing, and push everything except patch 7
<JEEB>
oh right, APIchanges
jamrial has quit []
jamrial has joined #ffmpeg-devel
iive has joined #ffmpeg-devel
<JEEB>
jamrial: posted the bumps and APIchanges onto the same branch, if that looks good enough I'll post them onto the ML so that they officially were put there.
<JEEB>
avutil APIchanges doesn't have that AVBufferRef function since apparently you want me to skip it
<jamrial>
JEEB: until we decide on the semantics, yeah. i'm ok with it, but anton is not
<JEEB>
and I really don't care either way since the patch set didn't utilize it :)
<jamrial>
JEEB: i see there's some references to side_data_set still
<jamrial>
but otherwise it's ok
<JEEB>
in the test code I kept the struct internally because I was lazy to rewrite the test to two separate variables, which I hope is OK. but yea, the internal functions and the name of the test, sure
qeed has joined #ffmpeg-devel
<JEEB>
I guess `add_side_data_from_buf` is good enough for an internal func?
<JEEB>
(removing the "to_set_"
<jamrial>
sure
<jamrial>
could change set to array too
<jamrial>
it's not important
Marth64 has quit [Remote host closed the connection]
<JEEB>
asdf, renaming the test and even after running configure again it still says the renamed one isn't around o_O
<JEEB>
oh right, probably in Makefile
<JEEB>
prkl
<JEEB>
there, that worked and passed
<JEEB>
jamrial: there, now all references to "_set" have been removed so the only thing is within the side_data_array test which does utilize a 100% internal struct FrameSideDataSet
<jamrial>
cool
<jkqxz>
Lynne: Vulkan is not an experimental thing any more. It would be nice if it autodetected correctly on any relatively recent distribution without installing extra headers.
<jkqxz>
I don't think that should be a blocker here, but it doesn't seem ideal to keep bumping like this forever.
<JEEB>
jamrial: there, posted v10 on the ML
<JEEB>
I have no idea for whom I'm writing all these cover letters for >_>
<Lynne>
jkqxz: fair enough
<Lynne>
I'd prefer to keep the version bump, as without maintenance1, video encode is essentially impossible for us, and the ifdef would be high
<Lynne>
but for future ones, I agree
<Lynne>
do you have any comments on the frame_id yet, or should I resend?
kasper93_ has joined #ffmpeg-devel
kasper93 has quit [Ping timeout: 252 seconds]
hamzah has quit [Quit: Client closed]
kasper93_ has quit [Ping timeout: 252 seconds]
ngaullier has quit [Ping timeout: 255 seconds]
microchip_ has quit [Quit: There is no spoon!]
microchip_ has joined #ffmpeg-devel
aaabbb has quit [Ping timeout: 260 seconds]
kasper93 has joined #ffmpeg-devel
Mister_D has joined #ffmpeg-devel
MisterMinister has quit [Ping timeout: 268 seconds]