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
<BtbN>
"master:732fb122e66c: lavfi: introduce textutils" broke this
<nevcairiel>
ah it removed is_newline and added ff_is_newline, with as many (optional) deps in one filter i suppose it can be forgiven to not test all of them, easy enough to just send a fix
mkver has joined #ffmpeg-devel
Krowl has quit [Read error: Connection reset by peer]
<NuoMi>
Hi all, I plan to merge vvc code today and fix Lynne's code reuse concern after the merge. Do you think it's ok?
<NuoMi>
but the transform may need some time. I do not want to block 7.0 release. I also hope people can try it earlier
<NuoMi>
The original idea is focus on vvc only, because change hevc code may have impact to current hevc user.
<NuoMi>
If will block us for long time
<NuoMi>
I understand her inclination for perfect code. However, software development needs to progress step by step, doesn't it? We can't wait for perfection before checking in.
<NuoMi>
Not check in means less people help to test and improve it
<JEEB>
quick and easily verifiable stuff can IMO be added into this one before merging, but IMHO as long as the work is planned to be actually done to merge the two then rest can be done after initial merge. although the problem occured on a much earlier state where no-one noticed that this stuff was getting duplicated in vvcdec.
<JEEB>
also regarding release, no idea when 7.0 is supposed to get cut :D
<NuoMi>
The patch set is quite big, already at v9. I'm not too keen on rebasing and sending it out again :). If merged, we can then focus and discuss the smaller patch set
<NuoMi>
If it will crash, or some design problem. we should fix it. But if just code reuse. It will not notice by people, right? I can change it later.
<NuoMi>
Reuse codes is not the target of initial patch set.
<kierank>
NuoMi: ignore lynne complaints
<kierank>
merge
<NuoMi>
else I may need change from hevc to h264, maybe h263.
<kierank>
just merge
<kierank>
forget what lynne says
<kierank>
j-b: ^
<NuoMi>
:), I don't want to disregard her. Some of her review comments are valid. However, my intention is to address them after the initial merge. This way, people can try and test it, report functional issues before the 7.0 release. After that, we can focus on code reuse.
<kierank>
yes
<JEEB>
but yea, in general gj with the VVC set
<JEEB>
and yes, it's rather large with the threading stuff etc
<kierank>
NuoMi has made FFmpeg great again
dellas has joined #ffmpeg-devel
<NuoMi>
:kierank thank you for support. If anyone +1 too. it's 2:1. I will merge it
dellas has quit [Remote host closed the connection]
<BtbN>
Lynne: https://www.campuspoint.de/mobile/amd-ryzen.html is my usual source for Laptops. Plenty of AMD ones. It being in German shouldn't be too big of a problem for just browsing specs I hope
<BtbN>
what you have to look for is the third digit in the CPU model
<NuoMi>
:JEEB, yes, nothing is perfect, we need more people's help to improve it
<JEEB>
yup
<BtbN>
"AMD Ryzen™ 7 7730U" -> Zen 3, "AMD Ryzen™ 7 7840U" - > Zen 4
<NuoMi>
If I keep it in the local, nobody will try and send patch for it
<BtbN>
If it says "nachweispflichtiger Artikel", it means the price is with a student Discount included. If that's substantially cheaper than what you can find for yourself elsewhere, I'd be happy to help, given I can order them with that discount
<JEEB>
NuoMi: just to be clear, if the intention is clearly to improve it along those lines and all of the requested mergings are of not close to nonzero complexity then as long as those that make sense get done I'm fine with them getting done as smaller patchses after initial vvcdec merge. what should have happened originally is that this should have been caught earlier in the process, alas it was not.
<JEEB>
for me the main point is not to have "throw and run" :) and looking at the PR in your repo I don't think that's the case
dellas has joined #ffmpeg-devel
<JEEB>
I hope this was clear enough :)
dellas has quit [Remote host closed the connection]
<JEEB>
(if not, more or less what kierank said :P)
<NuoMi>
I believe at the function level, we are in good shape. We've passed 295 conformance clips, and the C code can achieve 30fps+ for 4K on a modern computer. While there's still room for improvement, it's help from community, not a few people
<JEEB>
yup
<JEEB>
if it was unclear from my earlier comments, you can consider this a +1 as well as I think the current version passed review otherwise. and you are not running anywhere as far as I can tell :)
<JEEB>
so the mentioned stuff is coming
<NuoMi>
We chose not to reuse the HEVC code mainly because: 1. It needs HEVC code change, I don't want to impact HEVC users yet. 2. I do not want to involve HEVC to get a longer review time
<NuoMi>
3. Share code earlier evil. It may impact the VVC-specific optimizations. I hope we can delay it to asm implementation time
<Lynne>
if you merge the code without my approval, you risk a revert war
<Lynne>
I don't mind discussing
<Lynne>
I am known to change my mind
<Lynne>
but I do very much mind being told to be ignored, like what kierank just flat out said
<kierank>
Nonsense, you can't filibuster a huge patchset
<kierank>
Because it doesn't meet your standards of intellectual purity
<Lynne>
I had to fight to get approval for my vulkan patchset, after I said exactly the same thing
<NuoMi>
Instead revert it, how about you send a patch to improve it. It's a opensrouce project, right
dellas has joined #ffmpeg-devel
dellas has quit [Remote host closed the connection]
<Lynne>
that's you practically admitting that you don't plan to actually fix my comments later on
MrZeus_ has joined #ffmpeg-devel
<kierank>
You can't block a massive important patchset over something so small
<kierank>
This is astonishingly rude
<Lynne>
We don't have a lot of developers, but some of our most active developers spend their time just fixing stuff that someone did not fix years ago
<kierank>
Vulkan is not important, vvc is
<Lynne>
both are important
Kei_N has quit [Ping timeout: 246 seconds]
<kierank>
Your patchset wasn't completed in time and you wanted the whole release delayed for it
<kierank>
Vvc is done but you want to block it out of intellectual purity goals
<Lynne>
I changed my mind and I let the release happen
<kierank>
After a literal public meltdown
<kierank>
Shouting at everyone at fosdem
<Lynne>
no, after an "okay" during the fosdem discussion
<Lynne>
a simple "okay"
<kierank>
That's not how I remember it
<kierank>
Shouting at everyone about how important Vulcan is
<JEEB>
anyways, ignoring is bad which is why I would not word it like that. but the question is whether this is a blocker or not.
<kierank>
And how the release needed delaying
<Lynne>
definitely did not
<kierank>
Lol
<JEEB>
also if the author(s) are not planning to run away after merge, which right now looks unlikely
Kei_N has joined #ffmpeg-devel
<kierank>
It needs to go in so stuff like the Google fuzzer can work on it
<kierank>
That didn't apply to Vulcan
<kierank>
Google can't fuzz vulcan
<kierank>
Nor do they care about it
<kierank>
People care about vvc
<Lynne>
vulkan gets validation layers which ensure that the behaviour is exactly per-spec
<kierank>
Lol
<kierank>
Whatever
<Lynne>
it's based on theory, not fuzzing
<kierank>
Lol
<kierank>
14:21:18 <• Lynne> it's based on theory, not fuzzing
<kierank>
Intellectual purity at it again
<Lynne>
would you mind kindly not attacking me with what you call "intellectual purity goals"
<Lynne>
I have a request, and I'm trying to have a discussion
<kierank>
Then don't attack Nuo mi
<kierank>
And have yet another meltdown
<Lynne>
I haven't attacked him at any point
<kierank>
Because things don't go exactly the way you want rhem
<Lynne>
nor have I had a meltdown
<kierank>
And you again want to block something going into a release
<kierank>
When it needs to and is an important feature of historic consequences
<Lynne>
I remember exactly what happened at fosdem, and I can tell you that very much I did not make a big deal of it
<kierank>
More people will use vvcdec in a day than will use Vulcan in their lives
<kierank>
We have you a week, and then another week and another week
<Lynne>
I am clearly sensing you're trying to attack me by claiming that I'm not trustworthy, please don't
<JEEB>
NuoMi: ( ^_^)b
<Lynne>
I am merely a reviewer, and I'm trying to have a discussion
<kierank>
I'm saying don't block the merge
<Lynne>
I have left comments that I'm trying to discuss
<kierank>
Because this needs to get into git master to get fuzzed and in preparation to release
<kierank>
14:23:52 <• Lynne> I am clearly sensing you're trying to attack me by claiming that I'm not trustworthy, please don't
<kierank>
You literally threatened a revert
<kierank>
Which is unacceptable
<kierank>
14:13:57 <• Lynne> if you merge the code without my approval, you risk a revert war
<kierank>
Unacceptable
<Lynne>
it's unacceptable to merge something while there are review comments outstanding
<kierank>
Nonsense, this is a consensus based project
<NuoMi>
I am not ignore your review.Just want to explain to you I will fix it after merge. Why you insist we need fix it at initial patch? Because I can't fix it after initial patch?
<kierank>
Not a "one person can block everything"
<JEEB>
I am not sure she is insisting, or did she insist?
<kierank>
We learnt that with the sdr debacle, this is a community project
<JEEB>
the question is: good that the stuff was noticed, is it a blocker?
<Lynne>
but instead I was attacked by claiming I'm not trustworthy enough to review
<Lynne>
and that my review comments should be ignored
<JEEB>
yeh, and I facepalmed since that is veering the discussiong somewhere completely different.
<kierank>
Yes the hevc reuse stuff is not blocking
<kierank>
We should get this thing in
<kierank>
Ffmpeg-mt dragged on for years
<NuoMi>
Yes. she do not want something need rewrite to be useful :) But we always refact and rewrite softwares, right?
<kierank>
Yes
<JEEB>
how I understand it is that at least one of those things is clearly a nonzero amount of work, while the easier one already has a change set around, but still requires finishing up. so I'd note that the comments are being taken into account. now one thing that we do not want here are external APIs etc that require refactoring from the get-go (like the AVFrame subtitle thing which just dumps AVSubtitle
<JEEB>
fields into AVFrame even when there was an existing pts field etc). and this does not seem like that.
<JEEB>
so in that sense I'd be siding on the "not blocker" side
<NuoMi>
I understand Lynne's two concerns:
<NuoMi>
The filter 1. I have a patch for this. Will send out after the merge . 2. he transform - she wants to template it. I replied in the mail that I am working on it but may need some time. I plan to send it out with the ASM code. @Lynee, are you still have other concerns?
<Lynne>
yes, my concern is with code reuse
<Lynne>
you said that you copied HEVC code, but when I asked for you to make changes to it, you said that you wanted HEVC changed too
<Lynne>
you also said the code is exactly reusable between both codecs
<Lynne>
if so, why not just reuse the code, and let the HEVC assembly get reused?
<NuoMi>
the asm code is fully reuse from hevc.You will see it when we submmit the sao patch
<NuoMi>
I mean the asm patch
<NuoMi>
The inter part is can 100% reuse hevc with some modification too. We will send out after the c code merged.
AbleBacon has joined #ffmpeg-devel
<Lynne>
okay, would you mind merging the patch in?
<Lynne>
the reuse MR into your decoder tree, I mean?
<NuoMi>
I will merge the current code first. Then I will send out the reuse MR for review.
<Lynne>
why?
<Lynne>
the MR looks ready
<NuoMi>
Not every body see things like us, right. Maybe someone will object it or find a issue
<NuoMi>
It better to keep some review time for it
<Lynne>
I think it's important, it sets up a framework to share code between both
<Lynne>
I did look at it, and I do not think there's a problem with it
<NuoMi>
again, not every body look thing like you. Somebody may think xvc is not a good name...
<Lynne>
that's how reviews work
<Lynne>
but I do not believe it would result in months of delay
<Lynne>
at most, a day, or three
<NuoMi>
yeah, this why I suggest we merge the current code. Let other people test and report issue for it. then we take time to review and discuss the code reuse patch
<Lynne>
I disagree, it's not worth rushing the current code in without this framework
<Lynne>
we're not talking about significant delay here
<Lynne>
it's still the holidays, after all
<NuoMi>
The code reuse patch can wait, but the function part need verify by fuzz and other people.
<Lynne>
I do volunteer to review the patch on the ML, and I'm sure that jdek wouldn't mind having a look either
<NuoMi>
We are global team, not every country in holiday :)
<Lynne>
a few days of delay will not significantly change fuzzing
<BBB>
hm...
<BBB>
so Lynne... I think in this case, NuoMi is open to being an active maintainer for this code
<BBB>
my impression is that he won't just dump the code and run off
<BBB>
right?
<BBB>
so whether we go left first and then up, or first up and then left, we'll end up in the same place by the time the release comes around
<BBB>
so isn't it acceptable to leave some freedom to the maintainer to do as preferred?
<Lynne>
the code hasn't been merged yet
<BBB>
I agree with your comments, sao should be shared (I brought that up earlier also), and if mc can be reused, that's great. also, in-place itx is important for speed
<Lynne>
and I do not like how it's rushing to get merged
<BBB>
but it can be done after the initial version lands
<BBB>
I don't think it's rushing
<Lynne>
it is
<BBB>
I think it's getting off your plate
<Lynne>
there's already a patch
<Lynne>
no reason why it cannot be reviewed and included
<BBB>
it will be, just in a different order than what you're suggesting
<Lynne>
rather than merging code to be removed
<BBB>
if that's what the maintainer prefers, isn't that ok?
<Lynne>
it would be, but the code isn't merged yet
<Lynne>
surely I'm not the only one who sees a few days of delay as something we can live with, if the release is more than a month and a half away from being made
<BBB>
I think these decisions - if one can't be agreed upon by the community - go to the TC
<BBB>
so we can ask the TC if you insist
<Lynne>
I'd like to hear some other developers' opinions, rather than a full TCC
<BBB>
re: laptop, you want avx512-icelake, right? zen4 is icelake, not just regular skylake-avx512
<BBB>
(zen4 looks nice btw, but gather sucks from what I saw)
<wbs>
I'd prefer to go with NuoMi's suggested plan/order
<Lynne>
zen 4 is ICL, yes
<BBB>
ok so my opinion is that it's ok to give some freedom in ordering to the maintainer
<Lynne>
elenril, nevcairiel, jamrial: any opinions?
<BBB>
so I'm ok with that NuoMi is proposing
<Lynne>
NuoMi: would you add a comment to the transforms file header warning developers from writing assembly?
<BBB>
I agree with Lynne that her plan is in theory better, but I think it's better to go with what the maintainer prefers if the end result is the same
kekePower has quit [Quit: Ping timeout (120 seconds)]
<BBB>
adding a fixme/warning sounds acceptable btw
<Gramner>
keep in mind that zen4 only has 256-bit execution units, so you'll often end up with the basically the same perf as avx2 on function-level benchmarking unless you can leverage new instructions, compared to the intel ones where even just using wider vectors is beneficial by itself
<BBB>
(to the source file)
tufei__ has joined #ffmpeg-devel
kekePower has joined #ffmpeg-devel
<Lynne>
shuffles are full-width, though, and having 32 registers is a big deal
tufei_ has quit [Ping timeout: 240 seconds]
<Gramner>
yes, the avx-512 shuffles are indeed amazing
<BBB>
32 registers is also nice for large transforms etc.
<BBB>
you can never have too many registers
<NuoMi>
Hi, Lynne, sure. I will send out a patch to comment it after merged
<Gramner>
I found the largest benefit of having more registers is a) not needing to micro-optimize register allocation as much, and b) going from 6 caller-saved registers to 22 on win64
tufei__ has quit [Remote host closed the connection]
<NuoMi>
Lynne: CPU can only execute one task at a time. We have to choose a order
<BBB>
also, congrats on getting this in, big achievement!
<NuoMi>
<Lynne> NuoMi: I just wanted you to wait for no more than 20 minutes and just add the comment in before your merge, but it's too late now. Oh sorry, I misunderstood you. I think you want me add some comment to the source code.
<Daemon404>
[15:57] <@BBB> also, congrats on getting this in, big achievement! <-- yes youre a legend, NuoMi
qeed has quit [Remote host closed the connection]
qeed has joined #ffmpeg-devel
<NuoMi>
BBB: I'm not an expert like you. I still need your great help to review and send improvement patches
<BBB>
I think we all know equally much: just enough to write what we want to write
<BBB>
but seriously, you should take a victory lap
<NuoMi>
<Daemon404> thank you. Please help to improve it
<BBB>
and please come to vdd for a beer or two
b50d has quit [Remote host closed the connection]
<NuoMi>
You are just so humble
<mindfreeze>
‘Grats on VVC landing
* mindfreeze
waiting for kierank posting in Linkedin
<NuoMi>
jb and kieran invited me to present at FOSDEM, but it seems hard to get a visa. Everyone wants to goto EU
<NuoMi>
Please help improve performance. So I can take more beer at VDD
<NuoMi>
thank you mindfreeze
NuoMi has quit [Quit: Leaving]
Krowl has quit [Read error: Connection reset by peer]
dellas has joined #ffmpeg-devel
BtbN has quit [Remote host closed the connection]
jess has quit [Quit: Lost terminal]
jess has joined #ffmpeg-devel
BetweenUs has joined #ffmpeg-devel
kasper93_ has joined #ffmpeg-devel
philipl has quit [Ping timeout: 276 seconds]
BetweenUs has quit [Quit: Leaving]
kasper93_ has quit [Remote host closed the connection]
rvalue has quit [Ping timeout: 276 seconds]
<kierank>
anyone familiar with libfuzzer?
rvalue has joined #ffmpeg-devel
<jamrial>
re vvc, we need tests. is there a public conformance suite of samples?
<JEEB>
yea
<BBB>
should be, yes. although I bet you gotta sign up and maybe pay to get access
<JEEB>
but the firefox pdf reader at least doesn't find it
Krowl has joined #ffmpeg-devel
<JEEB>
> The associated conformance testing bitstreams are included with this Recommendation | International Standard as an electronic attachment. The following information is included in a single zipped file for each such bitstream.
<BBB>
jeeb is not coming home before dinner tonight
<JEEB>
frankplow: that's I think the same stuff as what ends up in that zip
<JEEB>
but yes, jvet documents are good to keep an eye on
<JEEB>
esp. since N-documents is no longer searchable without a general ISO login :<
<jamrial>
no 8bit samples? is vvc 10+ only?
<frankplow>
The VVC decoder's tested on github actions against pretty much the whole suite using the python scripts in this repo: https://github.com/ffvvc/tests but should probably take some of the bitstreams over to fate
<jamrial>
frankplow: i see VTM-20.2 released not too long ago, which could be tested in that repo
<JEEB>
jamrial: 8b420_A|B exist
<JEEB>
under 6.6.4.2
<jamrial>
JEEB: yeah, found them after writing the above :p
<JEEB>
8bit is now considered "additional bit depth for Main10"
<frankplow>
VVCv2 bitstreams are all 10-bit+ as that's mostly what was added but there's a fair few in v1
<JEEB>
> A copyright SEI message was present in H.263 Annex W, “Picture Message”, MTYPE == 2
<JEEB>
funny how tencent is presenting it
<Daemon404>
it really doesnt
<Daemon404>
its like ... we need one because we do
<frankplow>
`ci_year_plus1886`, because "1886 is the year where the Berne Convention on Copyright was first signed" lol
<Daemon404>
:D
<JEEB>
yes :D
philipl has joined #ffmpeg-devel
<Daemon404>
they claim it is beause of people messing with ES
<Daemon404>
but those people woul just strip it
<JEEB>
yea
cone-087 has quit [Quit: transmission timeout]
<Daemon404>
inb4 it's a nintendo-style thing where they want it to prove people knew it was copyrghted
lemourin has joined #ffmpeg-devel
<JEEB>
something like that I would guesstimate
<Daemon404>
honest, judge, i didnt know this hollywood movie was copyrighted
<BBB>
your honour, I heard about this new feature of listing copyright in a file, and when I opened it in hexedit, it wasn't there in this divx copy, so I thought it was therefore ok
<courmisch>
so if I write stuff in 1885 but release it in 1886 after the Berne convention is signed, how does it work
<courmisch>
asking for after I acquire a time machine
<ramiro>
courmisch: what board are you using for you risc-v work?
<courmisch>
atm, VisionFive 2 and Kendryte K230
<jkqxz>
haasn: Do hardware formats work at all with the new filter negotiation?
<jkqxz>
I'm seeing that graph setup calls config_formats (which does the negotiation and requires hw_frames_ctx to be set on links with hardware formats) before config links (which sets hw_frames_ctx on links).
<jkqxz>
This ordering of operations seems like it is possibly a problem.
<ramiro>
courmisch: thanks. I'm thinking of getting a visionfive 2. the kendryte k230 only has 2 cores, so I don't think it will be powerful enough. I'm playing around with a bunch of sbcs to see which one works best for a glitch art project.
ccawley2011 has quit [Ping timeout: 268 seconds]
<ramiro>
courmisch: if you have some spare time and want to optimize fdct and dct_quantize, that would save me some work :)
<haasn>
jkqxz: I don’t recall changing the order of anything
<haasn>
jkqxz: which commit are you worrying about?
<JEEB>
libavfilter/avfiltergraph.c:670 asserts with vaapi apparently
<jkqxz>
8c7934f73ab adds things which look at hw_frames_ctx on the links before they are set.
<jkqxz>
I don't see anything vaapi-specific on that, but I don't have a d3d device convenient to test something else right now.
Marth64 has joined #ffmpeg-devel
<JEEB>
yea, vaapi is probably just one possible thing that is hitting that
<jkqxz>
Yep, definitely that commit. Working on e687a848542, broken on 8c7934f73ab.
<jkqxz>
It needs to somehow propagate the hw_frames_ctx through the graph as it resolves the formats?
<jkqxz>
I think that requires that config_formats and config_links be interleaved, because some of the frames contexts will be created inside the graph.
<jkqxz>
I don't understand how this works with libplacebo. It's negotiating the colour properties, but how does it set the vulkan frames context for pick_format to see?
<haasn>
jkqxz: I think we need to fall back to using link->src->inputs[0]->hw_frames_ctx
<haasn>
mirroring logic from avfilter_config_links
<haasn>
and actually, maybe the fallback metadata forcing should just be moved to that function
<jkqxz>
How does that help? The frames context isn't set anywhere in the graph.
<haasn>
oh, I see what you mean, unless we change the way hwformats get forwarded we do indeed run into an issue the moment you use more than two
<haasn>
hmm
<jkqxz>
Also if the frames context is creaed by hwupload then it doesn't exist at all until the output link on that filter gets configured.
<haasn>
what would happen if we just switched hte order of config_links and choose_formats
<haasn>
they seem to configure an entirely orthogonal set of fields
<jkqxz>
config_links needs the format.
<haasn>
hmm
<jkqxz>
I think the interleave answer might be the right one? Once you've picked all the formats on a filter, configure it at that moment.
<haasn>
maybe the easiest resolution is to just hoist sw_format out of the hwfc and into the link
<haasn>
which would also allow bidirectional resolution on the sw_format
<ramiro>
I tested with a few sbcs (raspberry pi 5, orange pi 5, odroid n2+), but it would be interesting to know the performance improvement on apple silicon.
<jkqxz>
So query_formats has to be aware of sw_format as well if it is going to change anything, but otherwise it can pass through?
<haasn>
one thing I don't like about the naive approach of having format and sw_format coexist as independent fields is that it would prevent you from being able to express logic like "support nv12 and yuv420p for vulkan, but support only yuv420p for vaapi"
<haasn>
not sure if that's a realistic case
<haasn>
jkqxz: yeah pretty much
<JEEB>
ramiro: I think we have one for developer use
<jkqxz>
Are there any filters with multiple formats like that?
<haasn>
and e.g. hwdownload could force outlink->sw_format and inlink->format to be the same format ref
<haasn>
instead of erroring at runtime
<jkqxz>
Omgyes. That is such a stupid annoyance that you have to set format on the output manually to make the filte graph work.
<haasn>
currently -vf format=yuv420p,hwupload,format=vulkan,hwdownload,format=nv12 is a runtime error, not a link time configuration error
<jkqxz>
Yeah, all hwdownload use is a pain because of that one.
<haasn>
I think I'll give that approach a try
<haasn>
how do we solve the immediate regression though
<JEEB>
yea, I just had to semi-apologize to a user on #ffmpeg wrt hwdownload :D
<courmisch>
ramiro: I'm not sure what there would be to optimise. Maybe add some restrict or const qualifiers and such, but that's better done by someone that understands the DCT code, and needs no RISC-V device
<courmisch>
s/that /who /
<haasn>
should we just relax the assertion on link->hw_frames_ctx being set and treat links with unknown hwctx as being unspecified/unspecified for now?
<jkqxz>
haasn: If you promise to fix it properly then <https://0x0.st/H6_7.diff> does mostly work for now (not obviously worse than it was before).
<jkqxz>
You do need to set some format so it still carries the colourspace, but doesn't really care what that actually is.
Krowl has quit [Read error: Connection reset by peer]
BtbN has joined #ffmpeg-devel
<haasn>
would break for rgb links but probably not a big deal
<jkqxz>
Patch sent.
epony has quit [Remote host closed the connection]
<ramiro>
JEEB: oh, so I could get ssh access or something? who should I contact?
<ramiro>
courmisch: maybe I'm misunderstanding something, but riscv has vector instructions, doesn't it? certainly fdct could be optimised.
<JEEB>
ramiro: yea, kierank I think was administering the access
AbleBacon_ has joined #ffmpeg-devel
<kierank>
maybe tomorrow now
* kierank
sick
<JEEB>
hope you get well :)
<ramiro>
kierank: thanks, I'll ping you in a couple of days. in the meantime, well, "get plenty of fluids" (or at least that's what chatgpt tells me when I'm sick)
<kierank>
I am not in bed any more but I don't want to do a user config with a headache
<kierank>
especially on mac where it's "special"
<JEEB>
yea, I fully get it
<JEEB>
late evening and all that jazz :)
AbleBacon_ has quit [Quit: I am like MacArthur; I shall return.]
epony has joined #ffmpeg-devel
<haasn>
jkqxz: testing WIP but something like https://0x0.st/H6LU.txt is what I was thinking
<haasn>
not sure if I'm missing something obvious with this design (e.g. various hwframe filters need to be augmented to advertise their supported swformats)
<haasn>
are there any other filters that transfer between hwframes and swframes besides vf_hwupload* and vf_hwdownload
<haasn>
vf_libplacebo can do it, I guess
<haasn>
oh right, all of the hwfc setup code needs to look at the configured sw_format now
iive has joined #ffmpeg-devel
<jkqxz>
haasn: Things like vf_scale_vaapi which can convert between formats will need to handle changing sw_format too. Not sure what the full set of filters to add to is.
MrZeus__ has joined #ffmpeg-devel
<jkqxz>
But yeah, that approach looks right and I don't see any reason why it won't work.
<haasn>
jkqxz: okay, I'll polish it up, probably sometime when I get home
<haasn>
(am still travelling, it's hard to work here except in whatever 30 min increments I get)
MrZeus has joined #ffmpeg-devel
MrZeus_ has quit [Ping timeout: 245 seconds]
MrZeus__ has quit [Ping timeout: 264 seconds]
ccawley2011 has joined #ffmpeg-devel
ccawley2011 has quit [Read error: Connection reset by peer]
tufei_ has joined #ffmpeg-devel
CoreX has quit [Ping timeout: 264 seconds]
CoreX has joined #ffmpeg-devel
tufei__ has quit [Ping timeout: 240 seconds]
bencoh_ has joined #ffmpeg-devel
courmisch has quit [Ping timeout: 264 seconds]
BtbN has quit [Remote host closed the connection]
courmisch has joined #ffmpeg-devel
BtbN has joined #ffmpeg-devel
bencoh has quit [Ping timeout: 268 seconds]
bencoh_ has quit [Changing host]
bencoh_ has joined #ffmpeg-devel
bencoh_ is now known as bencoh
BtbN has quit [Remote host closed the connection]
BtbN has joined #ffmpeg-devel
<j-b>
good morning
<haasn>
When live streaming to a single client, and low latency is desired, would it make sense to use P frames only?
<haasn>
Or are extra I frames still needed every now and then
<haasn>
Presumably you’d want to avoid B frames either way for latency
<nevcairiel>
I would still include the occasional I frame for recovery reasons
<nevcairiel>
but yes low latency means no Bs
<Marth64>
j-b: Good morning hopefully my example about the 0xA0 space made sense
<Marth64>
grep -rP "\xA0" will show
<BBB>
it is definitely not morning in any place where I would expect j-b to be right now
<BBB>
j-b: you visiting seoul & tokyo?
<BBB>
or australia?
dellas has quit [Remote host closed the connection]
dellas has joined #ffmpeg-devel
tufei_ has quit [Remote host closed the connection]