I'm not sure exactly what you mean, but yes as near as I can tell it only freezes after packet loss. It was hard to tell when it was freezing because there wasn't a lot of motion in the video but I'm going to play with it some more today and try to identify more solid patterns.
On Wed, Jun 27, 2012 at 11:16 PM, Alex Cohn <[email protected]> wrote: > On Thu, Jun 28, 2012 at 4:17 AM, Michael Bradshaw > <[email protected]> wrote: >> >> On Wed, Jun 27, 2012 at 6:26 PM, Tim Pitman <[email protected]> wrote: >> > Interesting. However, I'm using x264 with --intra-refresh and --tune >> > zerolatency (no b frames). >> >> Sorry, I missed that part. > > At any rate, it seems that in some cases of corrupted input, the > decoder simply decides to stop producing got_pictue. > > On Wed, Jun 27, 2012 at 5:58 PM, Tim Pitman <[email protected]> wrote: >> It no longer crashes, but instead seems to freeze for a few seconds, >> which is definitely a big step in the right direction. > > Do I understand correctly that this happens not at the beginning of > the stream (which would be a result of non-zero latency in the > source), but after packet loss? > > Alex > _______________________________________________ > Libav-user mailing list > [email protected] > http://ffmpeg.org/mailman/listinfo/libav-user _______________________________________________ Libav-user mailing list [email protected] http://ffmpeg.org/mailman/listinfo/libav-user
