<div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><br>
Try to run the code in valgrind. If it is memory corruption it will spot it quickly.<br>
<br>
Btw if you are using udp make sure you set the system buffers to be large enough.<br>
<br><br></blockquote><div><br></div><div>Hey Luca</div><div><br></div><div>After a bit more looking around, I think I pinpointed the problem.</div><div><br></div><div>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:</div>
<div><br></div><div><a href="http://pastebin.com/gtj7774K">http://pastebin.com/gtj7774K</a></div><div>Line 135 being the main culprit</div><div><br></div><div>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.</div>
<div><br></div><div>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?</div><div>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.</div>
<div><br></div><div>On a final note, I have already increased my system UDP buffer to 50Meg +</div><div><br></div><div>Regards,</div><div>Evgeny</div></div>