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
jdek has quit [Ping timeout: 245 seconds]
witchymary has joined #ffmpeg-devel
tufei has quit [Remote host closed the connection]
tufei has joined #ffmpeg-devel
Kei_N_ has joined #ffmpeg-devel
Kei_N has quit [Ping timeout: 245 seconds]
^Neo has quit [Ping timeout: 252 seconds]
abdu has quit [Quit: Client closed]
abdu has joined #ffmpeg-devel
thilo has quit [Ping timeout: 252 seconds]
thilo has joined #ffmpeg-devel
mkver has quit [Quit: Leaving]
abdu has quit [Quit: Client closed]
abdu has joined #ffmpeg-devel
<toots5446>
michaelni: looks like that api-dump-stream-meta test binary needs to either be built statically when cross compiling or to be able to find the required DLL to make the test run with wine. Any advice on how to do that?
<toots5446>
I configured my local build with --target-exec=wine --disable-debug --cross-prefix=x86_64-w64-mingw32- --arch=x86_64 --target-os=mingw32
<toots5446>
make ./tests/api/api-dump-stream-meta-test.exe then wine ./tests/api/api-dump-stream-meta-test.exe and I get:
<toots5446>
0024:err:module:import_dll Loading library libwinpthread-1.dll (which is needed by L"Z:\\..\\FFmpeg\\tests\\api\\api-dump-stream-meta-test.exe") failed (error c000007b).
<toots5446>
Works with a -static flac but that breaks compilation for the native host.
<toots5446>
*flag
<jamrial>
that looks like a toolchain issue rather than your patch being wrong
<jamrial>
do the other api tests work?
<toots5446>
yeah. I have the fix for cross-compilation in general, I needed to prefix the cmd call by $(TARGET_EXEC)
<toots5446>
I agree, could be a matter of toolchain setup. I'll submit the updated patch set. Is there an automatic output I could look at for reference for running the mingw tests?
JackJ30 has quit [Remote host closed the connection]
<jamrial>
toots5446: i think you're missing "run" in the CMD line
^Neo has joined #ffmpeg-devel
^Neo has joined #ffmpeg-devel
abdu has quit [Ping timeout: 240 seconds]
^Neo has quit [Ping timeout: 252 seconds]
jamrial has quit []
<fflogger>
[newticket] gamer191: Ticket #11526 ([avformat] cmfv and cmfa not in hls allowed_extensions) created https://trac.ffmpeg.org/ticket/11526
System_Error has quit [Remote host closed the connection]
System_Error has joined #ffmpeg-devel
tufei has quit [Remote host closed the connection]
tufei has joined #ffmpeg-devel
mkver has joined #ffmpeg-devel
<fflogger>
[editedticket] RandomPerson: Ticket #11363 ([avcodec] MediaCodec de/encoders no more work since Android 15 (No output buffer available)) updated https://trac.ffmpeg.org/ticket/11363#comment:11
<fflogger>
[editedticket] Gyan: Ticket #11469 ([ffmpeg] ffmpeg_demux: readrate plays "catch up" if output is blocked, then later resumed) updated https://trac.ffmpeg.org/ticket/11469#comment:14
abdu has joined #ffmpeg-devel
^Neo has joined #ffmpeg-devel
^Neo has joined #ffmpeg-devel
DodoGTA has quit [Quit: DodoGTA]
DodoGTA has joined #ffmpeg-devel
jamrial has joined #ffmpeg-devel
<cone-946>
ffmpeg Michael Niedermayer master:62c7d08947f5: avcodec/ffv1: Fix remap ordering
<cone-946>
ffmpeg Michael Niedermayer master:171060d5dc54: avcodec/ffv1: 32-bit float sample support
<cone-946>
ffmpeg Michael Niedermayer master:e19496fe71ae: avcodec/ffv1enc: remap allows using rice golomb with more bits
<cone-946>
ffmpeg Michael Niedermayer master:0538b4c5691a: avcodec/ffv1dec: remove unused var
<cone-946>
ffmpeg Michael Niedermayer master:5dcf566f690c: avcodec/ffv1: Implement 2D RLE for remap
Traneptora has quit [Ping timeout: 248 seconds]
<cone-946>
ffmpeg James Almer master:fee5b0a38344: fftools/ffmpeg_filter: ensure ifp is set before dereferencing it
lemourin has joined #ffmpeg-devel
lemourin is now known as Guest7356
gamer191 has joined #ffmpeg-devel
Guest7356 has quit [Ping timeout: 252 seconds]
Anthony_ZO has quit [Quit: Anthony_ZO]
Anthony_ZO has joined #ffmpeg-devel
microchip_ has quit [Ping timeout: 252 seconds]
gamer191 has quit [Quit: Client closed]
gamer191 has joined #ffmpeg-devel
<toots5446>
jamrial: Added it but same error. I also get this error when running a FATE test using the cross-compiled ffprobe so I think this is a local toolchain issue.
<JEEB>
toots5446: compilers by default prefer dll.a dependencies to static .a
<JEEB>
how you are supposed to handle these things is to copy the dependency DLL files into the directory of the binary (technically the PATH I think), so you might be able to get it done by just adding the directory with the toolchain DLLs to PATH
<JEEB>
not sure how wine and PATH work
<JEEB>
alternatively you make sure you have the .a file and not only the .dll.a in the lib/ directory of the cross-compilation sysroot
<JEEB>
and then you move the .dll.a away from the lib/ dir
<JEEB>
that forces the linker to utilize .a since the .dll.a is no longer available
<wbs>
you can also add "-static" to the linker; but that assumes that no other libraries that you link exist only in .dll.a form
abdu has quit [Quit: Client closed]
<toots5446>
Well the real question here is how to reproduce what the failing tests reported by michaelni does. I have compiled in static and confirmed that the test pass when the binary can be run so I suppose that, if the test env is able to run the binary, the test will pass.
abdu has joined #ffmpeg-devel
gamer191 has quit [Quit: Client closed]
<toots5446>
i.e. my problem is: I do not know how to reproduce the test environment workflow.
<JEEB>
if your binary just requires the winpthreads DLL, you can just copy that into the directory of the binary
<JEEB>
it got picked up because you had the dll.a in lib/ which links against the DLL
<JEEB>
or do you mean something else?
<wbs>
JEEB: he's saying that michael reported a bug to him "in a mingw build" but he's unable to reproduce that problem in the mingw build he's done himself
<JEEB>
yea but his questions so far earlier mostly were regarding not being able to run the binary due to the DLL
<JEEB>
ah, "Works with a -static flag", missed that
<JEEB>
so he did make it work, apparnetly
<JEEB>
OK, then it is what you note wbs since apparently the "running the built binary" part is no longer an issue :)
<toots5446>
It would be nice to add the mingw and other cross-compiled stuff to the CI at code.f.o
<toots5446>
I'm using it as reference before sending my patches atm
System_Error has quit [Ping timeout: 264 seconds]
<wbs>
jamrial: thanks for fixing, although fate still seems to be broken due to one of the ffv1 commits...
paulk has quit [Ping timeout: 252 seconds]
microchip_ has joined #ffmpeg-devel
paulk has joined #ffmpeg-devel
paulk has joined #ffmpeg-devel
Traneptora has joined #ffmpeg-devel
<michaelni>
toots5446, ./ffmpeg.exe fails here, wine ./ffmpeg.exe works (its possible to set the box up so it would run it without explicit call to wine, maybe thats the difference)
<michaelni>
but if you confirm that the new patch puts wine in front and the old didnt, i think that would confirm that it liekly fixes it
<JEEB>
at least the one FATE mingw node I saw did tell explicitly that wine should be utilized
<JEEB>
so I'd expect if the configure option is given that wine as a command is prepended
<michaelni>
yes
<JEEB>
if not it'd be a bug in toots5446's test addition
<JEEB>
`--target-exec=wine`
<JEEB>
that was the thing
<JEEB>
so if the test failed with that, then it had a boog
<jamrial>
wbs: np
microchip_ has quit [Quit: There is no spoon!]
microchip_ has joined #ffmpeg-devel
<haasn>
I assume we are fine producing undefined data if a user gives us a yuv420p10 frame with an illegal input value (exceeds 10 bit range, e.g. 2000)?
<haasn>
as long as we don't execute undefined _behavior_
<mkver>
Your "undefined" output needs to be the same across all arches.
<mkver>
At least when the bitexact flag is set.
<Lynne>
the bitexact flag should not exist IMO
<Lynne>
the only part that produces output not consistent with all other platforms we support is some forgotten badly written power8 simd
<wbs>
Lynne: with current swscale, x86 differs in many, many functions
<Lynne>
you mean mmx?
<wbs>
no, all the x86 asm
<haasn>
mkver: so in the context of static range analysis, I should treat yuv420p10 and yuv420p16 as equivalent?
<haasn>
I guess that makes sense anyway, if we have a sequence like: y = read_luma(); y = min(y, 1023); y = lut[y]; write_luma(y); we definitely don't want to eliminate the min(y, 1023)
<haasn>
even though y > 1023 would be considered an "illegal" input, we still need to be robust against it; so we should always use an explicit saturation rather than simply truncating bits when e.g. downconverting from 10-bit to 8-bit
<haasn>
(after division by 1/4)
minimal has joined #ffmpeg-devel
<Lynne>
for shame
Traneptora has quit [Quit: Quit]
<Lynne>
there are no excuses not to write bitexact simd imo, even in extreme cases, the correct generally working solution is no more than a few cycles slower
microlappy has joined #ffmpeg-devel
Traneptora has joined #ffmpeg-devel
ccawley2011 has joined #ffmpeg-devel
microlappy has quit [Quit: Konversation terminated!]
<toots5446>
michaelni: yes I can confirm the latest patchset adds the target exec when running the tests. It was a bit confusing because you have to add a "run" prefix but thankfully, jamrial pointed it out to me.
microlappy has joined #ffmpeg-devel
<haasn>
ramiro: implemented a static range analyzer, now we can omit the 0 <= x <= 255 clamp in the case of e.g. conversion from rgb24 -> yuv444p as the static analyzer determines that the output is already guaranteed to be in-range
microlappy has quit [Client Quit]
odrling has quit [Remote host closed the connection]
odrling has joined #ffmpeg-devel
abdu31 has joined #ffmpeg-devel
abdu15 has joined #ffmpeg-devel
abdu has quit [Ping timeout: 240 seconds]
abdu31 has quit [Ping timeout: 240 seconds]
Anthony_ZO has quit [Ping timeout: 260 seconds]
Traneptora has quit [Ping timeout: 276 seconds]
<jamrial>
michaelni: the ffv1enc failures are due to excessive stack use it seems
ngaullier has quit [Read error: Connection reset by peer]
ngaullie has joined #ffmpeg-devel
cone-946 has quit [Quit: transmission timeout]
twelve has joined #ffmpeg-devel
another| has quit [Remote host closed the connection]
<jamrial>
also that it doesn't break float encoding
twelve has quit [Remote host closed the connection]
abdu has joined #ffmpeg-devel
abdu15 has quit [Quit: Client closed]
<michaelni>
jamrial, will check in a moment
<michaelni>
jamrial, LGTM
<michaelni>
also once the issue is fixed, probably makes sense to only allocate when its actually needed (float32)
Martchus has quit [Ping timeout: 245 seconds]
Martchus has joined #ffmpeg-devel
cone-348 has joined #ffmpeg-devel
<cone-348>
ffmpeg James Almer master:702239bc500b: avcodec/ffv1enc: reduce stack usage
ccawley2011 has quit [Ping timeout: 260 seconds]
Griummauld has joined #ffmpeg-devel
<Griummauld>
Heyy! Quick question: I see ffplay links against sdl2, and there is some detection logic in the `configure` script. Is there plans to move to sdl3 for ffplay? Would a patch/patch set giving sdl3 compatibility be welcome?
Guest34 has joined #ffmpeg-devel
<JEEB>
I'd say if you care enough about it running on sdl3, feel free to hack on it :)
<Griummauld>
alright! i'll have a poke then, cheers
<Guest34>
i'm trying to integrate fate test suite to my ffmpeg build. I see that it is running the tests but i don't have any logs showing the tests passed/failed. is there a way to do it ?
<Guest34>
for some reason, i'm unable to run the -report option while running fate tests.
odrling has quit [Remote host closed the connection]
<JEEB>
Guest34: `make fate SAMPLES=path/to/fate-suite` should do it and output to stdout or stderr
odrling has joined #ffmpeg-devel
<JEEB>
and `make fate-rsync SAMPLES=path/to/fate-suite` before that to sync the samples (this should be cached)
<JEEB>
so you don't re-get the same files over and over
Guest34 has quit [Client Quit]
odrling has quit [Remote host closed the connection]
<JEEB>
GNOME's gitlab also earlier took it into use
<kierank>
ok it's not some weird anime hack
<sfan5>
is it supposed to take more than 15 seconds on a desktop PC
<sfan5>
because it just did for me
<llyyr>
the difficulty is just set higher on ffmpeg's deployment of it
<llyyr>
gnome's takes less time
<sfan5>
I hope ffmpeg has patient users then
<llyyr>
it can probably be lowered :shrug:
<thardin>
what the shit
<thardin>
why do I need to run some webshit to look at a static page? ridiculous
<JEEB>
I guess BtbN took it into use since otherwise the LLM bots were making the thing fail
<BtbN>
Yeah, it's the last idea to have to keep the server alive at this point
<JEEB>
also IIRC if you don't have mozilla in the user agent it doesn't require the test since all of the bots seem to want to claim they are such in order to get "real content" to scrape
<BtbN>
And trac is not static pages
<thardin>
I guess they're not. but it's been perfectly usable js-free. also /ticket isn't even in robots.txt
<BtbN>
robots.txt is flat out ignored anyway
<BtbN>
Also, I wouldn't want to put tickets into robots.txt. It's nice to have them indexed
<thardin>
true
<thardin>
and of course legislation will take some time to catch up to this nonsense, making punching an inviable option for now
<BtbN>
The vast majority of the super aggressive cralwers all come out of China anyway
<thardin>
push the button, chairman xi
<thardin>
I guess they also change IP frequently to where serverside throttling is not viable?
<BtbN>
no request comes from the same IP
<JEEB>
are they all from alibaba's or tencent or someone else's network?
<thardin>
IPv4 or IPv6? or both?
<BtbN>
trac doesn't even have IPv6
<BtbN>
soo
<BtbN>
blocking the IPs isn't viable though. You'd env up blocking virtually the entire world sonner than later
<thardin>
blocks don't need to be forever
<thardin>
fail2ban can be configured to deal with this I think. lure the bots to a honeypot URL, then have fail2ban put them in time-out for a while
<BtbN>
but on what would fail2ban trigger?
<thardin>
trac.ffmpeg.org/killme
<BtbN>
Each individual request is a boring normal request
<BtbN>
So far Anubis hasn't been defeated, and if it would be, it'd probably get updated asap
<BtbN>
Anubis is pretty much just a Hashcash-Implementation
<sfan5>
I mean all you can do is raise the difficulty rating
<BtbN>
there's other ways to circumvent it
<BtbN>
i.e. "don't be Mozilla"
<sfan5>
this moves the waiting time into increasingly unviable territory for browser users, while scrapers can just throw the most hardware-optimized implementation at the problem
<BtbN>
I doubt scrapers would bother to spend 10+ seconds on each individual request
<thardin>
it's a bit of a fu to blind users as well
Guest24 has joined #ffmpeg-devel
abdu86 has quit [Ping timeout: 240 seconds]
<thardin>
but whatever, at least it's only once
<thardin>
could do with de-weebing
<Guest24>
hi
<Guest24>
Where do we report issues and bugs?
<BtbN>
I don't think it has an option to change the logo
<kierank>
trac.ffmpeg.org
<JEEB>
the place I noted on #ffmpeg
<kierank>
21:13:48 <thardin> could do with de-weebing
<kierank>
amen
<JEEB>
and yes what kierank noted
<BtbN>
Would love to put an FFmpeg logo there instead
<JEEB>
thardin: the worst bit is the default image is AI slop :<
<JEEB>
six fingers and all
<JEEB>
> fighting against AI slop by using AI slop
<BtbN>
the issue to allow changing the logo without forking the whole project was rejected
<BtbN>
author seems to love the Anime
<JEEB>
do note that they say that you can pay them for alternative themes
<thardin>
lol
<BtbN>
"Anubis is provided to the public for free in order to help advance the common good. In return, we ask (but not demand, these are words on the internet, not word of law) that you not remove the Anubis character from your deployment."
abdu86 has joined #ffmpeg-devel
<BtbN>
so yeah. Whyever they care about that character so much
<sfan5>
thardin: i think the cookie actually expires after a while. so expect to see it more often
<thardin>
it took like 20 seconds to run that nonsense
<JEEB>
BtbN: I think in one of the doc pages they do note that they are open for payment
<BtbN>
And then they'll fork it for us and change the logo? That's a bit silly.
<thardin>
forking? for changing an asset?
<thardin>
I guess that's what the kids call configuring a project to your liking these days
<JEEB>
right, it's the same page where you grabbed that quote from
<BtbN>
It explicitly does not have any way to configure it
<JEEB>
> If you want to run an unbranded or white-label version of Anubis, please contact Xe to arrange a contract. This is not meant to be "contact us" pricing, I am still evaluating the market for this solution and figuring out what makes sense.
<thardin>
if it's in the source code somewhere it can be changed
<JEEB>
yea, it is
<BtbN>
It's a violation of the license though
<BtbN>
For all I care the character image can stay, but add an FFmpeg logo as well. So it does not look like we got hacked.
<thardin>
so it's not free software?
<BtbN>
It's MIT licensed. So I guess license wise it's fine
<JEEB>
yea
<BtbN>
but I don't feel like forking and maintaining it, just to change a logo
<BtbN>
Which would also go against the express will of the original author
<JEEB>
just sad that it has to be what seems like a generated logo :P
<BtbN>
I'd almost say it's intentionally weird so you want to get rid of it :D
<BtbN>
but looking at the profile and other stuff of the author, I'm not so sure.
<JEEB>
it's partially that since they do offer the brand-changing service
<BtbN>
Well, it could be a "normal" default logo instead
<llyyr>
I mean, you can still change the character
<llyyr>
>Anubis is provided to the public for free in order to help advance the common good. In return, we ask (but not demand, these are words on the internet, not word of law) that you not remove the Anubis character from your deployment.
<sfan5>
I would totally think it's cute on a personal site, but even on an open-source project site seeing it is a "huh what?" moment
<thardin>
they're just three images under web/static/img
<JEEB>
sfan5: that was my first reaction to it on GNOME's gitlab
<sfan5>
so yeah it's probably intentional to some degree
<BtbN>
It's even designed in a way to be not easy to just override as the reverse proxy level
<BtbN>
the image uri is randomized each time
<psykose>
anime and ffmpeg is a perfect match
<llyyr>
eventually enough open source sites will use it that people will just get used to seeing it
<thardin>
wasn't there a proposal for an HTTP layer hashcash thing many moons ago?
<JEEB>
or someone figures out how to otherwise block that spam
<BtbN>
I know good old TeamSpeak has a hashcash-like system built into it
<thardin>
that way you could get rid of the js, and make it work with rss readers, wget and so on
<BtbN>
wget and rss readers will work with anubis at least
<JEEB>
yea as long as you don't have "mozilla" in user agent or so, it works
<thardin>
crawlers can just pretend to be wget. or use it outright. rss is a bit less useful, and rss is intended to be machine read anyway
<thardin>
plus rss can be served statically
<BtbN>
so far crawlers have not caught on. If/Once they do, it'll get more interesting.
<JEEB>
averne: cool, so you posted a patch :)
<thardin>
I get a rather modest amount of bots on my webzone. but it's also entirely static
Traneptora has joined #ffmpeg-devel
<thardin>
7515 unique IPs the last month or so
<BtbN>
I had to put it in front of code.ffmpeg.org already as well
<BtbN>
There were over 1000+ requests queued for running git blame on every file under the sun
<sfan5>
I suppose that's why gitlab makes you sign in to do that?
<BtbN>
yeah
<BtbN>
But if it's not blame, it'll just be the next most expensive thing they get stuck on
<thardin>
blame is notoriously expensive though
<sfan5>
maybe introducing a proof-of-work for action that actually take lots of server time would be a more sustainable solution
twelve has quit [Remote host closed the connection]
<thardin>
you'd think they'd make their crawler git aware and just download the code instead
<JEEB>
kasper93: I'll try to put some eyes on win32_thread_setname
<BtbN>
the crawler has no idea what it's even looking at
<BtbN>
It just clicks on every single link everywhere
<thardin>
evidently
<BtbN>
Kinda makes me want to build a crawler tarpit
<BtbN>
a procedurally generated maze of deeper and deeper links
<BtbN>
And all set up to artifally take forever to load
<JEEB>
yes, and then respond with 7kbps or something
<thardin>
that has already been done
<JEEB>
or a few bytes per sec
<thardin>
also look up slowloris
<BtbN>
Could combine it with a deflate-bomb
<sfan5>
> a procedurally generated maze of deeper and deeper links
<sfan5>
has been done already
<thardin>
bz2 is better bomb material
<thardin>
deflate caps out at 1:1023 compression ratio
<BtbN>
But browsers don't decompress bz2
<thardin>
zstd maybe?
<llyyr>
though maybe ffmpeg's anubis deployment could be configured to take few cpu cycles? it takes almost 5x longer than gnome's
<BtbN>
Or brotli or whatever
<BtbN>
It's on difficulty 5, "fast mode"
<BtbN>
which is the default
<llyyr>
oh
<sfan5>
the default was changed to 4 iirc
<thardin>
I'm on an 11 year old thinkpad you insensitive clod
<thardin>
(I jest)
<wbs>
jamrial: thanks for the second fix too! unfortunately it seems like it's not enough for macos/aarch64 at least; it still fails the ffv1 tests
<BtbN>
I can definitely lower it to 4, and see how it holds up
<kepstin>
as someone who uses an actual 11 year old thinkpad, gnome's settings are fine for me; you'd need a 22 year old thinkpad to have issues
abdu14 has joined #ffmpeg-devel
<kepstin>
(i have one of those too, it's not a good experience)
<sfan5>
note: 2014 was 11 years ago
<BtbN>
4 seems incredibly much faster
<thardin>
kepstin: I actually do use an 11 old thinkpad. t420
<thardin>
librebooted even
<BtbN>
open trac in a private tab to test the lower difficulty
abdu77 has joined #ffmpeg-devel
<kepstin>
t420's older than 11 years, my t440p is from 2014 right on :)
<BtbN>
A T510 was my first laptop, back in 2010
<BtbN>
I think it was the latest model then
<BtbN>
Somehow I remember it being snappier than my current P53
<thardin>
oh yeah, I see reviews from 2012
abdu86 has quit [Ping timeout: 240 seconds]
<thardin>
the local hackerspace used to run its website on a machine from like 2003. it eventually died in 2021
<jamrial>
wbs: there are other cases of excessive stack usage, so i guess those should also be dealt with
abdu14 has quit [Ping timeout: 240 seconds]
ccawley2011 has quit [Quit: Leaving]
<fflogger>
[newticket] bleak8197: Ticket #11528 ([ffplay] High sizzle problem when playing 5.6MHz DSD (.dsf) audio file) created https://trac.ffmpeg.org/ticket/11528