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
System_Error has quit [Remote host closed the connection]
derpydoo has joined #ffmpeg-devel
System_Error has joined #ffmpeg-devel
kepstin has quit [Remote host closed the connection]
kepstin has joined #ffmpeg-devel
cone-483 has quit [Quit: transmission timeout]
martinr1 has joined #ffmpeg-devel
martinr1 has quit [Read error: Connection reset by peer]
martinr1 has joined #ffmpeg-devel
martinr1 has quit [Read error: Connection reset by peer]
martinr1 has joined #ffmpeg-devel
martinr1 has quit [Read error: Connection reset by peer]
ccawley2011 has joined #ffmpeg-devel
Grimmauld has joined #ffmpeg-devel
ccawley2011 has quit [Ping timeout: 260 seconds]
ccawley2011 has joined #ffmpeg-devel
derpydoo has quit [Quit: derpydoo]
abdu10 has joined #ffmpeg-devel
zsoltiv__ has quit [Ping timeout: 252 seconds]
zsoltiv has quit [Ping timeout: 265 seconds]
ccawley2011 has quit [Ping timeout: 265 seconds]
IndecisiveTurtle has quit [Ping timeout: 244 seconds]
Mirarora has joined #ffmpeg-devel
^Neo has joined #ffmpeg-devel
^Neo has joined #ffmpeg-devel
ccawley2011 has joined #ffmpeg-devel
jamrial has joined #ffmpeg-devel
Anthony_ZO has joined #ffmpeg-devel
lexano has quit [Remote host closed the connection]
lexano has joined #ffmpeg-devel
cone-362 has joined #ffmpeg-devel
<cone-362>
ffmpeg Gyan Doshi master:64087171f67b: configure: add option to select use of response files
Anthony_ZO has quit [Ping timeout: 268 seconds]
<ramiro>
haasn: do you think SwsReadWriteOp could be changed to have a mask instead of the number of elements? conversions such as xv48be -> ya16be wouldn't have to read everything.
<haasn>
Interesting idea
<haasn>
Specifically, a mask on *write*
<haasn>
That could propagate as an unused component and eventually reach the read
<haasn>
Actually, this info already propagates; so the components should be marked unused
<ramiro>
oh, cool. I guess I should change my code to use that then.
<haasn>
Make sure to check next->comps.unused[]
<haasn>
something on my todo list is to add a SWS_COMP_UNMODIFIED flag (or w/e)
<haasn>
to detect passthough cases
<haasn>
when we have a planar->planar passthrough we could omit those planes entirely (and eventually promote them to a refcopy)
<ramiro>
wbs: I've been told that it might be faster to read using ld1 and then use tbl to unpack the data into individual registers instead of using ld3, especially on newer apple silicon. it seems odd to me that the hardware itself wouldn't make this optimization internally. what do you know about this?
<haasn>
on a side note I still really need to implement packed reads on x86, that's like my #1 todo thing to actually start pulling some interesting numbers
zsoltiv has joined #ffmpeg-devel
<haasn>
since that will be the make-or-break for the approach (vs dedicated packed swizzle functions)
<ramiro>
haasn: I've been thinking a bit about refcopy. shouldn't this be something done outside of sws_scale_frame()? I mean, if the user calls sws_scale_frame() with a src and dst, they might have allocated the memory themselves and would want even a memcpy instead of a refcopy.
<haasn>
ramiro: well the idea here is that you should leave the dst unallocated unless you specifically want a copy
<haasn>
Ultimately though it comes down to the fact that we want to handle refcopy on a per-plane basis when possible
<haasn>
So I made the API create the refs internally to open up that possibility eventually
<haasn>
Can AVFrame actually handle data ptr aliasing?
<haasn>
e.g. gbrp where each data[0] = data[1] = data[2] uses the same buffetref
<Lynne>
sure
<mkver>
haasn: Sure. But notice that you should add multiple references in AVFrame, so that the planes are not considered writable.
<haasn>
Oh, right, that makes sense
zsoltiv_ has joined #ffmpeg-devel
<haasn>
There’s also the implied 1:1 correspondence between buf and data
<Lynne>
nope
<Lynne>
we allocate by default every plane in a single bufferref
<Lynne>
*all planes
<mkver>
Lynne: lavc/get_buffer.c uses a different buffer (even different pools) for each plane.
<Lynne>
lavu's alloc uses a single one IIRC
<jamrial>
haasn: there's no correlation, so you can't assume a given buffer backs a given plane pointer
<jamrial>
you can have one or more bufs present for all four planes (eight for audio, then more in extended_*)
<jamrial>
the only requisite afaik is that buf[n] can't be NULL if buf[n+1] is not NULL
<haasn>
So what’s the strategy? Find the matching buffer by checking the start / length against the data pointer?
<jamrial>
no, bufferef could have arbitrary stuff like some struct pointer from some external library backing the plane data
<haasn>
Is it even possible to do a partial refcopy then
<haasn>
In the general case
<mkver>
av_frame_get_plane_buffer() casts to uintptr_t and compares.
<jamrial>
that sounds fragile
<mkver>
jamrial: But even then AVBufferRef.data needs to point to something containing the actual buffer.
<mkver>
It is actually not guaranteed to work by ISO C.
abdu1 has joined #ffmpeg-devel
abdu10 has quit [Ping timeout: 240 seconds]
<cone-362>
ffmpeg Tristan Matthews master:c14b837dedad: speexdec: fix framesize for ultra-wideband
<grillo_0>
oh, thanks! This link was on there, or I just have to know that this is the link format for ticket related videolan uploads?
<mkver>
You have to know it.
<compnn>
its where our incoming ftp uploads go yes
ccawley2011 has quit [Ping timeout: 246 seconds]
Traneptora has joined #ffmpeg-devel
ccawley2011 has joined #ffmpeg-devel
<grillo_0>
I see, thx
abdu1 has quit [Quit: Client closed]
<ramiro>
haasn: could we make swscale-test use legacy swscale for the auxiliary conversions? ideally I'd like to have only one conversion being done by the new code, and not the conversions to/from yuva444p
minimal has joined #ffmpeg-devel
<haasn>
sure, I toggle that locally every now and then
<haasn>
I think I will make the new code opt-in for now in any case
<haasn>
SWS_EXPERIMENTAL or sth
markh has joined #ffmpeg-devel
ccawley2011 has quit [Ping timeout: 248 seconds]
___nick___ has quit [Ping timeout: 244 seconds]
___nick___ has joined #ffmpeg-devel
HarshK23 has quit [Quit: Connection closed for inactivity]
<wbs>
ramiro: it may very well be possible, but I don't think the difference is very big... on older cores, instructions like TBL are quite expensive, while they're a bit faster on newer ones. overall I'd stick with what's reasonable/intuitive on older cores. it's perhaps not optimal on all cores but should be reasonable. (the other way around is usually more drastically slow on the wrong generation of cores)
<qwertyttyert>
Is there anything new in this version libtheora:_1.2.0alpha1+git after 2010? Or is this version "Preview release 1.2.0 Alpha 1 / September 24, 2010" unchanged? There is information that Xiph.Org presented a new edition of the free codec Theora 1.2. ffmpeg have libtheora:_1.2.0alpha1+git
<another|>
Check the log?
<qwertyttyert>
ffmpeg 7.0.2 have libtheora:_1.2.0alpha1+git
<JEEB>
that's not FFmpeg, that's whatever packaging system you're utilizing
Mirarora has quit [Quit: Mirarora encountered a fatal error and needs to close]
<mkver>
Reminds me that I wanted to finally fix multithreaded stream reconfigurations in vp3/theora.
<qwertyttyert>
ffmpeg does not have version 1.2.0?
<JEEB>
FFmpeg is FFmpeg, theora is theora. whatever packaged versions you are seeing have nothing to do with FFmpeg but your package manager
<another|>
This has nothing to do with ffmpeg and certainly not in #ffmpeg-devel
<qwertyttyert>
"FFmpeg is FFmpeg, theora is theora. whatever packaged versions you are seeing have nothing to do with FFmpeg but your package manager" not all FFmpeg -Windows
<JEEB>
У нас ничего общего с той системой софта нет. Please stop, you're not discussing anything related to FFmpeg, never mind internals :P
abdu88 has joined #ffmpeg-devel
abdu54 has joined #ffmpeg-devel
ccawley2011_ has joined #ffmpeg-devel
abdu5 has joined #ffmpeg-devel
abdu83 has quit [Ping timeout: 240 seconds]
ccawley2011__ has joined #ffmpeg-devel
ccawley2011 has quit [Ping timeout: 246 seconds]
abdu88 has quit [Ping timeout: 240 seconds]
ccawley2011 has joined #ffmpeg-devel
abdu54 has quit [Ping timeout: 240 seconds]
rvalue- has joined #ffmpeg-devel
ccawley2011_ has quit [Ping timeout: 260 seconds]
rvalue has quit [Ping timeout: 252 seconds]
ccawley2011__ has quit [Ping timeout: 248 seconds]
ccawley2011 has quit [Ping timeout: 260 seconds]
<qwertyttyert>
not all FFmpeg - Windows and not only Windows
<qwertyttyert>
ok
<qwertyttyert>
ffmpeg 7.0.2 have libtheora:_1.2.0alpha1+git "Preview release 1.2.0 Alpha 1 / September 24, 2010?
rvalue- is now known as rvalue
<BtbN>
again, FFmpeg does not have _anything_
<BtbN>
Someone built that version, and used whatever other libraries they saw ffit
Mirarora has joined #ffmpeg-devel
<ramiro>
haasn:I haven't looked into your checkasm code yet. good thing that it wraps the read/write operations. I'll have a look at some point
ccawley2011 has joined #ffmpeg-devel
<ramiro>
haasn: another thing. on the linear operation for rgb24 -> gray, the first 3 components are marked as !unused. I usually check that to perform the operations on. but apparently that flag is set even if the element is just being used (and not written to). how should I tell that apart?
<another|>
you're barking up the wrong tree in the wrong channel
Grimmauld has quit [Ping timeout: 240 seconds]
arch1t3cht has quit [Client Quit]
arch1t3cht has joined #ffmpeg-devel
cone-384 has joined #ffmpeg-devel
<cone-384>
ffmpeg Andreas Rheinhardt master:948a78365b1b: avcodec/dxa: Remove set-but-unused variable
<compnn>
i mean those are BtbN's builds
<compnn>
hehe /s
<compnn>
oh no i misread ignore me
<qwertyttyert>
Theora 1.2 - I doubt it will be better for me than x264 for arm32. Am I writing correctly where I need to write. ffmpeg 7.0.2 have libtheora:_1.2.0alpha1+git "Preview release 1.2.0 Alpha 1 / September 24, 2010 It seems to be the same thing.
<BtbN>
not gonna repeat the same info again
microlappy has joined #ffmpeg-devel
qwertyttyert has left #ffmpeg-devel [#ffmpeg-devel]
___nick___ has quit [Ping timeout: 248 seconds]
microlappy has quit [Quit: Konversation terminated!]
microlappy has joined #ffmpeg-devel
<haasn>
ramiro: op->comps.unused[i] means this operation does not *read* from component i
<haasn>
you might be looking for op[1].comps.unused[i]
<haasn>
usually it's more interesting to look at next->comps.unused than op->comps.unused
<ramiro>
haasn: good idea checking next->comps.unused. I'll try it later. I ended up writing some code that optimized away more identity operations and while doing that I checked if the output was used instead.
kasper93 has quit [Quit: kasper93]
Grimmauld11 has quit [Quit: Client closed]
kasper93 has joined #ffmpeg-devel
Grimmauld has joined #ffmpeg-devel
microlappy has quit [Quit: Konversation terminated!]
<haasn>
ramiro: for linear ops, can’t you just loop over the full matrix in C, and emit the correct subset of vector ops automatically?
<haasn>
Or do you not have enough spare rega
Mirarora has quit [Quit: Mirarora encountered a fatal error and needs to close]
mkver has quit [Remote host closed the connection]
abdu94 has joined #ffmpeg-devel
abdu5 has quit [Ping timeout: 240 seconds]
<ramiro>
haasn: I do, but I wanted to optimize away identity operations. at first I was emitting multiplication by 1. newer arm cores have a fastpath for multiply-accumulate, so if one of the coefficients is 1, it was still faster to emit a multiplication
<ramiro>
but if the only element that multiplies by 1 is the value itself, then I can just rename the register instead, and that's where I was missing an optimization
<haasn>
right, that makes sense
<haasn>
for x86 I was thinking of splitting up linear ops into the matrix multiplication and the addition portion
<haasn>
to reduce the number of cases
<haasn>
(as separate kernels)
Mirarora has joined #ffmpeg-devel
<ramiro>
haasn: in asmjit I now have one single function for all linear ops which seems to take care of all cases as fast and small as each can be. it's actually pretty impressive how powerful this new architecture is...
<ramiro>
haasn: I'm having an issue when using legacy swscale for the auxiliary conversions with this command: ./libswscale/tests/swscale -unscaled 1 -src yuva444p -dst yuv444p
<ramiro>
I get yuva444p 96x96 -> yuv444p 96x 96, flags=0 dither=1, SSIM {Y=1.000000 U=1.000000 V=1.000000 A=0.571399} loss 0.428601 is WORSE by 0.428583, expected loss 1.8239e-05
<ramiro>
and I can't pinpoint why this is happening... I can reproduce this is directly on your swscale5 branch, with no asmjit code (but with the legacy flag set like you wrote before).
kasper93 has quit [Quit: kasper93]
kasper93 has joined #ffmpeg-devel
Grimmauld has quit [Quit: Client closed]
abdu4 has joined #ffmpeg-devel
<haasn>
Is that one a bug in actual swscale? Surely not?
abdu94 has quit [Ping timeout: 240 seconds]
<haasn>
Seems legacy sws is not writing 0xFF to alpha
<ramiro>
there's another alpha-related bug on x86 (it works with -cpuflags 0) when running: ./libswscale/tests/swscale -unscaled 1 -src xyz12le -dst gbrap12be
<ramiro>
but I gave up trying to figure out what causes it, since it works on aarch64.
<haasn>
I suddenly remember why I made swscale.c use the new code by default :)
<haasn>
old swscale just has so many bugs uncovered by this test
<haasn>
now that we actually test against the expected loss rather than just finding regressions
<haasn>
checkasm is part of FATE runs right?
<ramiro>
haasn: yes, checkasm is part of fate runs