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 has been released! | Please read ffmpeg.org/developer.html#Code-of-conduct
mkver has quit [Ping timeout: 268 seconds]
iive has quit [Quit: They came for me...]
<ePirat>
BtbN, took me forever to figure out how to get stuff working when I made the doxxygen makefile fix patch…
<BtbN>
I have given up for tonight
<BtbN>
It's the weirdest failure and I just can't understand it
<BtbN>
https://bpa.st/LXEQ like... why is it acting in that way. The exact same command is run in both cases
<BtbN>
So this has to be due to the fact it's running from inside a Makefile, but... yeah, no clue
thilo has quit [Ping timeout: 245 seconds]
thilo has joined #ffmpeg-devel
System_Error has quit [Remote host closed the connection]
System_Error has quit [Remote host closed the connection]
System_Error has joined #ffmpeg-devel
<haasn>
there was some discussion a while ago about whether we should re-attach all packet-level metadata to frames decoded from that packet
<haasn>
unrelated; does libavcodec have to be robust against being linked to a version of libavutil older than the headers it was compiled against?
<haasn>
I think I asked this before and the answer was no
<haasn>
only newer versions
<nevcairiel>
older versions of avutil dont have to be supported, newer ones do
<nevcairiel>
which is still a bit silly, but better then both directions, which would be impossible =P
<haasn>
not without runtime checks :p
<haasn>
but yeah, makes sense
System_Error has quit [Remote host closed the connection]
<BtbN>
wtf, fedex just sent me a customs info mail about the package I already got
<another|>
BtbN: sure. they probably want money
<BtbN>
They already wanted money, in cash, when I got the package
<BtbN>
that mail would have been nice days BEFORE they delivered it
<another|>
oh, right
<another|>
you wrote about that
cone-917 has joined #ffmpeg-devel
<cone-917>
ffmpeg Derek Buitenhuis master:6d89fd4c27b2: avformat/http: Rename parse_set_cookie_expiry_time to parse_http_date
<cone-917>
ffmpeg Derek Buitenhuis master:2d5fa816fb94: avformat/http: Add support for Retry-After header
<haasn>
is there any way to add a fate test for filters modifying side data?
<haasn>
crc/framecrc ignore side data
<haasn>
metadata=print doesn't print side data
<haasn>
showinfo can only print to stdout (which fate ignores)
<haasn>
I guess the only way is to mux to something like rawvideo+nut and then ffprobe the resulting file?
<JEEB>
almost sounds like a basic API test being useful which calls lavfi or so, and then outputs to stdout the received AVFrames' relevant information
<JEEB>
alternatively adding such export to ffmpeg, but that would more or less standardize that format as something end users might utilize :P
<haasn>
clearly we need to consolidate ffprobe and showinfo into the same infrastructure and then expose it as a filter and/or output format
<haasn>
-f ffprobe
<haasn>
I guess I'll just ignore the problem for now, I wasted already more time to try and add a fate test than to write the entire patchset I'm trying to test
<JEEB>
yea, ffprobe for lavfi filter chains doesn't sound too bad, either by exposing filter chains in ffprobe or something else
<JEEB>
since I think showinfo is only there since that was not the case
<JEEB>
but yea, quite wider than your work that you want to get done :D
Krowl has quit [Read error: Connection reset by peer]