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 has been released! | Please read ffmpeg.org/developer.html#Code-of-conduct
Marth64 has joined #ffmpeg-devel
System_Error has quit [Remote host closed the connection]
System_Error has joined #ffmpeg-devel
System_Error has quit [Remote host closed the connection]
System_Error has joined #ffmpeg-devel
Traneptora has joined #ffmpeg-devel
cone-548 has quit [Quit: transmission timeout]
kasper93_ has quit [Ping timeout: 252 seconds]
thilo has quit [Ping timeout: 264 seconds]
thilo has joined #ffmpeg-devel
thilo has quit [Changing host]
thilo has joined #ffmpeg-devel
System_Error has quit [Remote host closed the connection]
Marth64 has quit [Quit: Leaving]
System_Error has joined #ffmpeg-devel
<another|>
jamrial_: Thanks for your effort to stay professional on the ML. :)
Marth64 has joined #ffmpeg-devel
realies has quit [Quit: ~]
mkver has quit [Ping timeout: 252 seconds]
^Neo has quit [Ping timeout: 260 seconds]
kasper93 has joined #ffmpeg-devel
Marth64 has quit [Quit: Leaving]
jamrial_ has quit []
^Neo has joined #ffmpeg-devel
^Neo has quit [Changing host]
^Neo has joined #ffmpeg-devel
^Neo has quit [Ping timeout: 252 seconds]
realies has joined #ffmpeg-devel
System_Error has quit [Remote host closed the connection]
System_Error has joined #ffmpeg-devel
Martchus has joined #ffmpeg-devel
Martchus_ has quit [Ping timeout: 248 seconds]
Quackdoc has joined #ffmpeg-devel
Quackdoc has quit [Quit: Client closed]
Quackdoc has joined #ffmpeg-devel
blb has quit [Ping timeout: 246 seconds]
blb has joined #ffmpeg-devel
System_Error has quit [Remote host closed the connection]
HarshK23 has joined #ffmpeg-devel
Quackdoc has quit [Ping timeout: 240 seconds]
rvalue has quit [Read error: Connection reset by peer]
rvalue has joined #ffmpeg-devel
Quackdoc has joined #ffmpeg-devel
secondcreek has quit [Remote host closed the connection]
secondcreek has joined #ffmpeg-devel
thesynthax has joined #ffmpeg-devel
<JEEB>
michaelni: regarding 54897da7ce8ae6e349cd56d0f11cb2404e264efa , have people really utilized m4s for mpeg-ts and not fmp4? I think that's the example extension for fragmented mp4 with fmp4 HLS (which is required for newer video formats in HLS by Apple)
<Lynne>
if it sounds horrible; yes, people have used it
<JEEB>
I just wonder if somewhere along the road there was a thought of "HLS always equals MPEG-TS"
System_Error has quit [Remote host closed the connection]
System_Error has joined #ffmpeg-devel
<nevcairiel>
the extension check for hls feels like a bad kludge anyway, streaming URLs will often just be some random URL with no readable extension, if something should be restricted, it should be format, not extension
<nevcairiel>
(also mpegts has a long list of other extensions used in the world)
ccawley2011 has joined #ffmpeg-devel
abdu has joined #ffmpeg-devel
ccawley2011_ has joined #ffmpeg-devel
ccawley2011 has quit [Ping timeout: 246 seconds]
ccawley2011 has joined #ffmpeg-devel
ccawley2011_ has quit [Ping timeout: 248 seconds]
ccawley2011_ has joined #ffmpeg-devel
rvalue- has joined #ffmpeg-devel
rvalue has quit [Ping timeout: 276 seconds]
ccawley2011 has quit [Ping timeout: 252 seconds]
^Neo has joined #ffmpeg-devel
^Neo has joined #ffmpeg-devel
^Neo has quit [Changing host]
rvalue- is now known as rvalue
System_Error has quit [Remote host closed the connection]
jamrial has joined #ffmpeg-devel
System_Error has joined #ffmpeg-devel
ccawley2011 has joined #ffmpeg-devel
ccawley2011__ has joined #ffmpeg-devel
ccawley2011_ has quit [Ping timeout: 246 seconds]
ccawley2011 has quit [Ping timeout: 252 seconds]
IndecisiveTurtle has quit [Quit: IndecisiveTurtle]
ccawley2011 has joined #ffmpeg-devel
ccawley2011_ has joined #ffmpeg-devel
ccawley2011__ has quit [Ping timeout: 260 seconds]
ccawley2011 has quit [Ping timeout: 248 seconds]
abdu has quit [Quit: Client closed]
abdu has joined #ffmpeg-devel
omegatron has joined #ffmpeg-devel
Everything has joined #ffmpeg-devel
<BtbN>
There is already two signups on code.ffmpeg.org which I can't immediately connect to anyone from here. If you are one of those account, just speak up and I'll activate it.
<Lynne>
wow, nice
<Lynne>
thanks for hosting it
<Lynne>
(I probably would have become stuck on configuring apache which we still use, rather than nginx)
<BtbN>
This is using neither apache nor nginx :D
ccawley2011_ has quit [Ping timeout: 246 seconds]
<Lynne>
could you activate my account?
ccawley2011_ has joined #ffmpeg-devel
<kierank>
jamrial: can you explain whatt AV_FRAME_DATA_PARAM_CHANGE is for
<BtbN>
done
<Lynne>
thanks, going to dig up old spicy patches to test MRs
<Lynne>
what does it use, if not apache nor nginx? some new rust framework I haven't heard of?
<BtbN>
Caddy
<kierank>
lol
<kierank>
always the most jank thing
<BtbN>
"code.ffmpeg.org { reverse_proxy forgejo:3000 }" is literally the entire config.
<BtbN>
Not sure what's "Jank" about Caddy.
<Lynne>
I've heard about it once
<Lynne>
nothing bad
<kierank>
for a project of ffmpeg's longevity we should seriously think about well supported things
<BtbN>
It's a pretty common and well established reverse proxy. Not sure what you're on about.
<BtbN>
It's also the by far easiest thing to replace if it somehow vanished.
<kierank>
so much contrarianism
<kierank>
forejo was a fork for oss purity reasons
<kierank>
the third ? fork
<BtbN>
I feel like we could set up whatever and you'd still be unhappy...
<kierank>
gitlab
<BtbN>
Now even a random reverse proxy isn't good enough
<kierank>
"random reverse proxy" qed
RapidLeader has joined #ffmpeg-devel
<BtbN>
Its whole job is to terminate https. ANYTHING can do that
<BtbN>
Apache, Nginx, Traefik, Caddy, ...
<kierank>
that's not the point, this stuff needs to be maintainable
<kierank>
in 10 years
<kierank>
and we've seen in this project that's not the case
<BtbN>
I can replace the reverse proxy in like half an hour or less.
<kierank>
sigh
<BtbN>
It's the by far least critical part of the entire thing
<kierank>
surely it's best we use gitlab like other OSS multimedia projects so that the knowledge can cross polinate
<kierank>
instead of doing our own weird thing for contrarianism
<RapidLeader>
gitlab is evil
<kierank>
RapidLeader: hi
<kierank>
how are you today
<kierank>
you always brighten my day with your names
<RapidLeader>
speed & power
<jamrial>
kierank: isn't an entire linux distro using forgejo?
<kierank>
jamrial: they have proposed to move
<BtbN>
I have no idea why you think so lowly about forgejo. It's pretty well established at this point, and not some random thing only we use.
<kierank>
because at work we used gogs (at small scale), it became gitea, now it's forjego purely on oss purity
<BtbN>
It's not like they forked last week. Been years now, and development seems healthy.
<kierank>
it's not as sophisticated as gitlab
<kierank>
and there is value in using tools that other members of the community (e.g videolan, dav1d) use
<kierank>
and have had success developing similar projects (e.g CI)
<BtbN>
Happy to run Gitlab instead if Forgejo fails the test and Gitlab is voted for
<kierank>
they have checkasm like us and something similar to FATE
<kierank>
errr
<BtbN>
And that can't run on Forgejo because...?
<kierank>
forgejo wasn't voted
<BtbN>
Read the E-Mail threads
<kierank>
???
<BtbN>
it's a test. We test, then vote.
<kierank>
so forejo is ok without vote, but gitlab needs a vote?
<kierank>
wtf
<jamrial>
no
<jamrial>
we're testing one option right now
<RapidLeader>
the Leader approves only forgejo, and nothing else
<jamrial>
we can test the other if you want later
<RapidLeader>
its just demo
<kierank>
RapidLeader: let's be honest the Leader will approve forgejo purely because videolan isn't using it
<BtbN>
Gitlab is also quite a bit more common, and people know how it works. Which can't be said about Forgejo.
<RapidLeader>
but gitlab is actuall company
<BtbN>
Really no idea what kind of conspiracy you are spinning there, but I'm done discussing it.
<BtbN>
When Gitlab was proposed, people talked shit against it endlessly
<BtbN>
Now something else is set up, and other people talk shit against it endlessly
<BtbN>
We're never going to get anywhere like this
<RapidLeader>
nothing is perfect, just pick something that is lightweight and fast and powerful
<kierank>
RapidLeader: lol
<kierank>
pick two
<jamrial>
this forgejo instance is certainly faster than the videolan's gitlab instance
<kierank>
it has no issues
<kierank>
and two users
<BtbN>
Yeah, the speed of it will need to be judged once it's under real world load
<jamrial>
i'm talking about clicking the "commits" link and waiting much longer to get a list of commits
<BtbN>
Though generally Forgejo is going to outperform Gitlab easily
<abdu>
Hello guys, I'm just curious but what was the problem with simply sending a PR in github? I see that for sometime there were PRs in the repo (383 Closed)
<BtbN>
Github is just a mirror
<BtbN>
merging a PR there would get instantly overwritten by the mirror scripts.
<Lynne>
what I like about it is that it instantly loads diffs, while gitlab takes years
<kierank>
abdu: github isn't open source
<jamrial>
the github repo is a mirror, and we're not going to host our main repo there
<BtbN>
That's 383 PRs by people who did not read the multiple warning about PRs not being accepted.
<abdu>
kierank BtbN Ok, I got it. thanks
<RapidLeader>
is codeberg open source? is it gitlab?
<BtbN>
Codeberg is Forgejo
<RapidLeader>
cool, i pick forgejo
<Lynne>
since viewing diffs is what you mostly do, I find that speed there matters most
<BtbN>
This is hosted on a less than 10€ a month Hetzner Cloud setup btw.
<JEEB>
yea the actual costs would probably come from CI runners
<BtbN>
Will probably need to scale up, specially with CI runners
RapidLeader has quit [Quit: Client closed]
<BtbN>
But even that will not be THAT crazy
<jamrial>
kierank: and re param_change, it's for callers to signal the encoder that some parameters need to change
<BtbN>
Need to cook up a setup that shuts the runners down when idle
<kierank>
videolan has these setup already for dav1d
<jamrial>
mainly, i want to pass a dictionary of private encoder avoptions for greaceful reconfigure/reinit
RapidLeader has joined #ffmpeg-devel
<jamrial>
see the x264 and aom patches in the set, where i use the API those libraries provide to change encoding params
<kierank>
I understand why you're doing it because ffmpeg has nothing else, but side data imo should not be (ab)used for signalling
<kierank>
not that there is another way
<RapidLeader>
FF* have enough coins to pay for all costs on monthly basis
<kierank>
RapidLeader: but who will sysadmin? Leader?
<RapidLeader>
Leader is already busy with extremely long TODO list
<kierank>
RapidLeader: anyway this reminds me when x265 used mercurial to be contrarian against git
<kierank>
and then lots of places stopped supporting it
<Lynne>
you do realize that you can update gogs all the way to forgejo?
<kierank>
having spent ages upgrading gogs to gitea I am well aware
<Lynne>
well, there you go, if fork number 3 dies, off to fork number 4
<kierank>
if it forks in two directions what do you do
<kierank>
pick one and be screwed later
<Lynne>
nah, there are migrations
<kierank>
lol
<kierank>
instead we could have gitlab, with an actual sysadmin who knows it like vlc
<kierank>
actual known good configurations used in dav1d
<Lynne>
it is quite slow though, that's my main complaint
<kierank>
it's a lot faster than before
<kierank>
and who's to say forejo won't get that slow under load
<Lynne>
because other large projects on busier instances are running as smoothly as ours
<kierank>
Also nobody is going to like this, but foregjo whatever is going to scare off contributors as it's a weird name
<Lynne>
so it github when you think about it
<kierank>
if you need to learn how to pronounce it, it's a dumb name
<kierank>
let alone spell it
<Lynne>
you're not spelling the name every time you have to register to our instance, let alone care about what it runs
<JEEB>
kierank: for our docs it'd just be code.ffmpeg.org or whatever, the user doesn't have to care what exactly it is as long as the UI is good enough. be that gitlab or forgejo
<kierank>
if not called FFmpeg Forgejo yes
ccawley2011_ has joined #ffmpeg-devel
<JEEB>
the biggest obstacle usually is requiring yet another set of credentials
<thardin>
what color shall we paint the bikeshed?
<JEEB>
thardin: bright red with speed stripes!
<kierank>
gitlab is the obvious choie
<Lynne>
it was when it was the only choice
<kierank>
but instead we need some weird contrarian third fork thing
<BBB>
thardin: definitely red, yes
<kierank>
other multimedia projects with similar needs to us already use gitlab
<kierank>
and it works
<Lynne>
its slow
<JEEB>
pretty sure a vote was proposed and can be done, as I think anyone can initialize a private vote (aka vote with X amount of voters for the GA)
<Lynne>
and the gitlab devs are not exactly the people you'd like to maintain the crucial piece of software
<thardin>
I ran a gitlab instance at uni. it was awful
<BBB>
I've merged patches from the ML. it's awful
<kierank>
BBB: :)
<thardin>
it's a huge beast. probably overkill for this project
<BBB>
life sucks and then I die
<kierank>
thardin: we have complex CI requirements
<thardin>
true
ccawley2011 has quit [Ping timeout: 252 seconds]
<BBB>
good luck discussing guys. I'm getting deja vus
<BBB>
I really hope one dy we'll figure out captain obvious
<JEEB>
:)
<BBB>
*day
<thardin>
more concretely, I recall gitlab being unstable and needing regular restarts for no good reason
<JEEB>
I've not heard that from videolan or the other smaller projects that run it
<BtbN>
Yeah, from an Admin-Perspective, I heavily prefer Forgejo/Gitea
<Lynne>
BtbN: if its not too much trouble, could you setup email for the instance?
<thardin>
it also requires jabbascript on the frontend
<BtbN>
It can already send E-Mail?
<thardin>
a big no imo
<BtbN>
At least it's happily mailing me.
<Lynne>
I got nothing when I sent a verification mail
<BtbN>
It's sending them via the ffmpeg.org mail server, as code@ffmpeg.org
<thardin>
it's essentially a big fu to blind people
<BtbN>
I'm getting them fine
<Lynne>
I'll resent and see if my server gets it
<BtbN>
My mail-server initially decided to graylist them
<BtbN>
so it took half an hour initially, and then it was fine
<BtbN>
I got a mail for your PR at least
<kierank>
Lynne: so a random bunch of people who forked three times are better?
mkver has joined #ffmpeg-devel
<kierank>
The last time out of pure intellectual purity
<nevcairiel>
whats a company but a random bunch of people?
<kierank>
there's a bigger body of support for it
<RapidLeader>
people's company of FFmpeg
<Lynne>
kierank: as far as I understand, the company the original founder of gittea formed was sold, and forced its decisions on the dev team, who left and forked the project off
<Lynne>
its still the same devs, but they just got in a bad situation
<RapidLeader>
is there at least fast and solid way to transform from forgejo to gitlab and vice-versa?
ccawley2011__ has quit [Ping timeout: 248 seconds]
<haasn>
jamrial: done
cone-533 has joined #ffmpeg-devel
<cone-533>
ffmpeg James Almer master:abdc20727c22: swscale/swscale: combine the input/output checks in sws_frame_setup()
<cone-533>
ffmpeg James Almer master:e20ee9f9aec9: swscale/swscale: don't reject scaling when color parameters are not supported but conversion is not required
Marth64 has joined #ffmpeg-devel
<RapidLeader>
haasn: do you use file templates or macros for swscale2 ?
<haasn>
RapidLeader: both
<haasn>
I'm not sure I understand the question
<haasn>
file templates for different bit depths
<haasn>
but macros to generate specialized functions
<RapidLeader>
i use macros for one-liners, file templates for rest
<RapidLeader>
because when i get error inside macro i'm blind
<haasn>
well so far I am trying to avoid macros as much as possible
<haasn>
mostly just because they're a royal pain to write and my editor does not have good support for them..
<RapidLeader>
:)
abdu has quit [Quit: Client closed]
abdu has joined #ffmpeg-devel
<haasn>
so far the worst cases seem to have about 30% slowdown
<haasn>
that's comparing the new _general_ path against the old specialized path
<haasn>
(this is on the example of yuv444p -> yuv444p10)
abdu has quit [Quit: Client closed]
abdu has joined #ffmpeg-devel
ccawley2011_ has joined #ffmpeg-devel
<RapidLeader>
more reasons to get free coders for new specialized paths
ccawley2011__ has joined #ffmpeg-devel
<haasn>
well
<haasn>
I declared the variable differently and now the code is magically 50% faster than swscale
<haasn>
I conclude black magic
<haasn>
I admit already, getting _consistent_ performance numbers from this approach is a massive PITA
<haasn>
and ultimately why dedicated asm will win in the end
<haasn>
but my goal for now is to cover the most ground with the least amount of code
ccawley2011 has quit [Ping timeout: 248 seconds]
ccawley2011_ has quit [Ping timeout: 248 seconds]
<ePirat>
BtbN, registered with username ePirat
<BtbN>
activated
<RapidLeader>
haasn: show me what you changed in generic path to get 50% faster than specialized swscale?
<haasn>
RapidLeader: the basic idea is to define a type chunk_t { uint8_t u8[32] }
<haasn>
and then to make all functions only input and output chunk_t
<haasn>
this allows the compiler to translate them into very tight SIMD operations under the hood
<RapidLeader>
yea, idea is to do baby steps for compiler to understand code better so SIMD is done for "free"
<haasn>
then you loop over the input image in fixed size chunks with a special handling for the edge
<haasn>
if you also pre-pad the input you could make it even faster in theory
<haasn>
... or just force the final function to be inlined also
<haasn>
hell now it's almost 3x faster than swscale for yuv444p -> yuv444p10le
<haasn>
by some miracle
<haasn>
let me just make sure it's still actually doing the right thing
<haasn>
I also use pointers to temporary chunk_t variables on the stack so that we get swizzles for free
<haasn>
e.g. swizzle() is a no-op after compilation
<haasn>
but from the point of the view of the programmer, these are all individual atomic steps
<RapidLeader>
i'm very amazed by the current progress! is there WIP code/branch to try?
<JEEB>
yea, haasn has been doing good stuff with swscale :)
<RapidLeader>
well its no longer swscale, its swscale_ng
RapidLeader has quit [Quit: Client closed]
RapidLeader has joined #ffmpeg-devel
<JEEB>
I'd be much less worried about touching swscale now
<JEEB>
previously I wouldn't even know if it was touching just matrix coeffs or primaries or both
<JEEB>
(I would have expected it to only know about matrix coeffs)
<RapidLeader>
i still do not believe haasn anything, i need to look at actual code to believe it. If new swscale beats zscale/zimg that will be major news on TV
<RapidLeader>
haasn should make sure to turn GPU off when developing CPU code
LainExperiments has joined #ffmpeg-devel
<BtbN>
transpiling swscale to GPU code sounds like a good plan
<haasn>
RapidLeader: you're welcome to help test, code is too WIP to be of much use for now though
<haasn>
anyway, I will publish this in a more accessible form once I have it hooked up to SwsGraph :)
<haasn>
for now, just to show what I'm working on and to prove that it's faster (it least on my aging zen v1 machine)
<RapidLeader>
its very compact code
<haasn>
BtbN: well the idea for now is that ff_sws_op_compile() has a signature general enough that you could invoke a GPU kernel under the hood
<BtbN>
if swscale can eat CUDA frames, that'd work fine as well
<haasn>
yes, and templated to avoid repetition between 8 and 16 bit depth
<haasn>
BtbN: you could invoke a GPU kernel even on CPU data
<haasn>
to be clear
<haasn>
I will probably work on this at some point
<BtbN>
well, that'd need to be uploaded first
<BtbN>
for which we already have filters
<haasn>
no, GPU can DMA
<haasn>
I tested this design for dav1d-gpu and it was working very well
<RapidLeader>
how you test for visual check?
<haasn>
(the poor performance of the AV1 GPU kernels notwithstanding)
<haasn>
RapidLeader: gdb :)
<haasn>
It's nowhere near ready
<haasn>
BtbN: so you can import the CPU pointers as host-allocated foreign memory and then read/write to it from a compute shader
<haasn>
at least in vulkan land
<RapidLeader>
just to the basic connection so i can enjoy in visuals watching test pattern animations...
<BtbN>
haasn: when CUDA is in uvm mode, it works the same. a CUdevptr is identical to a void* then
<BtbN>
But it's obviously still a lot faster to have the data actually reside in VRAM
ccawley2011__ has quit [Ping timeout: 252 seconds]
<BtbN>
specially if you do a full hw processing chain
<haasn>
for a convolution, perhaps
<haasn>
but for in/out it's completely fine
<haasn>
PCIe is _not_ the bottleneck
<haasn>
with the design I'm targetting, the first stage will always be an input normalization pass
<haasn>
if you look it the header file I uploaded, ff_sws_op_compile takes an arbitrarily long list of SwsOp, which will typically look something like: { SWS_READ_BYTES, SWS_SWIZZLE, SWS_EXPAND, SWS_MATRIX_3X3, SWS_WRITE_TMP, SWS_FILTER_H, SWS_WRITE_TMP, SWS_FILTER_V, ..., SWS_COMPRESS, SWS_SWIZZLE, SWS_WRITE_BYTES }
<haasn>
and for the basic C code, we will have a long array of known primitives targeting fixed cases
<haasn>
for example, we can have a single primitive dedicated to { SWS_READ_BYTES, SWS_SWIZZLE, SWS_EXPAND, SWS_MATRIX_3X3 }
<haasn>
which would be the fast path for yuv input
<haasn>
this design gives us the full flexibility to decide how granular our functions need to be in the end, for performance
<haasn>
could mix and match asm and C as well
<haasn>
or even GPU code
<haasn>
but for a pure GPU backend, I would see it as ultimately compiling this entire SwsOp chain into a single shader (or a sequence of shaders when filtering is involved)
<haasn>
SWS_READ/WRITE_BYTES can directly access host RAM
<RapidLeader>
amazing!
<haasn>
while SWS_WRITE_TMP and SWS_FILTER_* would obviously go through temporary VRAM
<BtbN>
I'd actually expect the RAM to be a bottleneck
<BtbN>
Cause GDDR is quite a bit faster than DDR
<haasn>
BtbN: but you have that bottleneck one way or the other
<BtbN>
do you?
<haasn>
unless you're talking about input frames that are already in VRAM
<BtbN>
I'm talking about copying to VRAM once, then applying multiple filters to it, and then either copying it back or giving it to a hwenc straight from VRAM
<haasn>
but in this case I think you would need a special op like SWS_MAP_BYTES_FROM_VRAM
<haasn>
multiple libavfilters? or multiple filters in the context of swscale?
<BtbN>
avfilters
<haasn>
right, that's a different case then
<haasn>
I was just talking about using GPU to speed up CPU swscale
<haasn>
but anyway, that's not impossible either, just would require a special input op type to take data directly from vram instead of a pointer
<BtbN>
At least the Nvidia driver will under the hood copy the data to VRAM anyway if you access a CPU pointer via uvm
<haasn>
anyway, GPU support is just something in the back of my mind for now
* haasn
-> break
<BtbN>
On an unrelated note, fucking trac is near unreachable again cause of intense bot traffic -_-
Everything has quit [Ping timeout: 252 seconds]
ngaullier has joined #ffmpeg-devel
ngaullier has quit [Remote host closed the connection]
ccawley2011__ has quit [Ping timeout: 245 seconds]
ulvertys has quit [Quit: Client closed]
Guest69 has joined #ffmpeg-devel
Guest69 is now known as mrnobody
mrnobody is now known as kpil_nobody
kierank has left #ffmpeg-devel [#ffmpeg-devel]
kpil_nobody has quit [Quit: Client closed]
<ePirat>
wbs, should d2096679d5b5d76a167d038a3a2aa570e4ce37f3 be backported?
<RapidLeader>
inspired by haasn WIP swscale code, i gonna write vf_pf2pf.c filter, which will convert one pixel format to another, all unscaled, dunno if that will give any useful outcome, but I like adventures into the unknowns
<haasn>
RapidLeader: seems redundant with swscale_ng
<haasn>
But if you can come up with a faster design and share it, I’d be happy :)
<RapidLeader>
but this is librempeg, where everything is converted into filters
<RapidLeader>
do not worry, swresample "clone" af_asf2sf converts any sample format to any sample format, that is 6x6 = 36 paths, and that takes seconds to compile with all template code, the vf_pf2pf.c would be much more combinations so i dunno if its at all possible today...
LainExperiments has joined #ffmpeg-devel
ccawley2011 has quit [Ping timeout: 264 seconds]
<wbs>
ePirat: maybe - the same issue is present in older versions too, but before 433cf391f58210432be907d817654929a66e80ba it was very unlikely to ever hit the bug
abdu20 has quit [Quit: Client closed]
abdu20 has joined #ffmpeg-devel
iive has joined #ffmpeg-devel
RapidLeader has quit [Quit: Client closed]
RapidLeader has joined #ffmpeg-devel
LainExperiments has quit [Ping timeout: 240 seconds]
cone-533 has quit [Quit: transmission timeout]
System_Error has quit [Remote host closed the connection]
System_Error has joined #ffmpeg-devel
abdu20 has quit [Quit: Client closed]
abdu has joined #ffmpeg-devel
Marth64 has quit [Quit: Leaving]
ccawley2011 has joined #ffmpeg-devel
System_Error has quit [Remote host closed the connection]
ccawley2011_ has joined #ffmpeg-devel
ccawley2011 has quit [Ping timeout: 265 seconds]
ccawley2011__ has joined #ffmpeg-devel
System_Error has joined #ffmpeg-devel
ccawley2011_ has quit [Ping timeout: 252 seconds]
LainExperiments has joined #ffmpeg-devel
jannau has joined #ffmpeg-devel
Everything has joined #ffmpeg-devel
LainExperiments has quit [Client Quit]
<ePirat>
BtbN, can you push the tags to the code.fffmpeg.org repo too?
<BtbN>
I did a ful mirror push
<BtbN>
not sure how the tags did not come along
<ePirat>
there are no tags though
<ePirat>
iirc tags always had to be pushed explicitly?
<BtbN>
Didn't expect that to be the case with push --mirror
<welder>
I think I found a bug. test_quant_bands() in tests/checkasm/aacencdsp.c initializes maxval and q34 from random elements of two global arrays, but these arrays are not initialized, and in effect the whole test compares just zeros. Calling ff_aac_float_common_init() in checkasm_check_aacencdsp fills these tables, and then the tests become flaky.
<BBB>
so xpsnr has this interesting tidbit where it requires the fps to be set
<BBB>
if the fps is not set, it SIGFPEs
<BBB>
which doesn't work well for use cases where the init_pts!=0. user guides recommend to use setpts, which appears to clear the fps, and thus results in a SIGFPE
<BBB>
should there be a workaround for this? or an option to override the fps? or can the fps be set in a filter (without resampling)?
<RapidLeader>
rm -f vf_xpsnr.c
<RapidLeader>
fps does not mean much anyway
<RapidLeader>
filter should not SIGFPE ever
<RapidLeader>
haasn: i just wrote filter that does generic 8bit<->8bit unscaled conversion and i get similar speeds with current swscale, even C code in filter is not optimized in any way, all pixdesc fields are passed as function arguments