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 8.0 has been released! | Please read ffmpeg.org/developer.html#Code-of-conduct
Kimapr_ has quit [Remote host closed the connection]
Kimapr_ has joined #ffmpeg-devel
Traneptora has joined #ffmpeg-devel
Kimapr_ has quit [Remote host closed the connection]
<fjlogger>
[FFmpeg/FFmpeg] Pull request #20499 closed: use AVFMT_EVENT_FLAG_METADATA_UPDATED because of event_flags belongs to AVFormatContext. (https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/20499) by jiangjie
<BtbN>
wbs: the question is, do we want cflags to be applied to objc, or not? For C++ we definitely do not, which is what that commit fixes, cause it did nonsense like passing -std=c17 to the C++ compiler.
<BtbN>
But I have no experience with objc? Is it the same situation there, and it should be split cleanly, or should it just also get passed all CFLAGS?
<wbs>
BtbN: that's a good question. I think flags like -std=c17 are ok in objective C mode; they were used before and that worked allright
<BtbN>
I also just noticed this: --extra-objcflags=FLAGS add FLAGS to OBJCFLAGS [$CFLAGS]
<BtbN>
it just puts CFLAGS there as defaults?
<wbs>
that kinda looks like a typo
<BtbN>
What exactly breaks build on OSX right now? Is it just some flags that right now are only add_cflags in configure, but should be allcflags/also be objcflags?
<wbs>
I have configurations where I used '--extra-cflags="-arch x86_64" --extra-ldflags="-arch x86_64"', to do the apple style cross compilation for another macos architecture
<wbs>
now currenlty those flags are missing from the objective C checks in configure
<BtbN>
Also, why does common.make have OBJCFLAGS and OBJCCFLAGS
<BtbN>
*common.mak
<wbs>
currently that seems to not have any ill observable effect, even though the configure check doesn't really check the right thing in the end
<BtbN>
It's pretty much a question on if we want --extra-cflags to also go to objc, or if they should be in --extra-objcflags instead
<wbs>
yep
<BtbN>
common.mak does OBJCFLAGS += $(EOBJCFLAGS)
<BtbN>
and then OBJCCFLAGS = $(CPPFLAGS) $(CFLAGS) $(OBJCFLAGS)
<wbs>
yep
<BtbN>
very confusing. EOBJCFLAGS aren't defined or used anywhere in the whole codebase
<BtbN>
And I don't immediately see OBJCCFLAGS being used either, only OBJCFLAGS
<BtbN>
But it must be used, since the cflags end up on the commandline
<BtbN>
Oh, COMPILE_M = $(call COMPILE,OBJCC)
<BtbN>
it has an extra C there, so it'll refer to OBJCCFLAGS
<BtbN>
is that intended??
<BtbN>
I guess so, cause OBJCC refers to the objc compiler. And it calls a macro for it
<BtbN>
messy, but okay then
<wbs>
yeah, sounds messy but probably ok
<wbs>
is there any flag like --extra-allcflags, for passing flags to all language modes?
<BtbN>
No, but could be easily added
<wbs>
it might be wanted by people after this change
<BtbN>
So OBJCCFLAGS = $(CPPFLAGS) $(CFLAGS) $(OBJCFLAGS) should lose its CFLAGS then?
<BtbN>
Then it matches how configure tests objc
<wbs>
that would be consistent with how c++ is handled. but as the other C specific flags, like -std=c17 are accepted (and probably affect the version of C tolerated in objc) it can probably be argued that it should be kept included (and configure should use cflags for objc as well)
<BtbN>
Would extra-allcflags even be needed? cppflags is pretty much exactly that.
<wbs>
that's true
<BtbN>
(You can't set that from CLI right now either, but that could also easily be added)
Anthony_ZO has quit [Quit: Anthony_ZO]
Anthony_ZO has joined #ffmpeg-devel
<BtbN>
Pretty much two ways to this: Add CFLAGS to line 1095 of configure, or remove it from line 50 in common.mak
<BtbN>
Adding it in configure is the safer way, since it makes objc work like it always did so far
Anthony_ZO has quit [Read error: Connection reset by peer]
Anthony_ZO has joined #ffmpeg-devel
<BtbN>
Though that must have been an issues before already? Cause I didn't remove the CFLAGS from there, it was always like this.
<BtbN>
I guess before this a bunch of stuff was in CPPFLAGS that's now in CFLAGS
Anthony_ZO has quit [Client Quit]
<BtbN>
But the inconsistency of configure not passing CFLAGS to OBJCC but the makefiles doing so is not new
Anthony_ZO has joined #ffmpeg-devel
Anthony_ZO has quit [Client Quit]
Anthony_ZO has joined #ffmpeg-devel
Anthony_ZO has quit [Client Quit]
<BtbN>
wbs: yeah, I don't immediately understand how --extra-cflags would have ever ended up on the objcc commandline during configure, even before that patch
<wbs>
looking into that now
<wbs>
0ce413af9cc8040095a6b714600d6a8dceaca514 did remove $CFLAGS from test_objcc
<BtbN>
ah, yeah, that'd do it.
<wbs>
and indeed, readding it there does make configure consistent with the build
<wbs>
btw, I had to add --extra-ldflags="-static-libstdc++ -static-libgcc" on all my mingw-on-wine fate instances, as it now depends on runtime DLLs that it didn't use to do before (could also fix it by copying those DLLs into the path while building, but linking them statically is easier)
<wbs>
that probably isn't an issue for non-cross mingw setups though
<wbs>
that gcc warning is really annoying
<ePirat>
BtbN, there is an issue with configure, for some reason it only showed up recently for me after some of your changes although it doesnt seem directly related...
<ePirat>
Using "--toolchain=clang-asan" I get ./configure: line 976: -fsanitize=address: command not found and ./configure: line 976: -fno-omit-frame-pointer: command not found
<ePirat>
this is because add_sanitizers calls add_allcflags, which calls append which in turn calls add_objcflags doing effectively: append OBJCFLAGS $($objcflags_filter "$@")
<ePirat>
but objcflags_filter at this point is an empty string still so it tries to call the argument as a program
<Traneptora>
ah, and it's not quoted either
<Traneptora>
would quoting it just fix that
<ePirat>
no
<ePirat>
it still wouldnt lead to the correct outcome which is adding the flag with the flags filter applied to it
<Traneptora>
so the root issue is that the flag filter is empty
<ePirat>
yes, because this is done before the flags filter is set
<ePirat>
I have no clue how to properly fix this
<ePirat>
also I have no idea how this was never an issue before
<ePirat>
as the toolchain is handled before the compiler is checked and the filter is set
<ePirat>
I see… apparently it is just set to echo for the cflags before getting set to something else again later...
<ePirat>
which I guess while not the most clean fix I will just propose that as it evidently didnt matter all these years
<Traneptora>
jamrial: 327680 is 5 << 16. payload reads 4 bytes, regardless, and 327680 is a 4-byte big-endian integer, with the second half being all zeroes
<Traneptora>
when it actually goes to read the tag, it only reads a big-endian short, which ends up as 5, ignoring the last two zero bytes
<Traneptora>
because av_exif_write always writes little endian buffers, it writes the four bytes 0x 05 00 00 00, rather than the four bytes 0x 00 05 00 00
<Traneptora>
on line 291 it calls "ff_tget_short" and reads 5, regardless of the payload value
<jamrial>
Traneptora: av_display_rotation_set() seems to be getting a nan when called from av_exif_orientation_to_matrix() for that one png
<jamrial>
but not the input jpg, where it gets 90.0
<BBB>
clearly not what I thought id did
rvalue has joined #ffmpeg-devel
<ePirat>
BBB, which button?
<BBB>
the red one, "merge after rebase and checks succeed"
<BBB>
I clicked it, and it didn't rebase, which is what I expected it to do
<Traneptora>
jamrial: how is that possible when all arguments are hardcoded
<jamrial>
that's what i'm asking myself
<ePirat>
BBB, huh weird
<BBB>
it's ok, there's a rebase button right next to it
<BBB>
"The time to compile vp9itxfm.asm is reduced to less than half" << nice!
<BBB>
haasn: 20503... seems very, uh, filter'y
<BBB>
haasn: I'm not sure I'm enough into filters to know what that does
<haasn>
fair enough
<BBB>
for me, filters are magic things that do pad init process contract gstreamer and then there's some magic code in the middle which actually *does stuff*, and that code I understand
<BBB>
(using language from ffmpeg's twitter account)
<ePirat>
haasn, dont you only need to report on outlink EOF?
<haasn>
ePirat: you mean only report on inlink EOF?
<haasn>
if anything, inlink EOF is the normal end of a file; unless downstream is length limited via -t
<ePirat>
haasn, Ah right this filter doesnt need to bother with draining any buffered frames so doing it on both is probably fine.
<BBB>
I believe the original reference was "[2] This seems to happen whenever I see anyone try to write anything in C++. They just spend all day figuring out how to connect things to other things and never write the part that does anything?", by astrange :D (https://news.ycombinator.com/item?id=44943687)
<BBB>
I'm not saying libavfilter is bad, just that my interest/knowledge isn't really in the "how to connect things", but rather in the "actually do stuff". they're both valuable and necessary, obviously
<haasn>
fully agree; though I think avfilter's API is pretty reasonable from a filter pov
<ePirat>
the activate functions are annoying though
<ePirat>
writing a correct one is insanely hard
<ePirat>
especially if you have a more complex case with audio and video in one filter
<kepstin>
indeed, but that's just because filter queue management is hard :(
<ePirat>
but also the API design for this isnt great
<haasn>
for sure; though the macros help IMO what is missing is documentation / examples
<ePirat>
the macros are footguns
<ePirat>
they only works for very specific cases without saying so
<kepstin>
yeah, when i was doing the fps filter i realized after a while that the macros weren't really useful for filters which do any significant amounts of frame dropping or generation :/
<haasn>
I'd be curious to hear what alternate APIs you'd design that still let fully asynchronous N:M filters like vf_libplacebo exist
<kepstin>
without C having a native "async" syntax that allows a function to be put on hold and resumed later, I honestly can't really think of a significantly better api.
<kepstin>
since any time you need to wait for more input frames, or wait for outputs to be ready to receive more frames, you have to return from the function.
<ePirat>
IMHO the main issue is documentation being not clear enough about some cases
kode540 has joined #ffmpeg-devel
kode54 has quit [Ping timeout: 250 seconds]
kode540 is now known as kode54
<haasn>
I think if I had to design a blackbox API, I'd make it so activate() is always called with an *outlink that a frame is being requested on
<haasn>
I'd also make e.g. the function to request a frame from an input automatically mark that input as "frame wanted" if there are no frames queued
<haasn>
so you don't have to have a function like FORWARD_WANTED at all
<haasn>
it would just happen implicitly when you request a frame from an input (after activate() was called for a given output)
b50d has joined #ffmpeg-devel
b50d has quit [Remote host closed the connection]
<mkver>
BtbN: Running configure with --toolchain=clang-asan now gives "./configure: 976: -fsanitize=address: not found ./configure: 976: -fno-omit-frame-pointer: not found" messages.
MisterMinister has quit [Ping timeout: 245 seconds]
<mkver>
ePirat: Thanks for taking care of this.
<kepstin>
haasn: unclear how that would work with multiple outlinks, and i think there are some cases where activate can be called without any outlinks requesting frames (don't recall offhand what circumstances might cause that, tho)
<Lynne>
err, did something break or touch flac parsing recently?
<Lynne>
"flac: Could not find codec parameters for stream 0 (Audio: flac, 0 channels): unspecified sample format"
<Lynne>
other files work fine, but these worked fine up until a month ago
<mkver>
Lynne: Do these files have ID3v2 tags? This might have been broken by 9d037c54f209958d47ac376d2a9561608f98dfae.
<Lynne>
yeah, they do, and I don't think their tags had correct encoding
<mkver>
It indeed starts with ID3v2 tags that are now no longer skipped.
<mkver>
So it has been broken by the aforementioned commit.
<Lynne>
"Introduces AVFMT_FLAG_ID3V2_AUTO and applies it to mp3, aac, tta, and wav.", why not flac?
<jamrial>
flac uses vorbiscomment normally, i think
<mkver>
Because these are the only formats for which ID3v2 at the start would have been applied before.
<Lynne>
ah, I see
<mkver>
Before this commit, the check for leading ID3v2 metadata was performed unconditionally (you only need to have an AVIOContext), but it was applied only for whitelisted formats. Now these tags are only consumed for whitelisted formats.
<mkver>
The actual issue was that raw formats (e.g. PCM) can start with what appears to be an ID3v2 tag, although it isn't.
<Lynne>
I thought id3v2 tags were stored in some container-specific way, are they just dumped in front of the whole container?
<fflogger>
[editedticket] mkver: Ticket #11233 ([avformat] heap-buffer-overflow occurred when running program ffmpeg in av_crc at crc.c) updated https://trac.ffmpeg.org/ticket/11233#comment:2
NullSound has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
<mkver>
haasn: Does vf_colordetect work with 8bit formats when BE? These formats don't have an endianness at all, so the descriptors don't have AV_PIX_FMT_FLAG_BE.
ngaullie has quit [Remote host closed the connection]
<haasn>
mkver: what is the practical benefit of av_cold?
<mkver>
It means that the function is optimized more for size than for speed. It also puts the functions in a separate section (.text.cold), which the linker uses to ensure that the cold functions are besides each other, which may improve chaching a tiny bit.
<BtbN>
Should the config_props functions also be av_cold?
<BtbN>
They also run only exactly once I think?
<mkver>
If they are only run once, then yes.
<BtbN>
I think those run only once on startup, but I'm not 100% sure