<div><br><div class="gmail_quote">On Wed, Nov 2, 2011 at 4:39 PM, Luca Barbato <span dir="ltr"><<a href="mailto:lu_zero@gentoo.org" target="_blank">lu_zero@gentoo.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

On 11/2/11 2:39 AM, Evgeny Yakimov wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<br>
Try to run the code in valgrind. If it is memory corruption it will spot<br>
it quickly.<br>
<br>
Btw if you are using udp make sure you set the system buffers to be large<br>
enough.<br>
<br>
<br>
<br>
</blockquote>
Hey Luca<br>
<br>
After a bit more looking around, I think I pinpointed the problem.<br>
<br>
Unfortunately Valgrind did not show the memory leak, because it runs a lot<br>
slower and in-fact cant run this live. I think the problem is that libav<br>
does performs some sort of buffer overflow If the input stream is not<br>
processed quickly enough. I was able to replicate this behaviour with the<br>
following code:<br>
<br>
<a href="http://pastebin.com/gtj7774K" target="_blank">http://pastebin.com/gtj7774K</a><br>
Line 135 being the main culprit<br>
<br>
It seems that If you take too long between your av_open_file and your<br>
av_frame_read (and potentially something to do with the find_stream_info) I<br>
guess some buffer overflow occurs which starts messing up everything else.<br>
</blockquote>
<br>
That's strange in a way, some more investigation is needed.<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
In the meantime I have fixed this by opening the stream once to query it<br>
for input details, closing it, then setting up all my output stuff which<br>
takes 3-10 seconds, and then again re-openning the stream and reading<br>
it immediately.<br>
<br>
Perhaps this could be fixed by increasing the buffer size? If so, Is there<br>
anyway I could manually force a larger buffer size for the input?<br>
</blockquote>
<br>
the udp protocol has a buffer_size option you can use.<br>
<br>
lu<br>
<br>
<br>
______________________________<u></u>_________________<br>
libav-api mailing list<br>
<a href="mailto:libav-api@libav.org" target="_blank">libav-api@libav.org</a><br>
<a href="https://lists.libav.org/mailman/listinfo/libav-api" target="_blank">https://lists.libav.org/<u></u>mailman/listinfo/libav-api</a><br>
</blockquote></div><br></div><div><br></div><div>Hello Luca</div><div><br></div><div>It seems that the actual cause of this problem was that I ran two av_open_input_files, my initial plan was to do this:<br><br>10 av_open_input_file</div>
<div>20 av_find_best_stream</div><div>30 (save some details from the codec context for setting up internal buffers/re-encoders)</div><div>40 av_close_input_file(oc); oc = NULL;<br><br>50 Setup buffers/encoders/output streams<br>
60 av_open_input_file<br>70 while (av_read_frame) ...<br><br><br>This causes the unexpected behaviour that I'm experiencing, </div><div><br></div><div>Where as If I hardcode the input details required for step 30, and them simply skip 10-40 and start at 50 (resulting in only a single av_open_input_file), it works fine.</div>
<div><br></div><div>Is it possible I'm not closing the input stream correctly. If thats the case can you please advise on the correct way to do this? </div><div><br></div><div>Regards,</div><div>Evgeny</div>