On Tue, Jul 30, 2013 at 9:37 AM, Adi Shavit <[email protected]> wrote: >> Note that overrun_nonfatal will break the video output. If the network >> is very bad, and you have IDR frames sent often enough, or if you use >> an intra-refresh stream. > > Sorry, I don't understand what this means. > > > Basically, my requirements are as follows: > > 1. Decode multiple video streams simultaneously from a single MTP stream. > 2. I do not display the frames, only process the pixels. > 3. I'm not very sensitive about dropped frames. > 4. I prefer to process the frames as early as possible, even before > they would have been displayed in "playing-time". > > If the UDP network stream is bad, then just wait until you get some > proper packets/frames. > > Thanks, > Adi
My bad. Few words got dropped from the last mail. Nevermind, let us address your scenario. If your processing consistently fall behind the input stream(s), then overrun_nonfatal or increasing the cyclic buffer will not really help. You can skip h264 post-processing to save decoding time. Other than that, if you detect that your process takes too long, you should apply it only when the decoder catches up with the stream. In the worst case, if an IDR frame arrives, you can discard all frames up to IDR, and essentially start again. If you cannot configure the encoder, the latter option depends totally on the nature of your incoming stream. If you can configure the source, you should be very careful about forcing IDR frames too often: first of all, these frames take much more bandwidth, and second, they take longer to decode. Sincerely, Alex Cohn _______________________________________________ Libav-user mailing list [email protected] http://ffmpeg.org/mailman/listinfo/libav-user
