[libav-api] Opening and Decoding UDP MpegTS

Evgeny Yakimov john.yakimov at gmail.com
Fri Nov 4 17:04:00 CET 2011

On Wed, Nov 2, 2011 at 4:39 PM, Luca Barbato <lu_zero at gentoo.org> wrote:

> 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
> libav-api at libav.org
> https://lists.libav.org/**mailman/listinfo/libav-api<https://lists.libav.org/mailman/listinfo/libav-api>

Hello Luca

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:

10 av_open_input_file
20 av_find_best_stream
30 (save some details from the codec context for setting up internal
40 av_close_input_file(oc); oc = NULL;

50 Setup buffers/encoders/output streams
60 av_open_input_file
70 while (av_read_frame) ...

This causes the unexpected behaviour that I'm experiencing,

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.

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?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.libav.org/pipermail/libav-api/attachments/20111104/0777ba65/attachment.html>

More information about the libav-api mailing list