ChanServ changed the topic of #ffmpeg to: Welcome to the FFmpeg USER support channel | Development channel: #ffmpeg-devel | Bug reports: https://ffmpeg.org/bugreports.html | Wiki: https://trac.ffmpeg.org/ | This channel is publically logged | FFmpeg 7.1.1 is released
YUiNA has quit [Ping timeout: 244 seconds]
lucasta has quit [Quit: Leaving]
YUiNA_ has quit [Remote host closed the connection]
Traneptora has joined #ffmpeg
Traneptora has quit [Remote host closed the connection]
cheapie has quit [Ping timeout: 248 seconds]
cheapie_ has joined #ffmpeg
minimal has quit [Quit: Leaving]
cheapie_ is now known as cheapie
Shine_ has joined #ffmpeg
<Trel>
furq: ah, no way to make ffmpeg intercept them and treat them accordingly without directly passing to the codec like that?
<furq>
depends on the codec but apparently not for x265
<aaabbb>
what kind of progress do you want it to output?
Shine_ has quit [Read error: Connection reset by peer]
derjanni has quit [Quit: ZNC 1.8.2+deb2ubuntu0.1 - https://znc.in]
derjanni has joined #ffmpeg
beastd has quit [Ping timeout: 260 seconds]
Copy_of_nrg has joined #ffmpeg
nrg has quit [Ping timeout: 265 seconds]
de-facto has quit [Ping timeout: 264 seconds]
Copy_of_nrg is now known as nrg
de-facto has joined #ffmpeg
JanC is now known as Guest6826
Guest6826 has quit [Killed (lead.libera.chat (Nickname regained by services))]
JanC has joined #ffmpeg
beastd has joined #ffmpeg
derjanni_ has joined #ffmpeg
derjanni has quit [Ping timeout: 252 seconds]
technonerd has quit [Remote host closed the connection]
derjanni_ has quit [Ping timeout: 244 seconds]
derjanni has joined #ffmpeg
beastd has quit [Ping timeout: 268 seconds]
beastd has joined #ffmpeg
technonerd has joined #ffmpeg
maxim_d33 has quit [Ping timeout: 248 seconds]
maxim_d33 has joined #ffmpeg
treefrob has quit [Ping timeout: 260 seconds]
jiffy__ has quit [Ping timeout: 244 seconds]
user_oreloznog has joined #ffmpeg
_whitelogger has joined #ffmpeg
treefrob has joined #ffmpeg
YuGiOhJCJ has quit [Quit: YuGiOhJCJ]
System_Error has quit [Remote host closed the connection]
System_Error has joined #ffmpeg
JanC is now known as Guest849
Guest849 has quit [Killed (tantalum.libera.chat (Nickname regained by services))]
JanC has joined #ffmpeg
FH_thecat has joined #ffmpeg
CHR0N0S has joined #ffmpeg
hjckr has quit [Ping timeout: 252 seconds]
hjckr has joined #ffmpeg
xx has joined #ffmpeg
lavaball has joined #ffmpeg
hjckr has quit [Ping timeout: 260 seconds]
hjckr has joined #ffmpeg
rsx has joined #ffmpeg
jmcantrell has quit [Ping timeout: 252 seconds]
CHR0N0S has quit [Quit: CHR0N0S]
Blacker47 has joined #ffmpeg
damian101_ has joined #ffmpeg
damian101 has quit [Ping timeout: 244 seconds]
SuicideShow has quit [Ping timeout: 244 seconds]
SuicideShow has joined #ffmpeg
Sketch has quit [Remote host closed the connection]
Sketch has joined #ffmpeg
<ePirat>
BtbN, the equation parser does not even has a concept of global variables per filtergraph yet
YUiNA has joined #ffmpeg
fling has quit [Remote host closed the connection]
fling has joined #ffmpeg
YUiNA_ has joined #ffmpeg
YUiNA has quit [Ping timeout: 260 seconds]
yans has joined #ffmpeg
Bertl has quit [Remote host closed the connection]
xx has quit [Ping timeout: 264 seconds]
xx has joined #ffmpeg
Shine_ has joined #ffmpeg
zsoltiv_ has quit [Ping timeout: 252 seconds]
zsoltiv_ has joined #ffmpeg
snoriman has joined #ffmpeg
<snoriman>
Hi, will av_read_frame() block when it's reading from a network stream?
<JEEB>
yes, it will block until IO -> demuxer -> AVPacket. look up `rw_timeout` AVOption that works with TCP based protocols (for whatever reason UDP protocol does read the value, but then overrides it with the `timeout` AVOption).
<JEEB>
but do note that rw_timeout/timeout may not help if data is actually flowing but there are no actual media packets in the input. I've had that happen quite a few times
<snoriman>
Ah interesting, thanks JEEB! I've just started an experimental implementation and will check out the timeout.
<JEEB>
rw_timeout is the thing that works with most things, and then due to a boog not with UDP
<JEEB>
but for example if you receive MPEG-TS but only metadata packets, that will still block as the IO layer is working OK
<JEEB>
although that might have improved, but at least I've seen that on versions from last year...
<snoriman>
Ah ok that's good to know. I guess I could check what of packets were received and how long ago the last media packet arrived and use that to timeout manually.
<JEEB>
metadata packets as in stuff that the demuxer doesn't return at all. so you are getting zero AVPackets, but there is actual IO traffic, so there is no IO timeout
<JEEB>
(which is what rw_timeout is)
<snoriman>
Ah I see. Ok once I've got some code working I'll look closer into that, thanks.
<snoriman>
I'm creating an test-app where I want to control which frames should be decoded. E.g. lets say tath I only want to decode one frame, every 100ms. What would be a good approach?