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 8.0.1 has been released! | Please read ffmpeg.org/developer.html#Code-of-conduct
minimal has quit [Quit: Leaving]
pengvado has quit [Server closed connection]
pengvado has joined #ffmpeg-devel
Traneptora has joined #ffmpeg-devel
Venemo_ has quit [Server closed connection]
Venemo has joined #ffmpeg-devel
michaelni has quit [Server closed connection]
michaelni has joined #ffmpeg-devel
zsoltiv__ has quit [Read error: Connection reset by peer]
zsoltiv has quit [Read error: Connection reset by peer]
zsoltiv has joined #ffmpeg-devel
zsoltiv has quit [Ping timeout: 264 seconds]
zsoltiv has joined #ffmpeg-devel
zsoltiv_ has joined #ffmpeg-devel
j-b has quit [Server closed connection]
j-b has joined #ffmpeg-devel
gnafu has quit [Server closed connection]
gnafu has joined #ffmpeg-devel
<Yalda>
(loundnorm) I feel it should be able to read its own output as input, whether stats or the main output, so manual parsing intermediate is not necessary
jamrial has quit []
funkylab has quit [Server closed connection]
funkylab has joined #ffmpeg-devel
kasper93 has quit [Server closed connection]
kasper93 has joined #ffmpeg-devel
Kimapr has quit [Server closed connection]
Kimapr has joined #ffmpeg-devel
MisterMinister has quit [Ping timeout: 245 seconds]
MisterMinister has joined #ffmpeg-devel
jb_ has quit [Ping timeout: 256 seconds]
jb has joined #ffmpeg-devel
welder has quit [Server closed connection]
welder has joined #ffmpeg-devel
ShadowJK has quit [Server closed connection]
ShadowJK has joined #ffmpeg-devel
Kwiboo has quit [Server closed connection]
Kwiboo has joined #ffmpeg-devel
tortoise has quit [Server closed connection]
tortoise has joined #ffmpeg-devel
afishhh has quit [Server closed connection]
afishhh has joined #ffmpeg-devel
mark4o has joined #ffmpeg-devel
markh has quit [Ping timeout: 245 seconds]
mark4o is now known as markh
Venemo has quit [Changing host]
Venemo has joined #ffmpeg-devel
rom1v has quit [Server closed connection]
rom1v has joined #ffmpeg-devel
mkver has joined #ffmpeg-devel
acryo has quit [Server closed connection]
acryo has joined #ffmpeg-devel
acryo has joined #ffmpeg-devel
acryo has quit [Changing host]
sudden has quit [Server closed connection]
sudden has joined #ffmpeg-devel
printfdebugging has quit [Read error: Connection reset by peer]
printfdebugging has joined #ffmpeg-devel
ngaullier has joined #ffmpeg-devel
kasper93_ has quit [Server closed connection]
kasper93_ has joined #ffmpeg-devel
vriska has quit [Server closed connection]
vriska has joined #ffmpeg-devel
<fjlogger>
[FFmpeg/FFmpeg] Pull request #21771 opened: av_filter/vf_opencolorio: libopenimage was added in error as part of the ocio filter, just cleaning it up. (https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/21771) by richardssam
<Yalda>
Hi ePirat: since loudnorm can write the measurements to json, etc; it would be nice if the same output can be read in from a file for the second pass without needing another tool to parse then re-enter as filter args
<Yalda>
Unless I missed a way I always felt this was extra work
<ePirat>
Ah, yeah
<Yalda>
We do have filters that read in/out files but I'm hesitant to do more of that since I don't believe there is a pattern to check file allowlist from filters
<Yalda>
In theory though it would be great if second pass was just loudnorm=in_params=pass1.json
<JEEB>
yea the best would be if the cli would handle the files
<Yalda>
vs. pass 1 -> rip json from stderr -> parse -> re-enter
<Yalda>
yea
<JEEB>
and pass on the parameters to the filter
<JEEB>
heck, if it was the cli you could even do stuff like pipe the output of pass1 into another process :P
<Yalda>
yes that would be great, i'm currently using python as an intermediate
<ePirat>
JEEB, all that is needed for that is to use a avio context instead of a filename
<JEEB>
alternatively it's a muxer that outputs the attached side data
<ePirat>
which we already do in some places anyway
<JEEB>
since a lot of side data is in either the context or frames
<JEEB>
(similar to some of the text based muxers we already have)
<JEEB>
ePirat: the whole thing is that you want to have a singular location to handle the parsing and output, similar to ffprobe
<JEEB>
having each filter do it separately in its own little island does not sound too great
<JEEB>
although the filter could provide the mapping, so that it then gets an avdictionary or something fed to it, from which it can then parse the options (alternatively it gets auto-converted to the required AVOptions)
<ePirat>
I mean we already have dicts in avoptions so we could just have a generic way to serialize/deserialize dicts on the CLI, like we already have to pass file contents for string options
<ePirat>
of course making this work generically in avfilter is a bit tricky
<ePirat>
as the filter options are handled directly by it without fftools interfering
<JEEB>
fftools already does input mappings etc, so fftools are already playing around the filter chain
<Yalda>
i was also leaning on a generic serialize / deserialize intermediate format and api
<JEEB>
also another thing that came to mind (not sure if a good idea or not), would be to have the thing (dict or whatever) be attached to the first AVFrame of whatever input stream it is mapped against
<JEEB>
that way you can for example map it against the audio stream that you care about
<JEEB>
then it will receive that side data as part of the first AVFrame
<JEEB>
Yalda: yea that is kinda required for text<->side data
<JEEB>
since a lot of side data is currently not possible to set via cli
<JEEB>
one of the few exceptions is the rotation one
<JEEB>
which I asked whether people wanted separate options or dict, they wanted separate options (for rotation and flip)
<JEEB>
of course those strings are not exactly an easily parse'able key=value pair key, but that can be added into the AVSideDataDescriptor if a separate string is required enough
_av500_ has quit [Ping timeout: 244 seconds]
<JEEB>
and also then a parser func pointer can also in theory be added to something like that.
<ePirat>
michaelni, should I make a milestone for the 8.1 branching?
<michaelni>
probably a good idea
<michaelni>
i dont really know about forgejo milestones though so dunno what to do with it
Guest63 has joined #ffmpeg-devel
<nevcairiel>
generally the idea is to link issues/PRs to it to track what you want to have in it thats not done yet
ubitux has quit [Ping timeout: 252 seconds]
ubitux has joined #ffmpeg-devel
irisfreckles1 has joined #ffmpeg-devel
<fjlogger>
[FFmpeg/FFmpeg] Pull request #21771 merged: av_filter/vf_opencolorio: libopenimage was added in error as part of the ocio filter, just cleaning it up. (https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/21771) by Lynne
<ePirat>
Why does it say "This pull request doesn't have enough approvals yet. 0 of 1 approvals granted." for https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/21773 when it literally shows Lynne approved it…
<ePirat>
Ah, because I rebased apparently...
<ePirat>
thats confusing UI :D
witchymary has quit [Remote host closed the connection]
<BtbN>
ePirat: if you rebase, the approval goes stale
<BtbN>
it does make sense, since Forgejo can't know if you rebased it to now contain something completely different
<BtbN>
Though there is also a bug where sometimes reviews are stale despite no rebase happening ever
<BtbN>
haven't figured out what causes that so far
<ePirat>
yeah its mostly the UI being a bit suboptimal not mentioning that the approval is for the specific state / sha, so it looks like its for the general PR no matter what...
<BtbN>
Someone can also post a review that's stale from the get-go, if they reviewed a pre-rebase state of the PR, but the PR then got rebased before they hit submit
<BtbN>
ePirat: the checkmark turns yellow if it's stale
<BtbN>
and you can't merge it anymore, obviously
<ePirat>
well the tiny one does, not the giant one right in the MR view :P
<ePirat>
would be nice if the summary can mention that the approval was for an older version, but not sure how hard that is...
<BtbN>
I guess the intend there is that if you see a rebase after the approval, the Approval is stale
<BtbN>
but yeah, it could make the checkmarks there yellow as well
ngaullier has quit [Remote host closed the connection]
Guest33 has joined #ffmpeg-devel
Guest33 has quit [Client Quit]
<fflogger>
[editedticket] Balling: Ticket #8385 ([avformat] libavformat/aviobuf: A part of conditional expression is always true: whence != 2) updated https://trac.ffmpeg.org/ticket/8385#comment:9