BtbN 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.0 is released
rvalue has quit [Read error: Connection reset by peer]
rvalue has joined #ffmpeg
Livio has joined #ffmpeg
ttys000 has joined #ffmpeg
minimal has joined #ffmpeg
peterLustig67 has quit [Ping timeout: 250 seconds]
peterLustig67 has joined #ffmpeg
jagannatharjun has joined #ffmpeg
<acidtonic>
I have been adjusting various things with my rtsp missed packets issue, I changed rtbufsize but didn't know about buffer_size that got sent to the demuxer, now it seems much better.
<acidtonic>
I am curious if there is a way to be notified in code when ffmpeg would print those "missed x packets" messages on the console, is there a callback or something so I can know the machine isn't keeping up?
<acidtonic>
I'd like to try keeping any corrupt portions of an image from making it past the decoding and into my software. I'd rather drop frames with corruption than show them
dionysis has quit [Quit: WeeChat 3.8]
billchenchina has quit [Remote host closed the connection]
billchenchina has joined #ffmpeg
kron has quit [Quit: kron]
peterLustig67 has quit [Ping timeout: 250 seconds]
rsx has joined #ffmpeg
<acidtonic>
I was able to track the first set of issues down to udp receive buffer size problems, fixed that, but when testing with tc implementing drops, I can't detect that in my code and the bad frames get thru. Any ideas?
markizano has quit [Remote host closed the connection]
markizano has joined #ffmpeg
rsx has quit [Quit: rsx]
waeking has joined #ffmpeg
<ePirat>
acidtonic, isnt AV_FRAME_FLAG_CORRUPT set for these?
<acidtonic>
I am unfamiliar, is that on the av_frame directly?
<ePirat>
AVFrame's flags field
<JEEB>
also AVPackets so you don't send them to a decoder
<JEEB>
mpeg-ts and I don't recall which other container are able to flag those
<acidtonic>
I'm coming in rtsp -> h264 with nvidia accelerated NV12 -> swcale
<acidtonic>
so both muxer and decoder can set this?
<JEEB>
AV_PKT_FLAG_CORRUPT is the packet one
<JEEB>
I see some RTP readers set this (like VP8)
<acidtonic>
so av_read_frame -> the before av_send_packet() I should check packet AV_PKT_FLAG_CORRUPT
<acidtonic>
so avcodec_receive_frame then check frame AV_FRAME_FLAG_CORRUPT before av_hwframe_transfer_data()
<JEEB>
(you can see with `git grep "CORRUPT" -- libavformat/` in the FFmpeg tree to see which modules utilize that flag when reading input)
<JEEB>
since hwaccels override the slice decoding, not sure how much of the decoder corruption checking will work there
markizano has quit [Remote host closed the connection]
<JEEB>
but sure, you can check if you're getting it set from received AVFrames
markizano has joined #ffmpeg
<JEEB>
I'm really happy that the MPEG-TS reader flags borked packets so they can be skipped from not being fed to decoders (or if you set the avformat flag you will never get them output from the demuxer)
<JEEB>
because I have "nice" experience in decoders breaking with broken packets when they try too hard
<acidtonic>
doesn't seem to have any effect
<acidtonic>
packet->flags & AV_PKT_FLAG_CORRUPT then after receive frame frame->flags & AV_FRAME_FLAG_CORRUPT
<acidtonic>
neither coming back positive, yet the h264 side is getting corrupting from dropped frames
<JEEB>
well yea, as I noted some RTP readers are using that flag. didn't see H.264 there.
<JEEB>
but if the packet is dropped on some level, then it never appears and it wouldn't be considered corrupt (since only packets that are partial or don't pass a possible checksum check would be considered corrupt by a reader)
<JEEB>
then on the decoder level, hwaccels might not be able to flag that
<JEEB>
try with swdec
<acidtonic>
I am simply trying to not draw or pass on corrupt frames. Otherwise I am okay with dropping or slowing down until valid frames are read again
Kobaz has quit [Excess Flood]
Kobaz has joined #ffmpeg
<BtbN>
I don't think that message means corrupted frame
<BtbN>
it just means the rtp format gave up waiting for the reorder delay
<acidtonic>
well, true but when that happens I get a nasty tear half the screen or more
<acidtonic>
thats what I am trying to stop, the non accelerated code using opencv to read (ffmpeg backend) doesn't do this, yet it's slow with a noticable lag of 2-4 seconds
<acidtonic>
this code shows instant nice up to the images, but the occasional corrupt or torn image gets sent beyond into my ai processing and ruins things.
<BtbN>
I wouldn't even know how that'd possibly happen with h264
<BtbN>
like, the decoder does not decode half-frames or something
<BtbN>
Are you sure you aren't re-using broken frames or something, or ignoring a decoder failure?
<acidtonic>
I have a code example I shared here recently and no one complained I was doing something wrong.... not doing too much with this basic test case (omitting everything downstream)