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.1 has been released! | Please read ffmpeg.org/developer.html#Code-of-conduct
<cone-010>
ffmpeg Marvin Scholz master:fb38d8759b00: avformat/tls_openssl: use TLS_[client|server]_method
<cone-010>
ffmpeg Marvin Scholz master:019ca5f01370: avformat/tls_openssl: use SSL_CTX_set_min_proto_version
Teukka has quit [Ping timeout: 260 seconds]
System_Error has joined #ffmpeg-devel
<fflogger>
[newticket] bermond: Ticket #11659 ([avutil] Regression: cannot use frames with alpha channel on vulkan) created https://trac.ffmpeg.org/ticket/11659
<kierank>
ePirat: lol
cone-010 has quit [Quit: transmission timeout]
System_Error has quit [Remote host closed the connection]
jamrial has quit []
System_Error has joined #ffmpeg-devel
System_Error has quit [Remote host closed the connection]
System_Error has joined #ffmpeg-devel
TheVibeCoder has joined #ffmpeg-devel
mkver has joined #ffmpeg-devel
Teukka has joined #ffmpeg-devel
Teukka has quit [Changing host]
Teukka has joined #ffmpeg-devel
ngaullier has joined #ffmpeg-devel
pelotron has quit [Ping timeout: 244 seconds]
pelotron has joined #ffmpeg-devel
Anthony_ZO has quit [Ping timeout: 245 seconds]
mkver has quit [Ping timeout: 248 seconds]
mkver has joined #ffmpeg-devel
<TheVibeCoder>
haasn: is there fast way to check that YUV (arbitrary colorspace) is in valid range? (so that converting such YUV to RGB get all r/g/b be within [0,1])
blb has quit [Ping timeout: 245 seconds]
blb has joined #ffmpeg-devel
MisterMinister has quit [Remote host closed the connection]
MisterMinister has joined #ffmpeg-devel
microchip_ has quit [Quit: There is no spoon!]
microchip_ has joined #ffmpeg-devel
microchip_ has quit [Quit: There is no spoon!]
microchip_ has joined #ffmpeg-devel
mkver has quit [Ping timeout: 244 seconds]
mkver has joined #ffmpeg-devel
microchip_ has quit [Quit: There is no spoon!]
mkver has quit [Ping timeout: 260 seconds]
mkver has joined #ffmpeg-devel
microchip_ has joined #ffmpeg-devel
microchip_ has quit [Remote host closed the connection]
microchip_ has joined #ffmpeg-devel
<Traneptora>
TheVibeCoder: rgb -> yuv maps the unit cube to a parallelapiped, so why not just check if the point is in that parallelapiped
<Traneptora>
might be easier to just convert to RGB and see if it's within [0, 1] than to do anything fancy
System_Error has quit [Remote host closed the connection]
System_Error has joined #ffmpeg-devel
phr3ak has joined #ffmpeg-devel
MisterMinister has quit [Ping timeout: 252 seconds]
<phr3ak>
When the TCP connection is closed by the remote side, ffplay does not detect the disconnection and continues playback as if the stream were still active. tcp:// (ogg stream)
jamrial has joined #ffmpeg-devel
hpkn has quit [Remote host closed the connection]
ccawley2011 has joined #ffmpeg-devel
minimal has joined #ffmpeg-devel
ShadowJK has quit [Ping timeout: 244 seconds]
ShadowJK has joined #ffmpeg-devel
putacho has joined #ffmpeg-devel
microchip_ has quit [Ping timeout: 244 seconds]
System_Error has quit [Remote host closed the connection]
<cone-048>
ffmpeg Marvin Scholz master:74aa71087968: lavf: add and use AVRTCPSenderReport struct
<ePirat>
do I need to bump minor or micro after adding an side data type?
<TheVibeCoder>
macro bump
System_Error has joined #ffmpeg-devel
<jamrial>
ePirat: minor
<jamrial>
it's a new entry in an enum
<ePirat>
jamrial, I thought so too but you recently only bumped micro
<ePirat>
so I was uncertain what I should do
<jamrial>
that was a mistake. not sure if i did it or BtbN, but it's harmless
<ePirat>
yeah minor was anyway bumped right after for a different reason so
zsoltiv has quit [Ping timeout: 260 seconds]
zsoltiv_ has quit [Ping timeout: 252 seconds]
<cone-048>
ffmpeg Marvin Scholz master:eca477da523b: avcodec: bump minor after adding AV_PKT_DATA_RTCP_SR
<cone-048>
ffmpeg Marvin Scholz master:934e1c23b056: APIchanges: Add entry for AV_PKT_DATA_RTCP_SR
<BtbN>
I had to re add the version updates, since the updates had long been rebased away. Probably got something in the wrong order there.
ccawley2011_ has joined #ffmpeg-devel
ccawley2011 has quit [Ping timeout: 248 seconds]
<fflogger>
[newticket] LigH: Ticket #11660 ([ffmpeg] Importing ffmetadata file into MP4 supports chapters but ignores global tags) created https://trac.ffmpeg.org/ticket/11660
<TheVibeCoder>
i did today my first vibe coding session!
<TheVibeCoder>
it was very successful
MisterMinister has joined #ffmpeg-devel
ngaullier has quit [Remote host closed the connection]
System_Error has quit [Remote host closed the connection]
<ePirat>
ok whatever lets keep av_dict_get non-const I dont care anymore… this is ridiculous
<mkver>
ePirat: When parsers are used that introduce a delay (e.g. because the parser does not get complete frames), then parsing in lavf (specifically parse_packet() in demux.c) can break the packet<->side data correspondence. Did you test whether it works for the side data you just added?
<ePirat>
mkver, I have no idea how to test this
<mkver>
You look at the output of avformat and check whether the side data matches what you expect?
<ePirat>
this is rtsp
<ePirat>
the server send these whenver
<ePirat>
its not tied directly to a specific packet
<mkver>
You may need to add some logging to the place where the demuxer adds the side data.
<ePirat>
I did verify I properly get the side data after I add it
<ePirat>
so as far as I can tell I am at lest never loosing any
<mkver>
What formats did you test?
<ePirat>
opus, h264 and aac iirc
<ePirat>
would it make a difference though given its all rtp?
<mkver>
Does rtsp send complete packets (i.e. what FFmpeg puts into an AVPacket)?
<ePirat>
as far as I can tell it queues packets and sends an AVPacket (in rtp_parse_one_packet) once it has something to send
<ePirat>
it does mean that an SR can be slightly "late" as it needs to wait on the next AVPacket to get attached to that but I dont really see a way around that as thats just how side data works.
System_Error has joined #ffmpeg-devel
<BtbN>
hm, I'm not sure about the patch Jack sent me. It generally seems sensible, but also volatile and a functional change.
<BtbN>
Basically, when udp.c is used to send something out, and no remote addr to send it to had been set yet, it makes udp.c set it to the last address a packet was received from.
<BtbN>
i.e. when it'd otherwise throe an error, implicitly set the destination address to whoever last sent something
<beastd>
BtbN: yeah, feels strange to infer it from the last received packet
<BtbN>
I do the same in the schannel_dtls code, but that's a layer above UDP, and is effectively building a connection
cone-048 has quit [Quit: transmission timeout]
<BtbN>
But doing that right in udp.c seems off to me
<BtbN>
it unsurprisingly is to fix some issue elsewhere :D
<BtbN>
not sure if WHIP or something else
ccawley2011_ has quit [Ping timeout: 276 seconds]
cone-827 has joined #ffmpeg-devel
<cone-827>
ffmpeg Dawid Kozinski master:219f234e077f: avformat/mov: add support for APV streams
<ePirat>
mkver, so IIUC looking at the demux code, it seems side data wouldnt be lost but just possibly on a different packet?
<mkver>
IIRC the side data of the first packet output by the demuxer would get lost (and the returned packet gets the side data from the next packet (or rather, the packet that makes the parser return something)).
<ePirat>
ok, I'll do a bit more testing later then
<ePirat>
mkver, also thanks for pointing out the lack of checks for the av_dict_set stuff, I will send a fix shortly