On 11/2/11 2:39 AM, Evgeny Yakimov wrote:
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.
That's strange in a way, some more investigation is needed.
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?
the udp protocol has a buffer_size option you can use.
lu
_______________________________________________
libav-api mailing list
[email protected]
https://lists.libav.org/mailman/listinfo/libav-api
