> > > Try to run the code in valgrind. If it is memory corruption it will spot > it quickly. > > Btw if you are using udp make sure you set the system buffers to be large > enough. > > > Hey Luca
After a bit more looking around, I think I pinpointed the problem. Unfortunately Valgrind did not show the memory leak, because it runs a lot slower and in-fact cant run this live. I think the problem is that libav does performs some sort of buffer overflow If the input stream is not processed quickly enough. I was able to replicate this behaviour with the following code: http://pastebin.com/gtj7774K Line 135 being the main culprit It seems that If you take too long between your av_open_file and your av_frame_read (and potentially something to do with the find_stream_info) I guess some buffer overflow occurs which starts messing up everything else. In the meantime I have fixed this by opening the stream once to query it for input details, closing it, then setting up all my output stuff which takes 3-10 seconds, and then again re-openning the stream and reading it immediately. Perhaps this could be fixed by increasing the buffer size? If so, Is there anyway I could manually force a larger buffer size for the input? To set the scene a little, I'm dealing with a 10Mbit mpegts stream, and this gap between the open and the read can be up to 10 seconds. So perhaps something like 20Mbyte may be needed. On a final note, I have already increased my system UDP buffer to 50Meg + Regards, Evgeny
_______________________________________________ libav-api mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-api
