[FFmpeg-trac] #4893(avcodec:reopened): FFmpeg stops outputting frames unexpectedly and indefinitely on "bad" h264 over UDP stream

FFmpeg trac at avcodec.org
Thu Mar 22 16:54:15 EET 2018

#4893: FFmpeg stops outputting frames unexpectedly and indefinitely on "bad" h264
over UDP stream
             Reporter:  superware    |                    Owner:
                 Type:  defect       |                   Status:  reopened
             Priority:  important    |                Component:  avcodec
              Version:  git-master   |               Resolution:
             Keywords:  h264         |               Blocked By:
  regression                         |  Reproduced by developer:  1
             Blocking:               |
Analyzed by developer:  0            |
Changes (by IsraelRobotnick):

 * status:  closed => reopened
 * resolution:  fixed =>


 Hi All,

 I'm having the same problem.
 I repeat a stream for days simluating a camera on udp to an ffmpeg server
 that repeats that stream. It works great for hundreds of times, then
 unexpectedly the server runs into an unending loop of errors.
 Seems like it looses a byte and can't recover from it.
 The simulated streams keeps going great, it's only the ffmpeg server that
 If I restart the ffmpeg server, it starts fine and you can see the
 (I added a log showing the broken serversending errors in an unending loop
 just as superware mentioned)

 I'm using ffmpeg static 3.4.1 version which should be updated with the
 fixes cenoyos mentioned.
 It always happens, but always unexpectedly, on a stream which is perfectly
 fine just had a long run. (so adding it here won't help anybody)

 I wonder maybe the problem is with how I config the ffmpeg on my
 "ffmpeg -i -f mpeg1video -b:v 1200k -an -r 30 -"

 I checked, the resolution, fps and BR are just as the input source sends
 it, and the bandwidth isn't a problem (it's on a lan network).
 Maybe I need to add a minimal buffer? (since I want it to be live content,
 I can't make a big buffer that will delay the stream, I rather have broken
 Or might it be something else? maybe a param that tells ffmpeg to skip
 broken bytes and restart?



Ticket URL: <https://trac.ffmpeg.org/ticket/4893#comment:34>
FFmpeg <https://ffmpeg.org>
FFmpeg issue tracker

More information about the FFmpeg-trac mailing list