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.0.2 has been released! | Please read ffmpeg.org/developer.html#Code-of-conduct
thilo_ has quit [Ping timeout: 248 seconds]
thilo_ has joined #ffmpeg-devel
<cone-781>
ffmpeg Marvin Scholz master:f43916e217e2: ffbuild: add METALCC and METALLIB to BRIEF
vipyne has quit [Quit: Leaving.]
feiw1 has quit [Remote host closed the connection]
feiw1 has joined #ffmpeg-devel
feiw1 has quit [Remote host closed the connection]
feiw1 has joined #ffmpeg-devel
feiw1 has quit [Remote host closed the connection]
feiw1 has joined #ffmpeg-devel
vipyne has joined #ffmpeg-devel
Xaldafax has quit [Quit: Bye...]
vipyne has quit [Quit: Leaving.]
Martchus has joined #ffmpeg-devel
Martchus_ has quit [Ping timeout: 248 seconds]
jamrial has quit []
arch1t3cht5 has joined #ffmpeg-devel
arch1t3cht has quit [Ping timeout: 252 seconds]
arch1t3cht5 is now known as arch1t3cht
cone-781 has quit [Quit: transmission timeout]
arbitercoin has joined #ffmpeg-devel
MisterMinister has joined #ffmpeg-devel
haihao has quit [Ping timeout: 265 seconds]
haihao has joined #ffmpeg-devel
mkver has joined #ffmpeg-devel
aaabbb has quit [Ping timeout: 272 seconds]
MisterMinister has quit [Ping timeout: 252 seconds]
<Lynne>
philipl: what was the cuda power level 2 issue again that made folks choose vulkan decode again?
<Lynne>
was it that it spent too much energy powering up the GPU fully or?
<King_DuckZ>
anyone able to help with my question from yesterday and 2 days ago?
cone-666 has joined #ffmpeg-devel
<cone-666>
ffmpeg Martin Storsjö master:157ce2193977: checkasm/sw_rgb: Revert test additions from e18b46d95fadcbaaf450bda9f1871849f2b0c586
ccawley2011 has joined #ffmpeg-devel
<wbs>
ePirat: I tested the configure/ld patch for -Wl,-no_warn.... with xcode 14/15/16, and it seems to work as expected
averne has quit [Quit: quit]
<elenril>
King_DuckZ: which was?
<haasn>
are interlaced bayer formats a thing?
<elenril>
a connoisseur of perversion I se
<elenril>
e
<haasn>
okay dumb question, I'll just return an error
<JEEB>
:)
j45_ has joined #ffmpeg-devel
j45 has quit [Read error: Connection reset by peer]
j45_ is now known as j45
j45 has quit [Changing host]
j45 has joined #ffmpeg-devel
<elenril>
does sws need to care about interlacing?
<nevcairiel>
scaling needs to care, so you either pawn that off to the caller, or make the library mroe useful :D
<elenril>
I mean is there more to it than just scaling each field separately?
<haasn>
elenril: it affects chroma siting quite substantially
<elenril>
ah, right
<King_DuckZ>
it was this:
<haasn>
so if you want swscale to respect the tagged chroma location
<elenril>
accurate chroma locations, so kinky
<haasn>
(which I want)
<King_DuckZ>
what's the best way to flush the udp buffer in ffmpeg from mpv when playing a stream? should I add an api for that (if it doesn't exist yet) or is it best to destroy all objects and re-create them? I'm managing an error situation where the stream gets very flaky and mpv stops
<haasn>
it needs to understand if this is the top or bottom field
<haasn>
IMO easier to just have swscale handle interlacing internally
<haasn>
that way you can also have it take into account the `interlaced` flag
<elenril>
King_DuckZ: seek to current position?
<JEEB>
King_DuckZ: technically I think this thing is closer to #ffmpeg (API usage) side, but you might want to detail the actual issue at hand. I mean, what is this "flaky" you talk of? I know that the UDP protocol has unlimited timeout by default, so if it's some issue due to stuff getting stuck or whatever, then setting a sane timeout of a second or few should help with that
<cone-666>
ffmpeg Martin Storsjö master:a3ec1f8c6c6f: aarch64: h26x: Fix the indentation of one function
<haasn>
I'm starting to think that a scale_frame_slice() function is fundamentally misguided
<haasn>
consider the extreme case of scaling a 1000x1000 frame down to 1x1
<haasn>
what does it even mean to scale a partial slice of the source frame?
<haasn>
the only thing that would make sense is to base it on the _output_ frame, not the input frame
<haasn>
but then we need to reverse engineer which lines are relevant at each point in the filter graph
<haasn>
not impossible but also not trivial
<Daemon404>
doesnt zimg base its tiling on output frame
<Daemon404>
i used tue api so i should remember...
<haasn>
yeah it seems to make more sense
<Daemon404>
it was slightly non intuitive iirc
<haasn>
and in any case, you need potentially read from every pixel of the input image to produce even one pixel of output
<Daemon404>
fractional pixels came into play
<haasn>
consider filtering with a 1000x1000 kernel
<elenril>
haasn: IIRC the motivation was to enable cases where input becomes available in slices
<Daemon404>
input must always be a full frame
<haasn>
the other case I'm worrying about is with sequential dither
<Daemon404>
you cant get around that
<haasn>
ie error diffusion
<King_DuckZ>
elenril: interesting, I'll try that!
<elenril>
then sws can potentially make use of that information to be faster
<elenril>
or not
<haasn>
you can't request to scale e.g. lines 200 to 400 without having already scaled lines 0 to 200
<haasn>
for error diffusion
<Daemon404>
sliced input is just asking for bugs or bad output
<Daemon404>
or weird gimped apis
<haasn>
so I think we should drop the sliced API at least for now
<haasn>
can always re-add it later
<elenril>
I was not a big fan of the idea either
<elenril>
so no objections from me
<haasn>
elenril: I mean I don't see what swscale could be doing faster, at best you could be slightly clever about scaling in parallel to decoding
<elenril>
haasn: probably start scaling the part of the output for which you have data
<haasn>
that's why swscale 1 keeps track of which lines were made available yet
<King_DuckZ>
JEEB: it's been very hard to track down, I *think* udp is somehow corrupt, reader in udp.c struggles to fill the buffer causing demuxer (or decoder?) to underrun and quit, mpv thinks it's paused and stops, eventually udp stream comes back up and circular buffer in udp.c fills up because no one is reading anymore
<haasn>
ironically, it doesn't actually use this for anything
<King_DuckZ>
s/reading/consuming/
<haasn>
it only starts scaling when the entire output is available
<haasn>
input*
<elenril>
haasn: basically, michaelni wanted the API to support this
<elenril>
without the implementation necessarily being there
<elenril>
which is why I added it
<Daemon404>
always leads to good api desigm
<haasn>
I can see the motivation but I don't think we need an API for a use case we have no plans (or reasonable ability to) actually ever implement
<haasn>
hrm
<elenril>
I'm fine with dropping it
<JEEB>
King_DuckZ: neither decoder or demuxer would underrun. you can of course get garbage out of demuxer if input is broken, and that may then break some logic for whatever is basing stuff based on that
<King_DuckZ>
best idea so far is to have mpv not get stuck like that, but when we do it keeps running into problems because the udp buffer gets filled with invalid data that can't be correctly decoted (nor rejected it seems), so being it a live stream once you know you have network issues it's worth clearing the udp buffer, even when it contains correct data it'd still be outdated
<JEEB>
King_DuckZ: the two things I always tell people to enable with UDP: timeouts and for the avformat context the discard_corrupt flag
<JEEB>
since if the MPEG-TS is known to be corrupt, there's no reason to pass it on to anywhere
<haasn>
it seems the way zimg handles it is using optional input reading callbacks
<King_DuckZ>
JEEB: I think we already spoke about that, I already enabled the discard corrupt, it improves things but doesn't fix everything unfortunately
<haasn>
so you can handle blocking and threading in the input read callback
<Daemon404>
the zimg api works but is hard to ise correctly
<Daemon404>
it took me several days to do it
<Daemon404>
but it works.
<haasn>
I mean we can add input reading callbacks at any time
<haasn>
so I'll drop the sliced API for now
<King_DuckZ>
I think we have a custom decoder for rockchip, no idea if anything in there is getting stuck tbh
<Daemon404>
also of note is that hardly any avcodec stuff outputs in slices
<Daemon404>
h264 and ...?
<King_DuckZ>
JEEB: the timeout you speak of, is it the url parameter?
<JEEB>
no, it is properly as an AVoption as well
<Daemon404>
rw_timeout probably
<Daemon404>
or one of the ither 4
<JEEB>
Daemon404: you are correct, but the udp protoocl module for whatever reason overrides rw_timeout with its own timeout option's value
<Daemon404>
lolwat
<JEEB>
one of those things that "needs fixing at some point"
<JEEB>
since TCP things at least generally follow rw_timeout
<King_DuckZ>
ah ok, I think I did something different, I increased the timeout in udp_read() in udp.c to I think 10 secs and it fixed the issue I described above (it makes the decoder not give up before udp data starts flowing back in), just as a proof of concept. Idk if the timeout url parameter or the one you're speaking of are equivalent
<King_DuckZ>
but that's a workaroud, I think the proper solution is to not give up (decoder, mpv, I'm not sure where yet) and clear the udp buffer because it's either rubbish or outdated frames
<JEEB>
it does set the same internal variable, but I heavily dislike the random stuff in URL parameters
<JEEB>
since AVOptions Do Work
<King_DuckZ>
the code I'm talking about btw it's all hardcoded numbers afaict
<King_DuckZ>
JEEB: ok
<King_DuckZ>
oh there it is maybe h->rw_timeout = s->timeout;
<King_DuckZ>
so url parameter overrides rw_timeout, no ifs and no buts
<JEEB>
s->timeout is also the AVOption
<JEEB>
and yes, as I said :P
<JEEB>
that is a dumb boog in the udp module
<JEEB>
pretty sure whomever added support for rw_timeout did not want that
<King_DuckZ>
`s->timeout = strtol(buf, NULL, 10);` that's from the url, I don't see anything else assigning to that variable
<JEEB>
see the AVOption options[]
<King_DuckZ>
ok
<JEEB>
specifically > OFFSET(timeout)
<JEEB>
that means that this struct member will get that AVOption's value
<JEEB>
the framework takes care of parsing and assigning it
<King_DuckZ>
libavutil/opt.h am I looking at the right struct?
<JEEB>
no, you can just look at udp.c
<JEEB>
you don't need to read into the framework itself
<JEEB>
you can just look at the line defining the AVOption :P
<King_DuckZ>
ohh ok found it sry!
<King_DuckZ>
still I think that timeout is not doing the same thing I hacked into udp_read()
novaphoenix has quit [Quit: i quit]
<King_DuckZ>
(I'm not gonna commit that hack anywhere, I'm looking for a proper solution)
novaphoenix has joined #ffmpeg-devel
aaabbb has quit [Changing host]
aaabbb has joined #ffmpeg-devel
<ePirat>
wbs, ok, LGTM then, thanks a lot
<wbs>
ePirat: for x86_64, the warning about nasm object files being OS-less still is present though, and nasm hasn't moved anywhere regarding implementing setting the OS field, and there's iirc no option for disabling that warning either
<wbs>
(but luckily, x86_64 is mostly a thing of the past for this platform) :P
<ePirat>
yeah I very much notice that being spammed with a huge amount of warnings :D
<ePirat>
I wonder how hard it would be to add this to nasm
<wbs>
there is an MR for it already since a couple of years
<Lynne>
haasn: interlaced bayer is definitely not a thing, it can't hurt you
<haasn>
but what if we
<haasn>
... make it a thing?
jamrial has joined #ffmpeg-devel
<haasn>
generally speaking is something like a 3x3 matrix multiplication faster on planar data or packed pixels?
<haasn>
like just comparing mult_3x3(int weights[9], u8 *r, u8 *g, u8 *b)
<haasn>
vs mult_3x3(int weights[9], u8 *rgbx)
<haasn>
in GPU code, packed data is always preferable because it interacts better with texture fetch units
<haasn>
but I think that for SIMD, it may be preferable to have data in planar form?
<Lynne>
packed data is always better
<Lynne>
since you have less need to dump cache by tracking multiple buffer simultaneously
<Lynne>
even for encoding, packed data is more efficient, which is why x264 prefers nv12 input
<Lynne>
generally most pixel processing code is just waiting on data, rather than operating on data
haihao has quit [Ping timeout: 252 seconds]
haihao has joined #ffmpeg-devel
<haasn>
okay
<haasn>
makes sense
<haasn>
also easier for me to implement
<ePirat>
wbs, oh neat
<wbs>
ePirat: yup. but unfortunately, to take that into use, we'd need to probe for support for such an option, and start passing it. and to pass the right value, we'd need to check what OS the C compiler actually is configured to use (macos, or iphone simulator, or other simulator, etc)
<wbs>
so it's not really a case to just merge that and be done with it, unfortunately
<ePirat>
wbs, this might get easier with the enhancement plans I have for ffmpeg configure
<ePirat>
just takes a while as configure is quite the beast to understand properly
<ePirat>
also configure seems to happily use cpp interchangeably for C PreProcessor and C PlusPlus…
<ePirat>
and sometimes cxx for the latter… who needs consistency and useful names anyway :P
fred has quit [Quit: +++ATH0]
fred has joined #ffmpeg-devel
microlappy has joined #ffmpeg-devel
microlappy has quit [Remote host closed the connection]
vipyne has joined #ffmpeg-devel
cone-666 has quit [Quit: transmission timeout]
paulk has quit [Quit: WeeChat 3.0]
<philipl>
Lynne: as soon as you init cuda, it forces the GPU into power level 2. That's it. no questions, no options. So it destroys the power saving opportunity of using hardware decoding.
IndecisiveTurtle has quit [Ping timeout: 265 seconds]
<philipl>
Lynne: the irony is that they force power level 2 to avoid going into PL1 or PL0 which apparently can cause problems with very intense cuda workloads so there are also people complaining that it slows their GPUs down when trying to do other things at the same time
DauntlessOne has quit [Read error: Connection reset by peer]
DauntlessOne has joined #ffmpeg-devel
Krowl has joined #ffmpeg-devel
DauntlessOne has quit [Remote host closed the connection]
DauntlessOne has joined #ffmpeg-devel
MisterMinister has joined #ffmpeg-devel
<jamrial>
do we have some way to signal a stream is a thumbnail? i see a disposition but it's "timed thumbnails"
<haasn>
what is the purpose of FF_PTR_ADD?
<elenril>
jamrial: if I'm understanding your patches correctly, they break the semantics of AVStreamGroupTileGrid
<Daemon404>
jamrial, we've always used disposition
<Daemon404>
even for non-timed
<Daemon404>
e.g. for jpeg thumbnail in mov
IndecisiveTurtle has joined #ffmpeg-devel
<Daemon404>
jamrial, i think we use 'attached pic' in mov
<Daemon404>
for the thumb tracks
<elenril>
huh, or maybe they don't since nb_tiles is decoupled from the group stream count
<elenril>
it's still a bit confusing though
<Daemon404>
HEIF is confusing.
<Daemon404>
maybe i am thinking of AV_DISPOSITION_STILL_IMAGE
<Daemon404>
we have a lot of image dispositions.
<elenril>
you might want to comment on the thread then
<Daemon404>
im sure the answer will be "let's add more dispositions" ;)
<elenril>
thankfully we can't add all that many
<elenril>
unless you want AVStream.disposition2
<Daemon404>
bitmasks strike again!
<Daemon404>
we should add gmp has a hard dep so we can do arbitrary precision bitmasks
<elenril>
do you wear your troll-driven-development shirt today
<King_DuckZ>
elenril: you know what? I don't see a single place in udp.c where fifo seems to get a flush, I'm not convinced that seeking would do anything to the fifo in there
<King_DuckZ>
do you guys think it'd do any good if I implemented a url_read_seek for URLProtocol? I don't understand that virtual class system very well yet! I also see a url_delete function pointer in there?
<King_DuckZ>
implement it to just clear the fifo that is, not to do any actual seek
<JEEB>
King_DuckZ: since just reading data from the proto should lead to stuff going away from the buffer, it sounds like something goes bork :P I mean, if it's just borked packets that should go through rather quickly
<JEEB>
because if the API client is still bork, it will not read the data even if you flush the protocol level buffer
<elenril>
JEEB: senpai will never notice me
Workl has joined #ffmpeg-devel
<King_DuckZ>
I've been looking at this for 5 weeks now, plus someone else for 3 weeks and we're still not sure what's going on - it looks like audio or video sometimes report an end of stream but not the other, because of some broken udp packets I guess, I'd really like to clear all buffers whenever this situation happens
<jamrial>
<@elenril> huh, or maybe they don't since nb_tiles is decoupled from the group stream count <- yeah, that lets us add streams that are not part of the grid
<elenril>
still, might be nice to mention that explicitly in the doxy
<elenril>
it's quite non-obvious
<King_DuckZ>
JEEB: that's the thing, we have some changes for mpv to wait for max 5 seconds if only video or audio have ended but not the other, then we make it retry from sctratch, though if udp buffer still contains crap the next read attempt also fails
<JEEB>
King_DuckZ: use multicat to save multicast with timing files in the directory mode. will let you then replay it later.
<JEEB>
it will let you analyze what crap you got fed as well
<jamrial>
elenril: ok
<King_DuckZ>
JEEB: we used tcpdump, is multicat a better tool? I didn't know either before this
Krowl has quit [Ping timeout: 248 seconds]
<JEEB>
multicat at least has worked very well for me, you get the exact data as split-by-timestamps files together with timing files for replay
<JEEB>
but yea, basically I feel like buffer not being eaten after a while is a symptom and not the actual issue. esp. coupled with discarding known corrupt packets
<JEEB>
if you still get borked stuff in, at that point most likely whatever is taking those packets in is the thing that's getting logic-broken
<JEEB>
at which point you just want to re-init completely the opened stream
<JEEB>
avio, avformat, avcodec - the whole works
<JEEB>
which in mpv terms sounds like "reload input"
<jamrial>
JEEB: those docs are barely readable, lol
<JEEB>
jamrial: welcome to drafts :)
<King_DuckZ>
right, quite more radical than just a seek... I can do that I suppose
<JEEB>
not trying to flush just some buffer since if the latter parts are broken they will not get fixed until you reinit stuff on a higher level
<JEEB>
I would probably have a timeout of like 1s, discarding corrupted data as well as tries to reopen the input if the timeout is hit or things go bonkers
<King_DuckZ>
but yeah it's a real mystery, so far the way for me to repro it is to have tcpreplay looping and constantly ctrl+z / fg it, while mpv plays the stream back, it mostly recovers but it eventually gets stuck. very hard to debug since remote debugging is not working either
<King_DuckZ>
ok
<JEEB>
generally for the problems I've dealt with, if you feed it the same data with same timings it generally makes things happen if the issue is due to input
<JEEB>
and all I can say is that I've just found multicat before looking at tcpdump etc, and it has worked well for me. I just have the dumping run with 1 minute segments, and then when the issue happens I can take some segments before it, and then replay it through the problem
<JEEB>
of course sometimes you literally need to go over the mpeg-ts wrap-around, in which case you might need to dump for more than 26.5 hours
<JEEB>
and then if it's MPEG-TS you can use DVB inspector to look at the MPEG-TS stream structure itself, to find possible issues in either data or the mpeg-ts demuxer
<King_DuckZ>
it is indeed mpeg-ts udp multicast, I did take a 1-min long set of tcpdumps though that doesn't seem to reproduce the problem, I can retry with multicat and dvb inspector, it's worth trying for sure
<JEEB>
basically set up multicat with 1 minute segments in the directory mode
<JEEB>
then have a cleanup script in cron that cleans up segments older than X houts
<King_DuckZ>
since testing takes hours (sometimes 14h+) I'd like to make this buffer flush change first so it gets tested while I attempt to take another stream dump
<King_DuckZ>
ok!
<elenril>
jamrial: I think it'd be useful to enumerate the possibilities explicitly, as we add them
<JEEB>
I would be surprised if magically all the rest of the flow would be OK
<elenril>
sec, i'll draft some text
<JEEB>
my expectation is that the buffer would get flushed and then still not being read from since the problem is downstream :P
<JEEB>
thus the focus on "if I just could flush this buffer" is weird
<JEEB>
I mean, you can just reinit the avio (called stream in mpv), sure. but that would still not fix the rest of the API client's logic
<JEEB>
if it's not reading data from the AVIO context then it's not reading it
<King_DuckZ>
I mean, from the logs what I understand is that in udp.c circular_buffer_task_rx() gets stuck on recvfrom() and elsewhere an underrun occurs because no data is coming in, then things stop (and they shouldn't) on the client side and when recvfrom() eventually returns it fills up the fifo because no one is consuming from it anymore
<JEEB>
and if you just want to reinit everything you can do it on a higher level within mpv by recreating the stream, the demux and the decoders (or just having a reopen of the input)
<jamrial>
oh wow, these iphone heic photos have exif metadata in the mdat box, near the end of the file
<King_DuckZ>
that's an option, I originally came here to ask if there was an API in ffmpeg to clear the cache, but as you correctly pointed out it might do nothing even if it existed (or if I find a way to trigger it, such as seek)
<jamrial>
instead of in the nicely available idat box at the very beginning
<JEEB>
King_DuckZ: good that you're grasping the fact that even if the buffer was flushed, if nothing is reading the AVIO context then most likely nothing will start suddenly reading it, either
<elenril>
(assuming we want to add AV_DISPOSITION_THUMBNAIL)
<King_DuckZ>
that you convinced me long time ago when I was looking at overrun_nonfatal, remember that? :)
<JEEB>
christ, I wish that thing would be removed from so many places
<JEEB>
so many people think it magically fixes their problems
<elenril>
jamrial: is that like sticking id3v2 into matroska?
<JEEB>
"no, it will literally just cause you to get some extra corruption since you just threw some data on the floor"
<JEEB>
"fix the goddamn root cause"
<King_DuckZ>
the thing is I can't find what is getting jammed, like, why client code stops reading while recvfrom() is blocking, that should definitely not happen, and why it only happens sometimes, and when it happens all running players freeze on the same frame
<jamrial>
elenril: it's a data offset referenced by an item
<jamrial>
it can be either in mdat or idat, the latter which is inside the meta box alongside every other box that describes the image, for quick access
<JEEB>
in mpv demux is in its own thread so it should not block things even if avio blocks (because recvfrom blocking basically means that there's no data coming in)
<JEEB>
welcome to debugging API client logic :P
Krowl has joined #ffmpeg-devel
<JEEB>
but yea, in any case set up a multi-hour multicat dumping
<JEEB>
you really want it to be so that you can just stop it after the issue has happened, and then look into timings :P
<JEEB>
and try to see if replaying a minute or two before the issue and through the issue makes it happen
<King_DuckZ>
JEEB: please replace it with "enable_magic_fix_for_my_specific_proble=true/false" :D
dukesook has joined #ffmpeg-devel
<jamrial>
we need to do something about AVStream.attached_pic too
<jamrial>
it's still an avpacket and not a pointer to one
<King_DuckZ>
thanks for the mpv info, I'm still lost with all this code, it's all new to me, really keen on learning as I've always wanted to contribute so any shred of info is much appreciated :)
Workl has quit [Ping timeout: 252 seconds]
<JEEB>
get the dump first with the problematic time frame
<JEEB>
if it breaks all things, at least it's common enough
<JEEB>
and thus replaying the problematic time frame should then cause it to happen
<elenril>
jamrial: yeah, and we also want to get rid of MEDIA_TYPE_ATTACHMENT
<elenril>
most likely at the same time
<dukesook>
Hello, I am subscribed to the FFmpeg mailing list and tried to submit a contribution by mailing the format-patch to ffmpeg-devel@ffmpeg.org. How can I check the status of my contribution? Is it possible that it got lost in the weeds?
<dukesook>
That is correct, it is a WIP (work in progress).
Krowl has quit [Read error: Connection reset by peer]
<dukesook>
I'm hoping to get feedback on int.
<dukesook>
I'm hoping to get feedback on it.
<King_DuckZ>
thanks, checking if it's a USE flag on vlc... I'll find it ;)
<dukesook>
Should I just wait until someone gets around to reviewing it? On average, how long could I expect to wait for someone to review it?
mkver has quit [Remote host closed the connection]
mkver has joined #ffmpeg-devel
<dukesook>
Is anyone here familiar with the FFmpeg patch submission process?
<BtbN>
send patch to ML, and respond to responses
<Daemon404>
a WIP / non-functioning patch isnt really suitable for the list usually
<dukesook>
Okay, is there a place where WIP code can be reviewed for feedback?
<Daemon404>
for specific help writing stuff, you can ask here
<BtbN>
you can send RFC patches if they're decently developed
<compnn>
dukesook, might take some time for your patch to be reviewed. most devs are just doing this as a hobby.
<Daemon404>
yeah i am considering RFC and WIP different.
<dukesook>
Sorry, what does RFC stand for?
<compnn>
request for comment
<Daemon404>
request for comment, e.g. for things which may be contentious
<dukesook>
compnn
<dukesook>
If it takes some time for the devs to review, then that's good to know. I can wait patiently until they get around to it. I just wanted to make sure that there was nothing else on my end that I was supposed to do.
<dukesook>
What I submit to the mailing list, is there a way to denote that the submission is a WIP or RFC? For example, should "RFC" be in the subject?
<Daemon404>
you need to be clear on what specific sort of feedback or help your are looking for, if your patch is a WIP
<Daemon404>
there just isnt much to comment otherwise
<dukesook>
Daemon404 Okay, thanks for letting me know. I simply submitted my WIP patch with no comments. I'll make sure to give more details next time.
dukesook has quit [Quit: Client closed]
cone-434 has joined #ffmpeg-devel
<cone-434>
ffmpeg Anton Khirnov master:1ebd521a4e50: fftools/ffmpeg_enc: stop using OutputStream in hw_device_setup_for_encode()
<cone-434>
ffmpeg Anton Khirnov master:70f7bbeade57: fftools/ffmpeg_enc: add an AVClass to Encoder
<cone-434>
ffmpeg Anton Khirnov master:78170120ca4a: doc/ffmpeg: improve wording in the description section
<cone-434>
ffmpeg Anton Khirnov master:238f439992f7: fftools/ffmpeg_enc: do not set AVStream timebase directly
<cone-434>
ffmpeg Anton Khirnov master:6525fe4e773b: fftools/ffmpeg_enc: remove unnecessary pointer references from enc_open()
<cone-434>
ffmpeg Anton Khirnov master:78038d51c5ba: fftools/ffmpeg_enc: do not set output stream codec parameters directly
<cone-434>
ffmpeg Anton Khirnov master:7f7fe2a10bda: fftools/ffmpeg_enc: move set_encoder_id() to ffmpeg_mux_init
<cone-434>
ffmpeg Anton Khirnov master:e3e66b14af9a: fftools/ffmpeg_enc: don't write frame rate/SAR to AVStream directly
<cone-434>
ffmpeg Anton Khirnov master:cefc7d1ff448: fftools/ffmpeg_filter: clarify error message
<cone-434>
ffmpeg Anton Khirnov master:ac578ccb8ec4: fftools/ffmpeg_filter: drop a redundant check
<cone-434>
ffmpeg Anton Khirnov master:addc29f67ae5: fftools/ffmpeg_filter: stop accessing OutputStream.[max_]frame_rate
<cone-434>
ffmpeg Anton Khirnov master:72cd0c20da3a: fftools/ffmpeg_filter: drop the OutputStream parameter to ofilter_bind_ost()
<cone-434>
ffmpeg Anton Khirnov master:d103b61cd849: fftools/ffmpeg_filter: remove remaining OutputStream usage in init_simple_filtergraph()
ngaullie has quit [Ping timeout: 245 seconds]
___nick___ has quit [Ping timeout: 245 seconds]
___nick___ has joined #ffmpeg-devel
<King_DuckZ>
nice, people have uncovered several gpl violations in winamp's code, have a look at issue 265
<King_DuckZ>
it's going wild
<King_DuckZ>
they started all cocky "uh yeah you contribute to us and you'll be happy for the honour" and 2 days later they're in trouble with dolby, the fsf, shoutcast and a bunch more folks
arbitercoin has quit [Ping timeout: 252 seconds]
feiw1 has quit [Ping timeout: 255 seconds]
iive has joined #ffmpeg-devel
averne has joined #ffmpeg-devel
rvalue- has joined #ffmpeg-devel
rvalue has quit [Ping timeout: 245 seconds]
darkapex has quit [Remote host closed the connection]
darkapex has joined #ffmpeg-devel
rvalue- is now known as rvalue
<Daemon404>
gmail seems to be marking an increasingly large number of ML mails as spam
<Daemon404>
and not just ffmpeg-devel, vlc and x265 too
<jamrial>
Daemon404: not for me at least
Warcop has joined #ffmpeg-devel
<haasn>
in trouble with dolby?
<haasn>
may god have mercy on their souls
<haasn>
I can hear the typewriters from here
<Lynne>
that issue author wanted the cops called practically, and provided no links
<Lynne>
sketchy
<Lynne>
but there is an understanding between those who do open source, you never call dolby upon someone else
some02 has joined #ffmpeg-devel
rvalue has quit [Remote host closed the connection]
rvalue has joined #ffmpeg-devel
<Daemon404>
jamrial, been getting worse for months for me
<Daemon404>
i have no idea why
hbbs has quit [*.net *.split]
nevcairiel has quit [*.net *.split]
sudden has quit [*.net *.split]
odrling has quit [*.net *.split]
King_DuckZ has quit [*.net *.split]
rodeo has quit [*.net *.split]
frankplow has quit [*.net *.split]
cosminaught has quit [*.net *.split]
sfan5 has quit [*.net *.split]
Guest2164 has quit [*.net *.split]
hbbs has joined #ffmpeg-devel
King_DuckZ has joined #ffmpeg-devel
Guest2164 has joined #ffmpeg-devel
odrling has joined #ffmpeg-devel
nevcairiel has joined #ffmpeg-devel
rodeo has joined #ffmpeg-devel
frankplow has joined #ffmpeg-devel
sfan5 has joined #ffmpeg-devel
cosminaught has joined #ffmpeg-devel
<elenril>
gmail is trying to tell you something
<Daemon404>
"switch to gitlab"?
* Daemon404
runs
<elenril>
consider your life choices moar liek
cone-434 has quit [Quit: transmission timeout]
___nick___ has quit [Ping timeout: 248 seconds]
<Lynne>
gitlab is worse
<Lynne>
it has to load a hundred megs of .js for that chatbot
<Lynne>
and syntax highlighting is at least 50 megs worth of frameworks
cone-638 has joined #ffmpeg-devel
<cone-638>
ffmpeg James Almer master:d55ab2ba9b16: avutil/iamf: fix doxygen
<cone-638>
ffmpeg James Almer release/7.1:c21472ec31bb: avutil/iamf: fix doxygen
<cone-638>
ffmpeg James Almer release/7.0:45ecf80f0e28: avutil/iamf: fix doxygen
<jamrial>
wbs: it looks mostly non invasive save for the "s->nb_unit = i + 1;" line
<jamrial>
does it have no effect at all with decoding with other hwaccels?
<wbs>
jamrial: yep; I would expect that none of the existing hwaccels touch s->nb_unit; this just sets it to the same value that will be set soon afterwards
<jamrial>
should be ok then, but maybe add a comment to start_unit in the header to explain why it's there
<wbs>
sure
<michaelni>
jamrial, regenerated
Krowl has joined #ffmpeg-devel
vipyne has quit [Quit: Leaving.]
<jamrial>
michaelni: thanks
Krowl has quit [Read error: Connection reset by peer]
<cone-638>
ffmpeg Martin Storsjö master:067abbfe9dbf: aarch64: Detect I8MM on Windows via SVE-I8MM
<cone-638>
ffmpeg Martin Storsjö master:e6e56fd7a773: configure: Add detection of assembler support for SVE/SVE2
<cone-638>
ffmpeg Martin Storsjö master:e6eabb7ce757: aarch64: Add CPU feature flags for SVE and SVE2
<cone-638>
ffmpeg Martin Storsjö master:b1ee2af8432e: aarch64: Print the SVE vector length in libavutil/tests/cpu.c
<cone-638>
ffmpeg Martin Storsjö master:c65a294f7944: checkasm: Print the SVE vector length at startup
<jdarnley>
Marth64: nice work on the dvd demuxer. Got it done better and in less time than my own dvd support.
<Marth64>
jdarnley: thank you. just one minor hiccup left and I'm ready to let it mature finally
ccawley2011 has quit [Read error: Connection reset by peer]
<Marth64>
looking forward to 7.1 will run a bunch of random tests this weekend
mkver has quit [Ping timeout: 260 seconds]
IndecisiveTurtle has quit [Remote host closed the connection]